[
Lists Home |
Date Index |
Thread Index
]
At 10:40 AM 10/26/2002 -0400, Elliotte Rusty Harold wrote:
>At 11:01 AM +0100 10/25/02, Michael Kay wrote:
>>It might also aid interoperability to say
>>something explicit about the handling of whitespace-only text nodes.
>
>What would you need to say about this? XPath is unambiguous about handling
>this. Perhaps it just needs to be pointed out that whitespace only nodes
>do count, though I hope by now most XPath users know this.
I'm still thinking about how to discuss this, and guessing that some
examples might be the best approach.
>Entity expansion is a good idea. I don't think the XPath data model really
>applies unless entities have been expanded.
I think that's most easily handled by requiring an error if an unexpanded
entity is encountered, though I'm not sure whether many XPath processors
will notice.
>XInclude resolution is trickier. The proper result of applying an XPath
>expression to a document containing XInclude is completely unambiguous,
>and it does not involve XInclude resolution. Consider, for example, the
>XPath expression //xinclude:include.
We've gone around and around on this one, and I've pretty much concluded
that different people and different processors see XInclude on different
levels. The relation of this specification to XInclude is a bit tricky -
in part because I think xpath1() lowers a barrier to easy implementation of
XInclude - so XInclude deserves some careful consideration.
>Thinking about this, I suspect it's a URI level question. The document
>before XInclude resolution is not the same as the document after XInclude
>resolution. These are two different documents. They are two different
>resources. They need to have distinguishable URIs. Unfortunately right now
>they don't.
There's a lot of resource/representation issues here that can make this
discussion very complicated. The document before/document after issue
seems to be about two different representations of a resource, not two
different resources, much as the same URI may return, for instance, HTML or
SVG representations of the same resource.
Unfortunately, I don't think acknowledging those issues gets us any closer
to resolving the issues, as URIs (IMHO) are not much good for identifying
representations. We're kind of forced to work with shadows...
>This could be hacked with an xinclude pointer part; e.g. xinclude(yes) or
>xinclude(no) but that's really the wrong layer. We're not using these to
>select a different part of the document. We're using them to select a
>different document. That's what the URL is for.
I wonder if it might be a good idea to go through the exercise of writing
an xinclude() scheme - plastered with appropriate warning labels - as a
basis for discussion. I agree with you that the layering issues are pretty
deep here.
(If Elliotte or anyone else would be interested in writing such a document,
let me know. It'd be easy to repurpose a lot of the resources used in
writing this draft, and the RFC 2629 XML format for doing this makes it
pretty easy. I may take a crack at it today, as I have a peaceful day in a
California hotel while I wait for a Saturday-stayover flight.)
>I'm not sure where you could put the xinclude processing in the URL? The
>scheme? The authority? The user info? Perhaps http://www.example.com/
>points to the document as it exists and xinclude:http://www.example.com/
>points to the document after XIncludes. But whatever the URL looks like,
>these are two different documents, and that needs to be recognized.
In general, I worry about the usefulness of XPointer (and fragment
identifiers generally) when the same resource can return multiple
representations, as there's no means of specifying which representation you
expect to get. Putting xinclude(yes) or content-type(image/svg+xml) into
the fragment identifier seems really wrong, but I don't see a simple way of
addressing these issues.
Simon St.Laurent
"Every day in every way I'm getting better and better." - Emile Coue
|
