Altova Mailing List Archives
>xml-dev Archive Home
>Recent entries
>Thread Prev - Conflict resolution in catalog files
[Thread Next]
Re: Conflict resolution in catalog files
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 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...)
Disclaimer
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 www.altova.com/list/index.html. 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.

