- From: Eric van der Vlist <vdv@dyomedea.com>
- Date: 19 Jul 2002 11:18:10 +0200
- To: xml-dev@lists.xml.org
- Cc: www-xml-linking-comments@w3.org
On Fri, 2002-07-19 at 05:01, Rick Jelliffe wrote: > From: "Eric van der Vlist" <vdv@dyomedea.com> > > In other words, a client never sends a request for a fragment! > > But that is not what I am talking about. HTTP is nothing to do with it. Yes and no, the architecture in which HTTP based XPointer is used is 3+ tiers and I have focussed up to now in the interactions between the user agent and the server only. Let's summarize and extend what I have learned so far... The architectures in which HTTP based XPointer are being used are (at least) 3 tiers and the different actors are: - A user (human or not) - A user agent (for instance a browser or an API) - A HTTP server XPointer concatenate in a single string 2 information pieces: - the identification of the target document - the identification of the fragment XPointer and HTTP make it clear that the identification of the target document is an information to be used between the user agent and the server and that the identification of the fragment is for the use of the user agent only which must process the "fragmentation" of the document by itself. This is a first point where we may agree or not, but I am afraid that the couple "XPointer, HTTP" doesn't leave much latitude about the split of the tasks between these 3 tiers. Now comes the problem "how can the user agent interpret the identification of the fragment?". My feeling at this point is that the current version of XPointer is either too permissive ot too strict in this respect, at least for the short hand pointers defined in the XPointer framework. When you give it a fragment identifier, the user agent has two basic issues to solve: which algorithm should it use to understand the id and on which data should it process this algorithm. To me, it looks like XPointer is very strict to define which algorithm may be used (ie only DTD and WXS ids), moderately precise in saying how a user agent can choose between these two and very open in how a user agent can determine on which data (ie which schema should it use). At this point, I am not discussing whether not specifying how user agents should process ids is a good thing or not but rather just saying that I don't see the point of being strict in specifying the algorithm and not specify how the data on which the algorithm should be applied. I see the point of being either strict and impose an algorithm and a way to choose a schema or open and leave to the user agent the choice for both the choice of the algorithm (there are many other possibilities to define ids in a XML document such as the ones discussed on XML-DEV) and the choice of the data on which the algorithm should be processed. My proposal for the XLinking WG is thus to either specify a normative way to choose a schema or to describe the usage of DTD and WXS ids non normatively as two possible ways to define ids without exckuding other alternatives. If this second alternative is chosen, this will leave room for another issue which is to define mechanisms to let the triple (user, user agent, server) agree on what these ids are... Even though this issue is considered as out of the scope of XPointer, I still think that for a given application (or range of applications) there is a need to specify how this should work. Eric -- See you in San Diego. http://conferences.oreillynet.com/os2002/ ------------------------------------------------------------------------ Eric van der Vlist http://xmlfr.org http://dyomedea.com (W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema ------------------------------------------------------------------------
Received on Friday, 19 July 2002 05:18:15 UTC