OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Conflict resolution in catalog files

[ Lists Home | Date Index | Thread Index ]
  • From: John Cowan <cowan@locke.ccil.org>
  • To: XML Dev <xml-dev@ic.ac.uk>
  • Date: Mon, 27 Jul 1998 11:56:37 -0400

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	http://www.ccil.org/~cowan		cowan@ccil.org
	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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS