Re: Public Identifiers, and CATALOGS

Bill Smith wrote:
> 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. 

Except that URLs are addresses: "Uniform Resource _Locators_". URNs, on
the other hand, would be names. But they don't exist yet.

> An equally
> intelligent cache can be constructed using fpi:<fpi specific part>.

Sure, as long as you are willing to overload the same syntax to mean two
very different things. That wouldn't be such a problem if there weren't
other flaws in the proposal.
 
> 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.

Right. That's why you want both. Resolving clients use the name.
Non-resolving clients use the default location.
 
> Location independent namespaces are good things. PUBLIC is not required to
> have location independence.

You are right, we could do it in all kinds of different ways. We could
invent a whole new keyword PUBLICID. Why not do it the SGML way, though?
 
> We only need involve the IESG if we expect 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.

I didn't hear that consensus. Rather, I hear a strong proposal being
defined in the Grosso/McQueen corner.
 
> 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. 

Not true. I download SGML documents and their associated catalogs all of
the time. Interoperates well. I wish I had that feature for the HTML
documents I must maintain.

> I'd vote for one concrete mechanism as opposed to an
> infinity of abstract ones. XML should be concrete, SGML is abstract.

Some things cannot be concrete. Some things in XML are already not
concrete. The "processing" of an XML document is not concrete (i.e. what
it "does") because XML documents are supposed to transcend particular
technologies and technology changes. What does "BLOCKQUOTE" do? It does
one thing today, on my machine and another, tomorrow, on yours. Public
identifier resolution is exactly the same. It is supposed to transcend,
and behave differently depending on the needs of the person and the
technology that is available at the time.
 
> I hate to be obtuse but what's the point? Without a resolution mechanism
> the SYSTEM ID will always be used. 

Not at all. There will be resolution mechanisms. There may or may not be
a resolution mechanism defined by this group, but there will be
resolution mechanisms. I've just described one I use, catalogs. Peter
Murray-Rust outlined the "Usenet" resolution mechanism a few days ago.
Jon Bosak outlined the client/server resolution mechanism he is
envisioning at Sun a long time ago.

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

Well, if you make it impossible to specify a fallback address then you
can guarantee a "404". It seems odd to me that to save a single
production in the grammar we would consign ourselves to blocking a
gentle upgrade path to a feature that people are already using. If you
make PUBLIC/SYSTEM an either/or choice with no resolution mechanism then
you've certainly consigned PUBLIC to the bit bucket of history. Nobody
wants to break all of the "current" (in a year) browsers in order to use
a new PID resolution feature offered by one of the vendors.

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

If you think that the only reason PUBLIC identifiers is being added to
XML is because it is easy, then I don't think you've listening to those
who have been "clamouring" for it. There are many features that are easy
to do that have been left out with much less noise.

 Paul Prescod

Received on Tuesday, 1 April 1997 17:42:42 UTC