This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]