Re: the return of the Public Identifier Question

> The idea of trying both in any order is fine if all you're trying to
> do is provide alternative resolutions to *equivalent* storage objects;
> that is, you are just trying to avoid "broken references," and any
> successful reference is equally acceptable.  

I think that it is just a logical error to have the public identifier and
system identifier point to non-equivalent storage objects. It is as if I 
sent a letter to ArborText to "Paul Grosso's office" and "[whatever room 
number you work in]" and they went to two different people. That shouldn't 
happen: names refer to logical objects, with potentially multiple addresses,
not multiple logical objects.

> But I do not see option
> (d) as working if you agree that an important reason for PUBLIC ids
> is to allow recipient/user level control over resolution.

I do not think that this is an important use for public identifiers, though
I admit that it is sometimes useful, for instance to include a set of user
modifications to a standard DTD.  I consider this a useful, common abuse
of the public identifer mechanism. You can reliably continue this practice
by deleting the system identifier. This will have the added benefit of 
requiring the user to specify the modifications or to specify that there are
none. If you want to specify a default, put it in the catalog.

 Paul Prescod

Received on Wednesday, 19 March 1997 18:46:25 UTC