Re: Client-side-resolved Indirection
At 12:04 PM 12/2/96, Michael Sperberg-McQueen wrote:
>On Mon, 2 Dec 1996 12:35:15 -0500 Paul Prescod said:
>> ... You've hit the nail on the head in a couple of respects. First,
>>document *authors* should not care about the resolution mechanism of
>>document *consumers*. They should be totally independant.
>As an author or publisher, I don't care about the mechanics; I do
>care, rather a lot, about ensuring (a) that the document consumer can
>actually resolve entity references and (b) that when they do, they
>get the right thing. Specifying a method of resolving FPIs seems to
>make those guarantees; specifying FPIs without a defined method of
>resolution seems to make neither guarantee. That's a level of
>independence between publisher and reader which I am not prepared to
But it is one that is essential. There can be no _single_ resolution
protocol for names, otherwise, they are simply locators, in the sense that
the protocol is hardwired -- and it deterministically yields a location
given a name. Names are useful for the cases where you want to be able to
look things up.
But let's be concrete for second: SGML allows PUBLIC without a system
identifier: I am not proposing that; It is an adequate compromise that it
even be _possible_ to have a public identifier in addition to the system
ID. In this case, a public identifier is a way that an individual (or a
motivated client) can safely change system IDs with confidence that the
same resource is being addressed. No resolution mechanism required. We can
accomodate the desire for a resolution mechanism by specifying (in advance
of deployment) that FPIs should be resolvable via the FPI grandfathering of
Alternatively, we can specify that PUBLIC will not be allowed, but that
a URN can be included as (or in addition to) a URL. If we propose an
experimental syntax for FPI-urns, that would be enough to enable interested
XML applications to detect their use, and do our best to make sure that it
becomes a standard (this would be pretty easy, I think). In this case, we
must have a way to specify multiple URIs so that a "plain old URL" can also
be provided, for the naming-impaired.
>Not that I know of. Version 3.2 of HTML did not exist before the advent
>of SGML Open catalogues; the entity sets did, but I don't believe I ever
>downloaded SGML documents from the Web at that time; when on occasion I
>got SGML documents from other people, working with the DTD subset to
>make my SGML systems find the entity sets was just part of the job of
>getting the files to parse.
And this has always been a serious problem. We could enable off-line
browsing of cached XML documents simply by specifying that PUBLIC IDs are
guaranteed-good cache-keys. This is at the least more difficult with HTTP,
as you need to do at least a HEAD to be sure that you have the correct
version of anything.
It's also easier and friendlier to prompt a user for the location of a
public identifier than for a random URL. This is also more likely to be
implemented, since implementors will be aware that there might be a
possibility of manual resolution of FPIs -- since this is almost never the
case for URLs, the option is an unlikely one to offer.
I am not a number. I am an undefined character.
David Durand email@example.com \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________