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
>endorse.

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
URNS.

    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.

   -- David


I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Monday, 2 December 1996 16:02:00 UTC