Re: Specify server processing of XPointers

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.

paul

[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
>items.
>
>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
>server.
>
>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
>DevelopMentor
>
>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