[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Conflict resolution in catalog files

• From: John Cowan <cowan@l...>
• To: XML Dev <xml-dev@i...>
• 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
over.

-- 
John Cowan	http://www.ccil.org/~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: http://www.lists.ic.ac.uk/hypermail/xml-dev/
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...)

• References:
  • Conflict resolution in catalog files
    • From: Lars Marius Garshol <larsga@i...>

• Prev by Date: Re: [Q] How should SAX support Namespaces?
• Next by Date: Re: IMB xml for java parser and printing entities
• Previous by thread: Conflict resolution in catalog files
• Next by thread: Expat for Japanese encodings
• Index(es):
  • Date
  • Thread