W3C home > Mailing lists > Public > www-xml-linking-comments@w3.org > October to December 2000

Re: Specify server processing of XPointers

From: Paul Grosso <pgrosso@arbortext.com>
Date: Mon, 30 Oct 2000 11:05:16 -0600
Message-Id: <>
To: "Martin Gudgin" <marting@develop.com>, <www-xml-linking-comments@w3.org>
Most of these questions are really for XInclude, not XPointer
(the latter just being the defn of the fragment identifier into
an XML resource, though I admit that there is some issue about
who gets to define the behavior associated with the # sign in
URI references), so I have forwarded a copy of this message
to the XInclude comments list (see [1]).

Specifically, Q1 and Q3 are neither XPointer nor XLink questions,
but XInclude questions.

Q2, and O2 which is pretty much the same issue, is an interesting
one that I think was raised a while ago, but I'm not sure what
happened on it.  It is mostly an XPointer and perhaps 
a RFC 2396 question, I think.  

As far as O3, a client could certainly do something special
for an href such as "#foo".  For an href such as 
"http://www.acme.com/redirected-to-whatever.xml#foo" where the 
current document happens to be at http://www.acme.com/whatever.xml, 
it would not be practical to expect the client to do something
special.  Generally, questions of "optimization" are best left
out of specs and left up to implementations.


[1] http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2000Oct/0011

At 17:53 2000 10 29 -0000, Martin Gudgin wrote:
>I've been writing an XInclude implementation along with XML Base support and
>I got to thinking about the 'correct' way to process XPointer fragments in
>XInclude hrefs. It seems to me that ideally the xpointer evaluation would be
>done at the server thus avoiding downloading a potentially large document to
>the client, only to have the client throw away all but a few information
>I would like to propose the following 'processing' scheme;
>1.    XInclude processors SHOULD convert the # to a ? and submit the
>resulting URI + query string to the server for processing
>2.    If the server can resolve XPointers it MUST wrap the result in a well
>know element ( e.g. <xptr:container xmlns:xptr='someuri for xpointer'>
>xpointer result goes here </xptr:container>  ) otherwise it returns the
>entire document as normal
>3.    The client MUST look at the top-level element to determine whether the
>server has processed the XPointer or not. If the top-level element is
>xptr:container then the client MUST strip of the element and use the
>elements descendants to replace the including element. If the top-level
>element is NOT xptr:container then the client must process the XPointer
>locally in order to acheive the correct result.
>This does lead to a few questions;
>Q1.    Is it legal to replace a single element information item that has an
>Xinclude href attribute information item associated with it with multiple
>element information items? From reading the XInclude spec I think not as it
>says the thing being included must be an infoset... but it would be quite
>common in the case of an XPointer.
>Q2.   Do the XLink WG want to support server side processing of XPointers
>Q3.   If the answer to 1 and 2 is Yes then can the XLink WG please define
>the top-level element that should be used to be the container for xpointer
>results. We can only get interop between implementation if this is specified
>in the Rec.
>And some observations:
>O1.    This processing scheme would only work with URLs served by web
>servers or similar software. File URLs will HAVE to be processed locally by
>the client.
>O2.    I understand that the '#' character indicates that the fragment
>should be processed by the user-agent, I'm hoping that my proposal does not
>violate this requirement. The user-agent is processing the fragment it just
>so happens that such processing involves submitting a modified form to the
>O3.    The client-side processor should be optimized to deal with xpointers
>that refer to the current XML document.
>I would be very interested in your comments, and I apologies if this has
>previously been beaten to death on the WG, IG or comments lists...
>Martin Gudgin
>P.S. Since I wrote the above the XInclude WD has been changed to address Q1
>above. I'm now working on changing my XInclude implementation over to the
>new syntax
Received on Monday, 30 October 2000 12:05:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:22 UTC