Re: agenda for ER TC teleconference 20010507

[Paul Grosso <pgrosso@arbortext.com>]

Basically, the catalog entry types are designed to indicate what
the input is, not how to treat it.  The reason for SYSTEM and PUBLIC
entry types is because, in XML 1.0, you may have one or the other or
both, and you need to know which is which to be able to execute the
algorithms that are defined to do catalog lookup.

There is no reason to pervert this by looking inside a SYSTEM string
and deciding it's really PUBLIC.  Now that we can do delegation on
SYSTEM, there is no advantage to being able to pretend that a SYSTEM
id is a PUBLIC id, and certainly no advantage to pretending that an
arbitrary URI is anything but a URI.

At 09:55 2001 05 07 -0400, Norman Walsh wrote:
>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:...">
                  ^
               SYSTEM

Without "SYSTEM", your declaration isn't valid.  And once
you put in "SYSTEM", it makes it pretty clear that treating
it as a public id is wrong.


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


Why, there is no advantage.  The Schema group has on its list of possible
additions our issue, and we can also invent an OASIS xsi: sort of thing
if we want (though I'm not sure I do at this point).

In my view, whether something is a SYSTEM or PUBLIC id depends solely
on which XML 1.0 production that string satisfies.  That is the point
of the different entry types.  If there is a use case that we are trying
to solve here, let's solve it within the realm of our catalog lookup
semantics, not by pretending thata string matched a different XML 
production than it really did.

paul