Conflict resolution in catalog files

[Lars Marius Garshol]

I've now researched how conflict resolution works in SGML Open
Catalogs and want to propose a new wording for the XCatalog proposal
section 7 based on this. The CATALOG extension to the catalog file
format means that TR 9401:1997 can't be followed directly, since it
does not have this entry. Instead, the handling of multiple catalog
files is based on the (extremely terse) description of how nsgmls
handles this.

This is the proposed wording:

--- BEGIN PROPOSAL

7. Conflict resolution

When more than one catalog entry applies to an entity, the conflict
can be resolved by using the entry that is comes out first after the
entries have been sorted in the order specified below.

Entries are sorted by (in this order):

  1) By catalog file, in the order the catalog files were processed
  2) By the entry type (in this order):
     a) SYSTEM   (Remap) 
     b) PUBLIC   (Map)
     c) DELEGATE (Delegate)
  3) The order in which the entries appeared in the catalog file

--- END PROPOSAL

(NB: The SYSTEM/Remap entry is not present in the original proposal,
but I think it should be included. The functionality it provides was
part of what the PubIdResolver interface of SAX was supposed to
enable.)

The reason I propose this is that the new wording is more concise,
and, I think, easier to understand. Another benefit is that this
wording is compatible with both TR 9401:1997 and the way nsgmls
handles conflict resolution. (Provided I understood James Clarks
explanation correctly.)

--Lars M.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)