RE: ANN: xpath1() scheme for XPointer
At 11:01 AM 10/25/2002 +0100, Michael Kay wrote: > > The I-D is available at: > > http://www.ietf.org/internet-drafts/draft-stlaurent-xpath-frag-00.txt > >Good stuff. Thank you very much. >I would tighten it up by saying explicitly that variable references, and >function calls other than the core functions defined in XPath 1.0, are >not allowed, and that the XPath expression is evaluated with a context >position and size of 1, and a context node that is the element >containing the XPointer. Those all sound good to me. >It might also aid interoperability to say >something explicit about the handling of whitespace-only text nodes. I'll have to think about the whitespace issues. In the original contexts I was thinking about those nodes would be full citizens, but in other contexts... well, I'll have to think. >I'm a little surprised that you seem [from the last sentence of section >3] to see the scheme as providing a way of addressing within an XML >entity, rather than an XML document. That last sentence states: -------------------------------------------- To support identifiers operating on external parsed entities with multiple root elements or text nodes, the xpath1() scheme extends the XPath data model to permit the root node to contain any sequence of nodes that an element node may contain. (XSLT provides the same extension.) --------------------------------------------- Basically, this is to ensure that XPointers using the xpath1() scheme could point into external parsed entities and not just XML documents. I believe the xpointer() scheme does this as well. While it's not something I would expect to do on a regular basis, I can see it being useful in certain contexts (notably XInclude). >In fact, I think it would be most >useful to say that both entity expansion and XInclude processing should >happen before XPath evaluation. I think I'll add language stating that those should happen before XPath evaluation - but there are some issues there. Not all parsers expand all entities, and XML 1.0 explicitly permits that. Similarly, many parsers don't speak XInclude, and the processing model for XInclude isn't exactly clear. Overall I think I'll state those requirements and require xpath() processors to report an error if they encounter either an unresolved entity or an unresolved XInclude. That could get very weirdly messy otherwise. >I've been looking for a way of defining a syntax for XPath expressions >that doesn't depend on the namespace context, for use in a dynamic >xx:evaluate(), and this XPointer scheme seems to provide the answer. I originally just wanted to come up with something to give XML fragment identifiers a push for hypertext linking, but I'm happy to hear that it has potential in other contexts as well. I'll be publishing a revised draft in the next couple of days, and hopefully I can make it a bit more concrete thanks to the issues you've raised. Simon St.Laurent "Every day in every way I'm getting better and better." - Emile Coue
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format