Actually, $root//nr will never return $root. Remember that expanding the last step yields $root//child::nr. ($root//self::nr would be another story.) So $root//nr can always be rewritten as $root/descendant::nr, regardless of what $root is. The only cases where "//" isn't equivalent to "/descendant::" is when an explicit (especially non-child) axis is used after "//", or when the predicate is numeric (positional) or calls last() or position(), e.g.:
Non-child axis in last step: $root//@foo $root//namespace::foo $root//. (equivalent to $root/descendant-or-self::node()) etc. Position- and/or size-dependent predicates: $root//foo[1] $root//foo[last()] $root//foo[position() != last()] $root//foo[last() gt 5] (get all <foo>s that have at least five sibling <foo>s) Evan On 1/7/12 7:28 AM, "Erik Hennum" <[email protected]> wrote: >Hi, Geert: > >Given that a document is not a named element and that collection() >returns document nodes, collection()/self::nr will never match. > >So, unless I misunderstand the issue, in practice //nr turns out to be >identical to collection()/descendant::nr > >The case would be different, of course with $root//nr where $root can be >an element. Also, as you point out, predicates have different effects >when using the shortcut and the explicit axis. > > >Hoping that's useful, > > >Erik Hennum > >________________________________________ >From: [email protected] >[[email protected]] On Behalf Of Geert Josten >[[email protected]] >Sent: Saturday, January 07, 2012 6:28 AM >To: General MarkLogic Developer Discussion >Subject: Re: [MarkLogic Dev General] //nr expanded to /decendant::nr ?? > >Hi Ron, > >You might be right about optimizer checking equivalence. //nr/text() gives >descendant::nr, but //nr[1]/text() remains nr[1]. //nr[true()] though, >gives descendant::nr again. I am sufficiently reassured for the time >being.. ;-) > >Thnx for your time, >Geert > >-----Oorspronkelijk bericht----- >Van: [email protected] >[mailto:[email protected]] Namens Ron Hitchens >Verzonden: zaterdag 7 januari 2012 14:53 >Aan: General MarkLogic Developer Discussion >Onderwerp: Re: [MarkLogic Dev General] //nr expanded to /decendant::nr ?? > > > I don't have the energy to contemplate the >subtleties of XPath semantics on a Saturday afternoon. >But I can say that this is not a profiling artifact, >since I wrote the MarkLogic profiler. > > The code snippets you see in the profiler output >are derived from the expression tree produced by the >XQuery parser. The profiler doesn't modify that tree >in any way, it's just hooked into the run-time evaluation >of it. > > The "code" for each expression in the profiling report >is a serialization of a node in the tree, not the original >source text. Any rewriting or optimization done during >static analysis (when the expression tree is built) will >be reflected in the profiler report. > > So, either the XQuery parser/optimizer is choosing >a simpler representation which it believes to be equivalent, >or there may be a subtle bug in it. If you can produce a >test case that shows different results for the compact vs >verbose XPaths, I'm sure MarkLogic would love to see it. > > I'm going back to my weekend now. > >On Jan 7, 2012, at 1:19 PM, Geert Josten wrote: > >> Hi all, >> >> I was using the Query console to profile a simple piece of abbreviated >> xpath, and my eye was caught by the way it was expanded in the profile >> details. I ran this expression: >> >> //nr/text() >> >> (wrapped in a distinct-values actually, but that shouldn't really >matter) >> The profile stats however are talking about: >> >> collection()/descendant::nr/text() >> >> Anyone who followed the blog articles from Evan >> (http://developer.marklogic.com/blog/xpath-punctuation-part-5 in >> particular), should know it really stands for: >> >> collection()/descendant-or-self::node()/child::nr/text() >> >> That can be of significant difference when predicates are in play >(applied >> to nr). Is MarkLogic really interpreting //nr as /descendant::nr, or is >> that just a glitch in the profiler output? I haven't taken time to come >up >> with some test case to check myself, yet.. >> >> Anyone care to comment? >> >> Kind regards, >> Geert >> >> drs. G.P.H. (Geert) Josten >> Senior Developer >> >> >> >> Dayon B.V. >> Delftechpark 37b >> 2628 XJ Delft >> >> T +31 (0)88 26 82 570 >> >> [email protected] >> www.dayon.nl >> >> De informatie - verzonden in of met dit e-mailbericht - is afkomstig van >> Dayon 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://developer.marklogic.com/mailman/listinfo/general > >--- >Ron Hitchens {mailto:[email protected]} Ronsoft Technologies > +44 7879 358 212 (voice) http://www.ronsoft.com > +1 707 924 3878 (fax) Bit Twiddling At Its Finest >"No amount of belief establishes any fact." -Unknown > > > > >_______________________________________________ >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
