RE: Specify server processing of XPointers

> -----Original Message-----
> From: Martin Gudgin [mailto:marting@develop.com]
> Sent: Monday, October 30, 2000 8:52 AM
> To: www-xml-xinclude-comments@w3.org
> Subject: Specify server processing of XPointers
> 
> 
> [Since this is mostly about XInclude, I am forwarding a copy of this
> message to the XInclude comment list.  -- paul]
> 
> 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.

It's unclear to me why XInclude would need to support this.  You are already
free to use a ? in the URI and do whatever server processing you desire.
The method you suggest is intrusive and changes the meaning of URIs, which
is a bad thing.

> 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.

Yes. Section 3.2.2 specifies that multiple nodes may result, and are
inserted in order.

The remaining comments should be addressed by the XLink WG, but what you
suggest is simply a different problem than XPointer is designed to solve.  

> 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 15:36:56 UTC