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
