[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: ANN: xpath1() scheme for XPointer
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
|
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
|