[
Lists Home |
Date Index |
Thread Index
]
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
------------------------------------------------------------------------
|
