Geert,
I have some reservations about using <additional-query> to stuff
potentially-complicated logic involving the lower-level cts functions.
First, the search:search documentation says that terms matching the
<additional-query> are not highlighted in snippet result output. Does
that mean I'd lose all highlighting since <additional-query> would be
used to filter all matches?
I want to make sure I understand fully what you are suggesting, so let
me give a generic example. My documents have "container elements"
containing repeated sections. I must ensure that all constraints for
a particular group in a given query are satisfied within a single
section of the appropriate type. Imagine that the query is "a:x b:y"
and that a and b belong to one "group" (this is a simple case; in
reality there will be many groups to support and the query could
involve several):
<section1-container>
<section1>
<a>x</a>
<b>u</b>
</section1>
<section1>
<a>z</a>
<b>y</b>
</section1>
</section1-container>
Using an <additional-query> with:
cts:element-query( 'section1-container',
cts:element-query( 'section1', cts:and-query((
cts:element-value-query('a', 'x'), cts:element-value-query('b', 'y')
)) )
)
...would the above document match? I'm posting this before trying it,
but I do not want it to match.
To extend this to multiple groups, there would be several elements as
siblings to <section1-container>. I would wrap the above in a
cts;or-query and include additional element-queries for the siblings.
Is that what you'd recommend?
Thanks,
Karl
On Wed, Apr 7, 2010 at 2:57 AM, Geert Josten <[email protected]> wrote:
> Hi Karl,
>
> Danny mentioned another alternative in an earlier response which I think
> might be of interest to you. Searchable expressions allow you to explicitly
> select one subpath within documents, but you could also use element queries.
> I must warn that it will not have the exact same behaviour, but I have the
> impression that it should work for you, and I think it allows you to do your
> grouped-constraints query (just giving the beast some name) in one single
> search, without additional-queries etc.
>
> An element query takes the name of an element and a subquery. This subquery
> is constrained to the descendants of the element. So if you would supply and
> and-query as subquery, all these subqueries would be constrained to that
> element. It would require that the element names to which you want to
> constrain your searches should have some degree of uniqueness in the complete
> document, and shouldn't occur recursively. It would still work in those
> cases, but perhaps not in the way you would like. You can also wrap element
> queries in other element queries, but not that the inner element doesn't need
> to be the child, it can also be a descendant further down the hierarchy..
>
> Hope this helps..
>
> Kind regards,
> Geert
>
>>
>
>
> drs. G.P.H. (Geert) Josten
> Consultant
>
>
> Daidalos BV
> Hoekeindsehof 1-4
> 2665 JZ Bleiswijk
>
> T +31 (0)10 850 1200
> F +31 (0)10 850 1199
>
> mailto:[email protected]
> http://www.daidalos.nl/
>
> KvK 27164984
>
> P Please consider the environment before printing this mail.
> De informatie - verzonden in of met dit e-mailbericht - is afkomstig van
> Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit
> bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit
> bericht kunnen geen rechten worden ontleend.
>
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of
>> Karl Erisman
>> Sent: dinsdag 6 april 2010 23:26
>> To: General Mark Logic Developer Discussion
>> Subject: [MarkLogic Dev General] Re: Separate
>> searchable-expressions for different constraints?
>>
>> Okay, it sounds like you have the basic idea of what I'm
>> considering doing. My example had only two different
>> sections to search over, but in reality there could be N such
>> sections. I think you meant to suggest using
>> <additional-query> with cts:document-query, not
>> cts:directory-query. That is helpful; I was also planning on
>> multiple queries, but your suggestion of using
>> additional-query will make things easier.
>>
>> The data could be modeled in a different way make this
>> simpler, but there are trade-offs and I'm still weighing
>> different data modeling approaches.
>>
>> Thanks again,
>> Karl
>> _______________________________________________
>> General mailing list
>> [email protected]
>> http://xqzone.com/mailman/listinfo/general
>>
> _______________________________________________
> General mailing list
> [email protected]
> http://xqzone.com/mailman/listinfo/general
>
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
