Re: public/catalog [was: Re: ERB Decisions of March 26th]

> If you go to
> your local bookseller and ask for a copy, he is not required by
> antient custom to write a letter to the address of the original
> publisher as it was at the time of publication, or even to have
> on hand the quill pen, penny stamp, and original address he would
> have used to order a copy when the book was first published. 

Terry, although I think PUBLIC is an unnecessary feature in XML,
bloating a language already much larger than it should have been,
even I don't buy this argument.

XML can be revised long before 50 years are up.

If it turns out that by some horrible mistake, PUBLIC is incorporated,
and later we want to use URNs, and then discover that (perhaps) you
can't put a URN in a PUBLIC Id because it uses characters not
allowed in a minimum public literal, or for whatever other reason,
we will have to change XML.

> The catalogue mechanism can be recommended as a means user agents
> might want to employ to determine what URL the publisher intends
> his PI to resolve to *at the time of publication*.

But if that was all, they could simply put the URLs in the documents,
using a CGI-script transformation if necessary.

And on the Web, if mechanisms change, why, you are _still_ the publisher,
and you can change your catalog, or replace it with a frobnitz, and
what's the problem?

> [...] mandating support for catalogues (rather than recommending
> support for them as sets of URN hints) doesn't ensure that PIs can be
> resolved indefinately.  NOTHING CAN DO THAT.

So if nothing can do it, let's not worry about it.
The question then becomes, what's a good compromise.

As far as I am concerned, SYSTEM with URLs is a good compromise.

Lee

Received on Saturday, 29 March 1997 21:55:09 UTC