Lists Home |
Date Index |
Eric van der Vlist <firstname.lastname@example.org> writes:
> On Wed, 2002-07-17 at 18:30, Henry S. Thompson wrote:
> > We could do that, but it would be wrong (in my view). Wrong because
> > it violates locality -- a barename link with name XYZZY is to what the
> > _target_ establishes as is its XYZZY ID, not the source.
> Can you clarify what you are calling the source and what you are calling
> the target?
Sorry not to be clearer, let me try to be as precise as I can.
*source*---An XML document containing an remote absolute http-scheme
URI reference (call this *ref*) which includes a (shortform) fragment
identifier XYZZY (call this the *idref*)
*user agent*---The application/machine which issues the GET request for
*server*---The application handling the GET request at the machine
identified by domain name part of *ref*
*target document*---The XML (i.e. the *server* believes it is of
mime type text/xml or application/xml or . . ., given any accept
header parameterisations sent along with the GET for *ref*)
document identified by *ref*, ignoring the fragment identifier part
thereof, as returned by the *server* in reply to the GET request
*TDI*---The representation of the infoset of the *target document*
constructed by the *user agent*
*intended target*---The element information item in *TDI* intended
by the author of *source* as the referent of *ref* (including *idref*)
*actual target*---The element information item in *TDI* identified
by the *user agent* as the referent of *ref* by interpreting
*idref* as a shortform xpointer
*supplementary resources*---Resources involved in the construction
by the *user agent* of the *TDI*. These may be indentified by
absolute or relative URI references. Other things being equal,
*ref* will serve as the base URI for relative URI refs. What these
are depends on the *target document* (obviously), the *user
agent*'s choice of processing done to construct the *TDI* --
minimal non-validating parsing, full validating parsing, complete
non-validating parsing (i.e. processes all referenced parameter
entities parsing) plus-or-not schema validity assessment, and the
environment in which the *user agent* operates.
So my basic argument is that since what counts as an ID, and therefor
what determines the *actual target*, depends crucially on the
*supplementary resources*, and therefor on the *user agent* and its
environment, that is user parameterisation/policy specifications,
catalogs, caches, proxies, etc., the *source* and *target document*
necessarily underdetermine the *actual target*.
> Not really. When I say that I want to access to anchor "boo" per the
> (X)HTML naming system, the rules are set by the server.
Um, you just went to some lengths to argue it was the *user agent*,
not the *server*, which interprets fragIDs -- why change now? The
only thing the *server* contributes are the resource as such and its
> > The _user_ does that by setting up the processing environment, in
> > either case.
> What do you mean?
I hope the clarifications above now make this clear. *User agents*
typically enable a wide range of user control over their behaviour,
and questions such as whether or not to validate, whether or not to
chase parameter entity references, whether or not to use a proxy, may
all be under user control. The proxy point is particularly important
-- if I am running without network access, the presence of absence of
a *supplementary resource* such as a DTD in my cache may well
determine whether my reference goes through or not.
So, bottom line: should we _also_ consider providing some _author_
input into the control of *supplementary resource* determination? If
so, where should it go and whose (i.e. which W3C REC's) job is it to
say how this works?
My answer: Yes, but not in the fragId and it's not the XPointer REC's
job. These questions are clearly the responsibility of XML Processing
Model REC (forthcoming, I hope), in my opinion. Note of course there
are typically at least _two_ authors involved, which is another reason
why putting it in the fragID is a bad idea.
Final note: the 99.99% case, for both DTDs and Schemas, is that all
sensible *user agents* will do the same thing, and it will be what
people expect, namely:
1a) If there's a DOCTYPE, process as much of it as you can get
access to looking for ID declarations, and use them during
parsing to identify possible anchors;
2a) If there's an xsi:schemaLocation attribute, use it to get a
schema doc and schema validity assess using it;
2b) Otherwise if the doc elt is in a namespace and there's a
schema doc accessible via the namespace URI, ditto.
People will chose their *user agents* just as they do now, namely on a
combination of ubiquity and functionality. Let's hope the market
decides XPointer functionality is useful and we get *user agents* that
do all three of the above.
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
W3C Fellow 1999--2002, part-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: email@example.com
[mail really from me _always_ has this .sig -- mail without it is forged spam]