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

RE: ANN: xpath1() scheme for XPointer


xinclude xpath
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!

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.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

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.