Altova Mailing List Archives

Re: Conflict resolution in catalog files

From: John Cowan <cowan@-----.----.--->
To: XML Dev <xml-dev@--.--.-->
Date: 7/27/1998 5:57:00 PM
Lars Marius Garshol wrote:

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

I have no problem with this in principle.

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

How's that?  This is no extension: it is documented right in
9401:1997.  (Unfortunately, there are neither clause numbers nor
HTML anchors in that document, but search for the string "The CATALOG
entry can be used".)

> 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

AFAIK the only difference (modulo System) is that Maps are always
processed before Delegates within a single catalog even if the
Maps physically follow.  This is probably a good rule.

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

I still have problems with this, as it violates referential
transparency.  It means that the processor of a document can
change the content of the document based on a catalog entry,
and independent of the author's declared intent.
> The reason I propose this is that the new wording is more concise,
> and, I think, easier to understand.

I take your point, but it is incomplete, specifically in the
matter of what to do when a Delegate entry is accepted: discard
the rest of the current catalog *and* the entire queue, and start

John Cowan		cowan@c...
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as:
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.