Okay, thanks again. The solution I'm leaning towards (assuming I will
use this document modeling approach) involves a couple of the things
we've discussed. I'll get a query like "physician-lastname:williams
chief-complaint:aches test-name:rdw test-value 14.6". I'll know that
the constraint groups are as follows: A = {physician-lastname,
chief-complaint}; B = {test-name, test-value}. I'll run a search on
group A using a <searchable-expression> that constrains to section A.
Then I'll run a search on group B using a different
<searchable-expression> and an <additional-query> with a
cts:document-query containing all the results from the search on A.
That's two searches, but there would be N searches for N sections (I
expect N <= ~7).
As for highlighting, I guess the above strategy would lose
highlighting except for the last search performed. Maybe I can save
the search:highlight nodes from each search and do some recombining at
the end. It's not a painless strategy, but I think it will work for
small numbers of sections and documents of "reasonable" size.
On Wed, Apr 7, 2010 at 10:49 AM, Geert Josten <[email protected]> wrote:
> One additional note:
>
> You prefered to not using additional-query because of highlighting, but you
> will have to do multiple searches then and will end up with multiple search
> results that you will have to join or intersect (making pagination more
> difficult as well). Each set will have only one type of highlighting, so that
> won't be helpful either. It is easiest to skip highlighting all together, but
> you could perhaps apply the 'old' cts highlight on the search results to
> apply multiple hightlighting (one for each query type). Or perhaps Mark Logic
> has better ideas?
>
> Kind regards,
> Geert
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of
>> Geert Josten
>> Sent: woensdag 7 april 2010 17:38
>> To: General Mark Logic Developer Discussion
>> Subject: RE: [MarkLogic Dev General] Re: Separate
>> searchable-expressions fordifferent constraints?
>>
>> Hi Karl,
>>
>> > 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 was actually suggesting not using additional-query nor
>> searchable-expression, but read on first please..
>>
>> > 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.
>>
>> Hmm, I don't think one big query is going to work
>> unfortunately. To my knowledge, the element-query constraints
>> only look a the names of parents, not at the real sharing of
>> parents. That is what I meant with certain degree of
>> uniqueness. You can differentiate between section1
>> constraints and section2 constraints, but not between
>> constraints on individual section1 elements.
>>
>> On the other hand, if you use the searchable-expression to
>> select section1 elements (like Danny suggested), then it
>> should match the constraints within each individual section1
>> element. It will likely involve filtering under the hood to
>> make it work, but at least it would work..
>>
>> > 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.
>>
>> Well, I was indeed suggesting wrapping the big lot in an
>> or-query or an and-query, but we already determined that you
>> will need the searchable-expression, so no use bothering
>> about it any longer..
>>
>> > Is that what you'd recommend?
>>
>> I hope it is clearer now how element queries can be helpful
>> (and how not)..
>>
>> 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.
>>
>> _______________________________________________
>> 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
