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.

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 11:51:47 UTC