[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The evaluate function

Subject: Re: The evaluate function
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Fri, 4 Jan 2002 11:11:19 +0000
w3c xpointer restricted xpath
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

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 :)



Jeni Tennison

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.