Re: Public Identifiers, and CATALOGS

David Durand wrote:

> My note pointed out that even without a resolution mechanism for PUBLIC IDs
> the fact that they are _defined_ as names for unique entities allows
> smarter caching behavior. This is because knowing that something is a name
> is useful information.

The scheme specific part of a URL can be a name. To my knowledge nothing
precludes defining the scheme specific part of a URL as a name. An equally
intelligent cache can be constructed using fpi:<fpi specific part>.

> And of course it's not at all unhelpful to be able to give a name, and a
> default location in case the client cannot process the name. This last is
> what allows non-resolving clients to get benefit from PUBLIC. I can see the
> pragmatic reason to specify URLs, but I see real advantages to having a
> location-independent namespace. I think being able to specify PUBLIC and
> SYSTEM both gives us this with very little trouble. We're about to add
> CONCUR to XML, and people are complaining about the burden of implementing
> PUBLIC!???!! Give me a break.

I don't understand how a default location enables non-resolving clients to
get benefit from the name, which they don't understand. The benefit is
received from the default location which is all they understand.

Location-independent namespaces are good things. PUBLIC is not required to
have location independence.

CONCUR added to XML? Maybe today but not tomorrow. (It is April 1.)

> One problem is that we would have to submit a _resolution_ protocol to the
> IESG, thus defeating the _purpose_ of FPIs. We could use URNs, but since
> the draft specified URL and not URI, that is only open to those who don't
> care about conformance -- and in that case, why not implement PUBLIC and
> get more SGML compatibility coupled with more functionality?

We only need involve the IESG if we expet FPIs to interoperate. This is a
red herring since (as best I can tell) the list has reached consensus on
resolution interoperability - there won't be any. 

> One problem is that it will be _only_ one mechanism once it's defined. That
> violates one of the desired properties of FPIs. (resolution-mechanism
> independence)

One resolution mechanism that works for (one or more) location-independent
namespaces would be preferable to many abstract resolution mechanisms. For
10 years we've had PUBLIC and yet we still don't have a single mechanism
that interoperates. I'd vote for one concrete mechanism as opposed to an
infinity of abstract ones. XML should be concrete, SGML is abstract.

> We don't get a fallback SYSTEM ID. When I suggested this previously (about
> 4 months ago), I pointed out that to make it equivalent, we'd have to
> change SYSTEM to a _list_ of alternative URIs. This gives us all the
> advantages you are claiming, and would be acceptable to me....

I hate to be obtuse but what's the point? Without a resolution mechanism
the SYSTEM ID will always be used. So why bother? Only consenting PUBLIC
applications using some as-yet-undefined resolution mechanism to locate
named objects will understand FPIs. The rest of us will be left with 
"404 Not Found" because (I suspect) fallback XML objects will be 
maintained about as well as HTML pages.

I'm sure PUBLIC will be added to XML because "it is easy to do". 
Unfortunately, that's almost always the wrong reason to allow a feature
to creep in. I'm not convinced PUBLIC is required and suspect that it will
be (for the most part) ignored. If we persist in adding features that will
be ignored, we can predict the fate of XML.

Received on Tuesday, 1 April 1997 15:56:57 UTC