From: Michael B. <mbe...@mb...> - 2006-02-02 10:34:56
|
[Igor Leturia] > Now to the eXist developers: is there any intention to support any > XPath expression in indexes, such as the one I mentioned, in a near > future? [Pierrick Brihaye] > Well... I myself would appreciate such a feature but this would have an > impact on performance because indexing could only occur when the entire > document tree is loaded wheras eXist currently indexes "off the scratch= " >(this explains the limitations in the path expressions). I appreciate the processing cost of trying to support full XPath support = in index configuration, but I have wondered from time to time whether it mig= ht not be possible to at least allow reference to values along the current node's attribute axis (rather than just to attribute Qnames) and maybe to the Qname of the parent element when specifying an index. I am famously ignorant of eXist's innards, but I should have thought that in a SAX pars= e these items are retrievable for any given node at neglig=EDble cost. I personally am interested in such a feature, not so much for specifying range indexes, as for configuring selective indexation using the fulltext facility. It would be a huge boost to my applications if I could include = or exclude nodes from indexation on the basis of the value of a language attribute value. (I deliberately don't say xml:lang, because supporting t= hat might lead to unrealistic expectations about traversal to the first ances= tor with such an attribute explicitly set, as in XSLT). At the moment I have = to do an XSLT pre-pass to rewrite <p lang=3D"en"> ....</p> as <EN><p >.....<p></EN> so that I can get the language-selective indexation I need= . Incidentally, if there are to be pluggable tokenisers, the indexer (and query parser) is going to have to track xml:lang values at all times. A pluggable tokeniser limited to one language only would be one step forwar= d, two steps back... Michael Beddow Michael Beddow |