[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The evaluate function
Evan wrote: > XPointer becoming Recommendation may be the only thing keeping XSLT > 1.0 processors from conformantly (and optionally?) implementing what > effectively can be used as an alternative to an explicit evaluate(). > > This wouldn't meet all of Jeni's use cases, but it would meet 90%+ > of the theoretical eventual uses of evaluate(), I bet. That's a good idea, but I don't think it meets that high a proportion of the use cases. It would meet all the cases where the expression returns a node sequence (or a boolean value via a node sequence), and does not need to be evaluated relative to the context item or with any other context information (e.g. variables, extension functions, context position). Only returning node sequences (or boolean values via node sequences) is OK - I think that about 95% of the requirement for evaluate() involve returning node sequences (or boolean values). However, I think that not having a concept of the context node is a *major* limitation. The vast majority of times that people need something like evaluate() come when they are trying to evaluate a path relative to the context node. You can use here() in XPointer to give you the node within the XSLT stylesheet in which the XPointer is held, but that doesn't really help. I'd estimate that this limitation reduces the percentage of cases that XPointer can manage to about 5-10%. That's not a small achievement, but it's not 90%+. One possibility would be for XSLT to override the definition of the origin() function in XPointer (which is intended to represent the origin of a link) such that it means the context node. I think that doing so would allow XPointer to be used with document() in perhaps 50% of cases. The remaining 50% would be cases like the first use case I provided, where a variable reference is required (there's no way of initializing variables in XPointer, and all variable references within an XPointer are errors), or where position() is used. Users would also have to get used to a restricted XPath syntax compared to what they'll be used to in XSLT 2.0, since XPointer supports XPath 1.0 and any functions outside XPath 1.0 and XPointer functions are errors. I'd also point out that using XPointer if the source document (and thus the XPaths that you're evaluating) use namespaces is pretty horrific. XPointer 1.0 is a Candidate Recommendation at the moment. If the XSL WG can work with the XML WG (who produce XPointer) to create an XPointer 1.1 with facilities to support XPath 2.0 syntax, the context node, variable references, and namespace declarations provided externally, then great. However, I wonder whether it's worth it, given that the resulting language would be essentially "XPointer, but without the bits that aren't in XPath, and with the bits that XPath has but XPointer omits", which is equivalent to XPath :) Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
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
|