W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > December 1996

Re: Client-side-resolved Indirection

From: David G. Durand <dgd@cs.bu.edu>
Date: Mon, 2 Dec 1996 16:07:33 -0500
Message-Id: <v02130500aec8e9d8c7be@[]>
To: W3C SGML Working Group <w3c-sgml-wg@w3.org>
Cc: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:20 UTC