Re: agenda for ER TC teleconference 20010507

[John Cowan <jcowan@reutershealth.com>]

Norman Walsh wrote:


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

Indeed, I did mean that, though I didn't say it.

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

Now this is a case which I hadn't thought about.  You are suggesting that
when a string of the form "urn:publicid:*" arrives *as* a public identifier,
as opposed to a system identifier or a URI, it should also be unwrapped?
Sounds good to me.

> So the only place where your suggestion that urn:publicid: is a public
> identifer would arise is this:
> 
>   <!DOCTYPE book "urn:publicid:...">

This is the main use case, along with the URI cases above.
 
> or
> 
>   <!DOCTYPE book PUBLIC "-//..." "urn:publicid:...">

Now I admit that this one is problematic.  Under my interpretations,
this declaration does have two public identifiers, and it is not clear
which one should prevail.  However, since an XML catalog processor is
always permitted to fail and return the system identifier (hopefully
for some other URN resolution mechanism to deal with), I am willing
to say that in this case the urn:publicid:* should not be specially
handled.

> 1. This special case isn't actually necessary. One can use URI and SYSTEM
>    entries in the catalog to perform whatever mapping is desired.

But at the expense of losing backward compatibility with 9401, which
provides facilities

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

But this is a special case that we concocted ourselves; we can successfully
resist special cases concocted by others.

(How about urn:url:<any URL>?  :-))

> 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*. :-)

Sure.  It's protocol tunneling.

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein