Fwd: Specify server processing of XPointers

  this was posted in the XPointer comment list but might interest XInclude
people as well,

http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000OctDec/0040.html

Daniel

----- Forwarded message from Martin Gudgin <marting@develop.com> -----

> From: "Martin Gudgin" <marting@develop.com>
> To: <www-xml-linking-comments@w3.org>
> Date: Sun, 29 Oct 2000 17:53:42 -0000
> Subject: Specify server processing of XPointers
> 
> 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

----- End forwarded message -----

-- 
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | libxml Gnome XML toolkit
Tel : +33 476 615 257  | 655, avenue de l'Europe | http://xmlsoft.org/
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Rpmfind search site
 http://www.w3.org/People/all#veillard%40w3.org  | http://rpmfind.net/

Received on Sunday, 29 October 2000 13:41:28 UTC