Re: [Jaxen] Custom location step functions
Hi Hallvard. That sounds interesting. You can call a function and navigate through its results already. e.g. document( 'foo.xml' )//bar[@x='123']/xyz I'm just wondering why you think that a custom location step is requried. e.g. your example could be reworked a little as follows... ext:related-thing(thing)[@color='red'] Or further location steps can be appended as needed such as ext:related-thing(thing)[@color='red']/foo/bar Without having to change the XPath grammar etc. Would that do what you need? James - Original Message - From: Hallvard Trætteberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 18, 2002 3:00 PM Subject: [Jaxen] Custom location step functions Hi, I've managed to add custom location step functions to jaxen, to allow xpath expressions like thing/ext:related-thing()[@color='red']. The idea is that a function may generate the elements in a step, e.g. to support navigating across idref's or increase speed. Main features of the implementation: - add support for this in the XPathHandler interface - make the saxpath parser recognize the new syntax - add support in XPathFactory, DefaultXPathFactory and JaxenHandler - add new DefaultFunctionStep class, extending DefaultStep which uses the custom function to generate elements to iterate over (the axis is ignored) Any interest in adding this to Jaxen? Anyone care to validate the implementation? Hallvard Trætteberg, stipendiat ved IDI, NTNU http://www.idi.ntnu.no/~hal, mailto:[EMAIL PROTECTED], phone:+47 7359 3443 ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
RE: [Jaxen] Custom location step functions
James, I'm just wondering why you think that a custom location step is requried. e.g. your example could be reworked a little as follows... ext:related-thing(thing)[@color='red'] When designing the XML structure you have to anticipate the navigation pattern, to ensure that everything interesting is underneath in the hierarchy. This is often not feasible, so I find it useful to have custom functions for jumping across the XML tree. Requiring that the function be the first step is limiting, i.e. cannot be used for just navigating along an idref and nothing more. In my particular application, I combine XML and javascripting, so the custom function can be written in javascript and embedded in the file. Or further location steps can be appended as needed such as ext:related-thing(thing)[@color='red']/foo/bar Without having to change the XPath grammar etc. Would that do what you need? For a specific purpose this is usually possible, but when all navigation patterns are taken together, it's not always possible to design a tree where navigation is always downward. Hence, there is a need for custom jumps in the XML tree. In some application, the speed may also improved this way. BTW, isn't this part of XPath 2.0, for these purposes? Hallvard ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
RE: [Jaxen] Possible bug with processing instructions
Hmm, Switching to preceding axis for clarity, but issue is the same. From Michael Kay's XSLT Programmers Reference 2nd Edition by Wrox Press, page 364: preceding: This selects all the nodes that appear before the origin node, excluding the ancestors of the origin, in reverse document order. If the origin is an element node, this effectively means that it contains all the text nodes, element nodes, comments, and processing instructions in the document that finish before the start tag of the origin element. The preceding axis will never contain attribute or namespace nodes. Is he dead wrong here or what? /Mattias -Original Message- From: [EMAIL PROTECTED] [mailto:jaxen-interest- [EMAIL PROTECTED]] On Behalf Of bob mcwhirter Sent: den 18 april 2002 15:47 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: Re: [Jaxen] Possible bug with processing instructions XPath spec, 2.3: Every axis has a principal node type. If an axis can contain elements, then the principal node type is element; otherwise, it is the type of the nodes that the axis can contain. Thus, * For the attribute axis, the principal node type is attribute. * For the namespace axis, the principal node type is namespace. * For other axes, the principal node type is element. --- So, preceding-sibling::* will select the preceding sibling of the type 'element', as I read it. Am I misinterpreting the spec? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hi, I'm using dom4j and of course also jaxen for some xml processing. Got into trouble when trying to get a hold of a processing instruction via an xpath expression. Example: a b/ ?toc order-by=x? c/ /a c.selectSingleNode(preceding-sibling::*[1]); returns b. Best Regards Mattias Reichel ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
RE: [Jaxen] Possible bug with processing instructions
Actually, now that I re-read the spec, I'm not certain what my point was. (One of those days). Okay, an axis has a primary node type, but, so what? Hmm... Does preceding-sibling::node() manage to find the PI? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hmm, Switching to preceding axis for clarity, but issue is the same. From Michael Kay's XSLT Programmers Reference 2nd Edition by Wrox Press, page 364: preceding: This selects all the nodes that appear before the origin node, excluding the ancestors of the origin, in reverse document order. If the origin is an element node, this effectively means that it contains all the text nodes, element nodes, comments, and processing instructions in the document that finish before the start tag of the origin element. The preceding axis will never contain attribute or namespace nodes. Is he dead wrong here or what? /Mattias -Original Message- From: [EMAIL PROTECTED] [mailto:jaxen-interest- [EMAIL PROTECTED]] On Behalf Of bob mcwhirter Sent: den 18 april 2002 15:47 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: Re: [Jaxen] Possible bug with processing instructions XPath spec, 2.3: Every axis has a principal node type. If an axis can contain elements, then the principal node type is element; otherwise, it is the type of the nodes that the axis can contain. Thus, * For the attribute axis, the principal node type is attribute. * For the namespace axis, the principal node type is namespace. * For other axes, the principal node type is element. --- So, preceding-sibling::* will select the preceding sibling of the type 'element', as I read it. Am I misinterpreting the spec? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hi, I'm using dom4j and of course also jaxen for some xml processing. Got into trouble when trying to get a hold of a processing instruction via an xpath expression. Example: a b/ ?toc order-by=x? c/ /a c.selectSingleNode(preceding-sibling::*[1]); returns b. Best Regards Mattias Reichel ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
RE: [Jaxen] Possible bug with processing instructions
Hmmm... Sounds like a bug. So, standard questions: Which version of dom4j are you using? James? Any thoughts? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Nope! -Original Message- From: bob mcwhirter [mailto:[EMAIL PROTECTED]] Sent: den 18 april 2002 16:09 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: RE: [Jaxen] Possible bug with processing instructions Actually, now that I re-read the spec, I'm not certain what my point was. (One of those days). Okay, an axis has a primary node type, but, so what? Hmm... Does preceding-sibling::node() manage to find the PI? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hmm, Switching to preceding axis for clarity, but issue is the same. From Michael Kay's XSLT Programmers Reference 2nd Edition by Wrox Press, page 364: preceding: This selects all the nodes that appear before the origin node, excluding the ancestors of the origin, in reverse document order. If the origin is an element node, this effectively means that it contains all the text nodes, element nodes, comments, and processing instructions in the document that finish before the start tag of the origin element. The preceding axis will never contain attribute or namespace nodes. Is he dead wrong here or what? /Mattias -Original Message- From: [EMAIL PROTECTED] [mailto:jaxen-interest- [EMAIL PROTECTED]] On Behalf Of bob mcwhirter Sent: den 18 april 2002 15:47 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: Re: [Jaxen] Possible bug with processing instructions XPath spec, 2.3: Every axis has a principal node type. If an axis can contain elements, then the principal node type is element; otherwise, it is the type of the nodes that the axis can contain. Thus, * For the attribute axis, the principal node type is attribute. * For the namespace axis, the principal node type is namespace. * For other axes, the principal node type is element. --- So, preceding-sibling::* will select the preceding sibling of the type 'element', as I read it. Am I misinterpreting the spec? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hi, I'm using dom4j and of course also jaxen for some xml processing. Got into trouble when trying to get a hold of a processing instruction via an xpath expression. Example: a b/ ?toc order-by=x? c/ /a c.selectSingleNode(preceding-sibling::*[1]); returns b. Best Regards Mattias Reichel ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
RE: [Jaxen] Possible bug with processing instructions
I use dom4j 1.3 -Original Message- From: [EMAIL PROTECTED] [mailto:jaxen-interest- [EMAIL PROTECTED]] On Behalf Of bob mcwhirter Sent: den 18 april 2002 16:18 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: RE: [Jaxen] Possible bug with processing instructions Hmmm... Sounds like a bug. So, standard questions: Which version of dom4j are you using? James? Any thoughts? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Nope! -Original Message- From: bob mcwhirter [mailto:[EMAIL PROTECTED]] Sent: den 18 april 2002 16:09 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: RE: [Jaxen] Possible bug with processing instructions Actually, now that I re-read the spec, I'm not certain what my point was. (One of those days). Okay, an axis has a primary node type, but, so what? Hmm... Does preceding-sibling::node() manage to find the PI? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hmm, Switching to preceding axis for clarity, but issue is the same. From Michael Kay's XSLT Programmers Reference 2nd Edition by Wrox Press, page 364: preceding: This selects all the nodes that appear before the origin node, excluding the ancestors of the origin, in reverse document order. If the origin is an element node, this effectively means that it contains all the text nodes, element nodes, comments, and processing instructions in the document that finish before the start tag of the origin element. The preceding axis will never contain attribute or namespace nodes. Is he dead wrong here or what? /Mattias -Original Message- From: [EMAIL PROTECTED] [mailto:jaxen-interest- [EMAIL PROTECTED]] On Behalf Of bob mcwhirter Sent: den 18 april 2002 15:47 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: Re: [Jaxen] Possible bug with processing instructions XPath spec, 2.3: Every axis has a principal node type. If an axis can contain elements, then the principal node type is element; otherwise, it is the type of the nodes that the axis can contain. Thus, * For the attribute axis, the principal node type is attribute. * For the namespace axis, the principal node type is namespace. * For other axes, the principal node type is element. --- So, preceding-sibling::* will select the preceding sibling of the type 'element', as I read it. Am I misinterpreting the spec? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hi, I'm using dom4j and of course also jaxen for some xml processing. Got into trouble when trying to get a hold of a processing instruction via an xpath expression. Example: a b/ ?toc order-by=x? c/ /a c.selectSingleNode(preceding-sibling::*[1]); returns b. Best Regards Mattias Reichel ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
