Thanks for the suggestions. I admit the XML isn't ideal and is ugly to process, but I'm using a standardized XML format, not a home-grown one, so my options for changing the XML are limited if I want the XML to remain valid. I'd prefer to keep things simple and let the ML database hold the "real" XML, not keep the real XML elsewhere and transform when loading into ML. However, I do have the option of doing this:
<language displayLabel="English"> <languageTerm type="code" authority="iso639-2b">eng</languageTerm> </language> which solves the ML indexing problem (make it an attribute range index on language/@displayLabel) even if it's not that much cleaner to process via XPath. Thanks, Greg On Jun 7, 2011, at 12:50 PM, Michael Blakeley wrote: > Danny is right, but I would suggest restructuring the XML to make it more > expressive. This will result in more efficient indexing and querying, and a > more robust application. Consider the XPath to get a language name for a > known code: > > language[languageTerm[@type eq 'code'][. eq $code]]/ > languageTerm[@type eq 'text']/string() > > That's quite ugly, and confusing to read. I predict that it will lead to > programming errors. I would suggest using a more expressive document > structure, one that takes full advantage of XML. The structure should allow > for XPath something more like this: > > language[@code eq $code]/string() > > Or perhaps: > > language[@code eq $code]/@name > > The XML might look like: > > <language code="eng">English</language> > > Or > > <language code="eng" label="English" /> > > Or the authority might be encoded in the QName: > > <language iso639-2b="eng">English</language> > > In any of these cases, the XML is more expressive. As a result it's much > easier to write XPath against the XML, and also to create range indexes. > > If the XML has to arrive in the original format, that's ok. You can use a CPF > pipeline or a RecordLoader input module to transform the XML as it arrives. > If necessary, you can also provide output in a variety of formats. But any > XML processor should prefer a more expressive schema to an overly generic > structure. > > -- Mike > > On 7 Jun 2011, at 09:29 , Danny Sokolsky wrote: > >> There is no way to specify that a range index only applies based on a >> filter. A range index will index all QNames for that element in your >> database. >> >> You can, however, pass a cts:query into the lexicon functions, which can >> accomplish something similar. >> >> -Danny >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Murray, Gregory >> Sent: Tuesday, June 07, 2011 8:32 AM >> To: General MarkLogic Developer Discussion >> Subject: [MarkLogic Dev General] Indexing an element based on attribute value >> >> Apologies if this is a common and/or elementary question, but I couldn't >> find an answer in the ML docs or list archives. >> >> I'd like to add an element range index for an element, but only include >> element values when the element occurs in a specific context -- namely when >> a particular attribute has a particular value. Example: >> >> <language> >> <languageTerm type="text">English</languageTerm> >> <languageTerm type="code" authority="iso639-2b">eng</languageTerm> >> </language> >> >> I want to index <languageTerm> when @type = "text", but not otherwise. >> Doable? >> >> Thanks, >> Greg >> >> Gregory Murray >> Digital Library Application Developer >> Princeton Theological Seminary >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
