[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: agenda for ER TC teleconference 20010507
/ 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC