Re: agenda for ER TC teleconference 20010507

[Norman Walsh <ndw@nwalsh.com>]

/ jcowan@reutershealth.com was heard to say:
| Norm says that system ids are system ids, and public ids are public ids, and
| never the twain shall meet.  And fundamentally I agree.  But there is an
| exception, which after all is the point of the Kipling poem!
| 
| (See http://www.geocities.com/Athens/Aegean/1457/poem3.htm)
| 
| The W3C culture, frankly, is hostile to public ids.  They aren't part of 
| Web architecture, as has been said several times both publicly and privately.
| The whole purpose of our creating publicid URNs is to be able to smuggle
| public IDs into the W3C system, and then get them processed through existing
| catalogs.

The purpose was certainly to get public identifiers into the web
architecture, but I'm not sure that we have to subvert any existing
semantics to achieve that. Let's consider some of the use cases:

  <xsl:import href="urn:publicd:-:Norman+Walsh:xsl+DocBook+XSL+V1.37:en"/>

and similarly:

  <book xsi:noNamespaceSchemaLocation="urn:publicd:-:OASIS:xsd+DocBook..."
        xmlns:xsi="...">
  ...
  </book>

In both of these cases, the URN is a "URI", and so it matches the URI
catalog entry. System or public never comes into the picture.

(Actually, it occurs to me now that you might be suggesting that
urn:publicid:... is a public identifier even in these cases.)

The only place that public/system entries are relevant is when the
XML 1.0 declarations are used:

  <!DOCTYPE book PUBLIC "urn:publicid:..."
                        "http://...">

In this case, the URN is a public id and the http: URI is a system id.
No problems there.

So the only place where your suggestion that urn:publicid: is a public
identifer would arise is this:

  <!DOCTYPE book "urn:publicid:...">

or

  <!DOCTYPE book PUBLIC "-//..." "urn:publicid:...">

(and for <!ENTITY declarations as well).

This would lead to declarations that had no system identifier. That
strikes me as a bad thing. And a thorny argument for opponents to the
use of public identifiers to use against the urn:publicid scheme.

I guess my arguments come down to this:

1. This special case isn't actually necessary. One can use URI and SYSTEM
   entries in the catalog to perform whatever mapping is desired. The
   advantage of the urn:publicid: scheme (to me) is that it is (1) obviously
   a name and not an address and (2) brings the concept of public identifiers
   into the web architecture.

2. Special casing urn:publicid: is an invitation for future URN (or
   other identifier schemes to request or demand special cases). I don't
   relish the thought of urn:systemid: always being interpreted as a system
   identifier or 'xyzzy:bar' always being interpreted as a URI, regardless
   of where it occurs.

| By doing that, for example, we can give an XML Schema a public id, and then
| reference it through an xsi:schemaLocation hint of the form urn:publicid:*.
| By translating this URI to a public id, it can be looked up in a
| public-id-based catalog, which eventually delivers a local or remote URI.

Although I still think it's a bad idea, my resistance is weakening. There
would be a certain perverse pleasure in making xsi:schemaLocation actually
contain *public identifiers*. :-)

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@East.Sun.COM    | If someone tells you he is going to make
XML Standards Engineer       | 'a realistic decision', you immediately
Technology Development Group | understand that he has resolved to do
Sun Microsystems, Inc.       | something bad.--Mary McCarthy