[
Lists Home |
Date Index |
Thread Index
]
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
|
