semantics of delegating system ids [was: Proposal for XML syntax forcatalogs]

[Paul Grosso <pgrosso@arbortext.com>]

At 18:14 2000 12 13 -0500, Norman Walsh wrote:
>/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
>| >  <delegate idPrefix="urn:oasis:member:ndw:"
>| >            catalog="http://nwalsh.com/catalog"/>
>| 
>| I've got a problem here--same one as I've expressed several times.
>| URN's where, used as what, in what context?  Public IDs or System IDs?
>
>Oh, barf. You're right. Hmm. I only want this for system or public
>identifiers, so may be we can do this:
>
>  <delegate systemIdPrefix="xxx" publicIdPrefix="yyy" catalog="zzz"/>

Would this be completely semantically equivalent to
  <delegateSystem prefix="xxx" catalog="zzz"/>
  <delegatePublic prefix="yyy" catalog="zzz"/>
(assuming the obvious semantics of those two elements)?  If so, I
think I can live with that syntax--provided we can figure out the
semantics of either syntax, which is what the rest of this message
is about.

In either of those two syntaxes, I'm wondering about things like
what you do when the external identifier you're resolving is:
  PUBLIC "yyy-stuff" "xxx-otherstuff"
and your catalog contains:
  <public publicId="yyy-stuff" uri="www"/>
  <delegate systemIdPrefix="xxx" publicIdPrefix="yyy" catalog="zzz"/>
both with override on and off.  With override on, do you end up
using uri="www" or do you run off to catalog zzz?  (Note that, if
you had a matching SYSTEM entry, you would use that regardless of
the OVERRIDE setting, you would never use the PUBLIC entry.)  With 
override off, do you use "xxx-otherstuff" or do you end up going to 
catalog zzz (which raises another question I handle later--see "The
other issue..." below)?

Now what if your catalog contains:
  <public publicId="yyy-different-stuff" uri="www"/>
  <delegate systemIdPrefix="xxx" publicIdPrefix="yyy" catalog="zzz"/>
what do you do in both override cases?  Probably the key issue here
is that TR9401 defines the order of match specificity to be:

   1. SYSTEM type entries;
   2. PUBLIC type entries;
   3. DELEGATE entries ordered by the length of the prefix, longest first;

where DELEGATE means delegation of Public ids.  So exactly how do
we fit in delegation of system ids?

The other issue is what it means to use a delegated catalog when
delegating system ids.  Again, TR9401 says:

  If this catalog entry file produces any such matches, the
  right hand side of all such matching entries are used, in
  order from longest partial public identifier match to shortest,
  to generate a new complete logical catalog (i.e., a newly specified
  list of catalog entry files) that replaces the current catalog.

  The catalog lookup process for this entity continues with this
  new (replacement) catalog, ignoring for the purposes of this entity
  any other entries in the current catalog entry file as well as any
  subsequent catalog entry files that may have been part of the
  previous list of catalog entry files. This newly defined catalog
  is then processed in much the same manner as if it had been the
  originally specified catalog; however, only the entity's public
  identifier is considered as the information available for lookup--its
  entity name and system identifier (if any) are not available during
  lookup in any “delegated to” catalog.

So once we decide that we're delegating the resolution of a system id,
are we going to follow the analogous process?  Are we going to ignore
the rest of the catalog entry files and are we going to ignore the 
PUBLIC id when searching the "delegated to" catalog entry files?  At 
what point do we decide that we haven't found a match at all, and what 
do we do at that point (presumably, use the original system id, I think)?

We might be able to work this out, but there are several tricky bits
to be addressed, and we need to address them carefully so that we
don't ambiguate the whole catalog resolution process defined in TR9401.

paul