RE: Simple solution? Pub. Idents. vs URN.

At 12:35 PM 11/29/96 -0500, Martin Cottreau wrote:
>There are applications of XML that don't require FPIs, the biggest one
>simply being a replacement for HTML, so people will stop putting
>processing information in comments.  It's not all singing and all
>dancing, but simple XML with URL (for now...) and style sheets
>would solve a lot of people's problems right now.

And how would an optional FPI extension to the syntax change that?

>I agree we have to consider what impact not having FPI will have,
>but my gut feeling is that a) the ERB has already done this before
>deciding to drop them in the first place and b) the Web will
>evolve towards some sort of FPI mechanism. 
>(wasn't that the point of the original e-mail in this thread?)

The Web's FPI mechanism under development is explicitly designed to support
namespaces like "FPI:", and to "grandfather in" any existing namespace
(phone numbers, license plates, ISBN numbers, FPIs, etc.) In other words, we
can put Public Identifiers in the standard today, or put an identical
construct in a year from now, and in the meantime, the people who are
already using them in the SGML community will be without them, for no good
reason.

All I am asking for (and I *think* that this is what other are asking for)
is a "hook" for public names, not a standard for how to resolve them.

>We shouldn't try to redefine addressing on the Web: it's clear there
>are other activities within the W3C which may solve the problem.

I am not trying to redefine addressing on the Web. FPIs are for use *off of*
the Web. They are for internal systems, and inter-company systems, for user
groups and application groups. Every document that is published on the Web
should have URLs with the FPIs.

>We have to concentrate on making XML easy and useful.   According
>to Jon we only have a six month window to just get a new markup
>language out there.  

I'm not sure what is so special about the next six months, but I highly
doubt that an extra paragraph in the spec about an optional, non-parsed,
black-box-string, ignore-it-if-you-don't-understand-it string would slow us
down much. Think of it as an "addressing processing instruction".

>On FPI, I hope we punt.

SGML punted on FPIs 10 years ago. It made them optional, and made the
mechanisms for resolving them optional and system-specific. That was the
right decision then, and it is the right decision now. The fact that people
are using them successfully is evidence enough that they are right, and
there is *never* a case where the existence of a public identifier makes the
parsing or use of a document harder.

 Paul Prescod

Received on Friday, 29 November 1996 16:58:08 UTC