Re: ERB discussion of public identifiers

At 12:05 PM 12/11/96 -0800, Tim Bray wrote:
>Input, please.

Sorry for the long-winded response...

I would like to see a 3b type spec for PUBLIC, which I characterize as:
hand-wave about name resolution schemes, and allow a range of
implementations consistent with common Web and SGML practices.  I would
like to see some recognition of catalogs, FPIs, and URNs, without requiring
them.

I'm swayed by all the arguments for allowing PUBLIC in XML.  I see no
compelling argument against full support per 8879-1, if we allow systems to
assume "FORMAL NO" by default in the SGML declaration. This only requires a
validating system to report an error if a PUBLIC ID is not a minimum
literal.  Authors and processing systems are free to interpret IDs as they
see fit. 

On further reflection I believe that, in the interest of fostering the
deployment of name resolution schemes for the Web, the XML spec should
*recommend* that URL syntax be used for SYSTEM IDs, and URN syntax for
PUBLIC IDs.  The common naming schemes are relatively easy to explain, and
parsing IDs is trivial.

The message to implementors is forward looking: XML (the language) does not
require recognition or handling of URNs and FPIs, but *does* encourage
their use.

The message to Web publishers is very positive: XML supports a useful
feature for interchange with name resolution systems, and XML will scale
better than HTML as industrial strength naming schemes come online.

To make this work the spec should provide some concrete examples. The
example should be placed in context with real world problems, and should
employ naming schemes that are known to work (URL, FPI, ISBN). 

So we may not offer a formal specification of PUBLIC and SYSTEM IDs for the
Web, but we can enable everyone in the Web community to recognize them when
they see them.

This approach strikes me as a reasonable balance among realism, political
correctness, and functionality. It recognizes an important mechanism for
name resolution, but does not impose undue hardship on implementors. No
authors are forced to use them; no implementors are forced to parse them.
And of course customers and vendors will work things out in the marketplace.

/kmc

Received on Wednesday, 11 December 1996 17:41:19 UTC