I think what you need here is to use the searchable-expression option. The searchable-expression option controls what the searches will return (like the first argument to cts:search). So for example, your searchable expression might be something like:
<search:searchable-expression>/contacts/contact</search:searchable-expression> Then the search would return contact elements. -Danny -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Karl Erisman Sent: Sunday, November 22, 2009 5:52 PM To: [email protected] Subject: [MarkLogic Dev General] Search API: specifying multiple constraints Suppose an XML structure has repeated element names, for example: <contacts> <contact> <name>bob</name> <relation>uncle</relation> <phone>1111111</phone> </contact> <contact> <name>mike</name> <relation>uncle</relation> <phone>2222222</phone> </contact> </contacts> How can the search API be used to find a *specific* <phone> element, ignoring other such elements at different levels (XPath: contacts/contact[name/text()="bob"]/phone)? The following: search:search("relation:uncle", <options xmlns="http://marklogic.com/appservices/search";><constraint name="relation"><value><element ns="" name="relation" /></value></constraint></options>) ...would allow matches for <relation> *anywhere* in the document (as long as the cts:element-value-query implied by the constraint option is satisfied). However, I want the constraint to allow a match for Uncle Bob, but not Uncle Mike (so if the above XML was in two separate documents, only one would match). Of course, my target documents will be much more interesting, but this illustrates the pattern. I'm interested in knowing how to require that matches satisfy more complicated constraints than "element is x", "attribute is y", etc. I also would like to know how to require that matches follow a particular path which may involve many hierarchical levels (so I can be sure that results come from a specific subtree and not another subtree that may use the same element names). Perhaps it depends on the specific situation, but are <additional-query> and <custom> the best facilities for tasks such as these? That would still make for lots of manual cts:query construction work. Thanks. _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
