Re: Proposal for XML syntax for catalogs

[Paul Grosso <pgrosso@arbortext.com>]

At 15:18 2000 12 13 -0500, Norman Walsh wrote:
><catalog override="yes">
>  <public publicId="xxx" uri="yyy"/>
>  <system systemId="xxx" uri="yyy"/>
>  <catalog override="no" xml:base="absURI">
>    <delegate idPrefix="xxx" catalog="yyy"/>
>    <public publicId="zzz" uri="yyy"/>
>  </catalog>
>  <import catalog="yyy"/>
></catalog>

While I don't feel strongly, if we are going to "standardize"
on "uri" for the righthand side, I don't see why we don't also
do that in the case of delegate and catalog.

I don't like using <catalog> for the grouping element's name.
First, in TR9401, CATALOG means what you're using <import> to
mean, so using <catalog> to mean something else is unnecessarily
confusing.  Also, the *only* semantic of this element as you're
using it is to scope override and xml:base, so using the word 
"catalog" seems to imply semantics that aren't there.  

I have two, different, suggestions (and I'm not sure which one
I prefer at this time):

1.  use some fairly semantic-free name such as <group> or <div>
    or <scope> for the scoping tag.  We can either:
  a.  use that same name--whichever we choose--for the top level
      element or 
  b.  we can use <catalog> for the top level despite
      choosing a different name for the grouping tag.

2.  Finesse both this scope-element issue and the import issue
    by defining the <catalog> element to have both functions.
    That is, the catalog element would either have a uri attribute
    that pointed to a catalog to import--in which case it should
    contain no content--or it would have content--in which case its
    uri attribute should not be assigned.  (Alternatively, we could
    allow both a uri and content and define what this means--it would
    sort of be like a doctype decl with both an internal and an
    external subset.)  One thing I like about this is that both
    cases effectively define a scoping for both override and xml:base
    (since both are scoped when importing a new catalog file), and
    this way I don't mind using the name "catalog" since semantically
    it is doing more than just grouping--in fact, its semantics include
    the semantics of TR9401's Catalog entry.

>I know that 'import' is contentious.
>
>I used 'idPrefix' (which I don't think is great) on delegate instead
>of 'partialPublicId' because I see delegate as being useful for URNs
>as well:
>
>  <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?

TR9401 defines Delegate semantics in terms of public identifiers.
As I've said before, if you also want to be able to delegate for
system ids, then we should have both delegatePublic and delegateSystem
entry types.  Then, the "lefthand side" for the former would be
publicId and for the latter systemId, and both would work fine
for URNs.

Implementing my second suggestion with regard to scoping and
the one above for delegate (and using "uri" for all rhs attribute
names), I'd rewrite Norm's example as follows:

<catalog override="yes">
  <public publicId="xxx" uri="yyy"/>
  <system systemId="xxx" uri="yyy"/>
  <catalog override="no" xml:base="absURI">
    <delegatePublic publicId="xxx" uri="yyy"/>
    <public publicId="zzz" uri="yyy"/>
  </catalog>
  <catalog uri="yyy"/>
</catalog>


paul