Re: the return of the Public Identifier Question

> From: Paul Prescod <papresco@csclub.uwaterloo.ca>
> 
> > 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.

I was VP of Engineering at ArborText about 4 years ago.  Most bulk mail
that currently gets addressed to:
	Paul Grosso
	VP of Engineering at ArborText
(and a lot still does!) should and does get rerouted locally (by some
effecient adminstrative folks) to Mike McEvoy who is the current VP of 
Engineering.  It should not get sent to me, despite the fact that the
"system id" of Paul Grosso is still a valid identifier.

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

I strongly disagree.

> You can reliably continue this practice by deleting the system identifier. 

No, the reader of a read-only document can do no such thing.

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

Yes, one can add something like the OVERRIDE entry to the catalog.
This is one way to implement my choice (g) which says to require 
that there is some way for the user to specify which to try first
(so that the user can specific that PUBLIC should be tried first).

But I'm not going to be the one to suggest we complicate the XML catalog.

paul

Received on Wednesday, 19 March 1997 19:25:29 UTC