(Sorry to be so late in submitting this. I'm having connectivity problems, which means that all email has to be transferred by floppy to my work computer.) * Lars Marius Garshol | | 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. * John Cowan | | 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".) It turns out that you're right. CATALOG entries weren't in TR 9401 originally, but I now see that they have been added later. What confused me was that they weren't mentioned in the conflict resolution part, but rather were defined on their own. Still, it seems that even with the CATALOG entries, TR 9401:1997 is compatible with my original wording. (Although that may not have been entirely obvious from the text.) | [...quote of my proposal snipped...] | | 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. I agree, and that's the same as in my proposal. Look at it again: all Maps are processed before any Delegates. The order within the catalog is the last sorting criterion. Maybe the bit about catalog file origin (sort criterion 1) confused you? That part is there to take care of the CATALOG entries and the cases where multiple catalog files are given to the parser. (nsgmls accepts a semicolon- separated list of catalog files.) * Lars Marius Garshol | | (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.) * John Cowan | | 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. I'm uneasy about it myself, for exactly the same reasons, but I think that this will sometimes be needed, especially with DTDs. What if you're parsing a document retrieved over HTTP and it uses an explicit SYSTEM literal to refer to a DTD, also with HTTP, only the DTD URL just gives you a 404? Or you want to use the DTD modified with architectural forms declarations, or modified in some other way? | 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. No, it is not really incomplete in this regard, although perhaps this should be covered a little more explicitly. Imagine the following catalog: DELEGATE "-//W3C//DTD HTML" htmlcatalog PUBLIC "-//LMG//Article DTD//EN" "egne\article.dtd" PUBLIC "-//W3C//DTD HTML 3.2 Final//EN" HTML32.dtd Sorted, these entries come out as: PUBLIC "-//LMG//Article DTD//EN" "egne\article.dtd" PUBLIC "-//W3C//DTD HTML 3.2 Final//EN" HTML32.dtd DELEGATE "-//W3C//DTD HTML" htmlcatalog This means that if you try resolving "-//W3C//DTD HTML 3.2 Final//EN" you'll get "HTML32.dtd", and not be referred to the "htmlcatalog" catalog file. If you try resolving any other FPI starting with "-//W3C//DTD HTML" you'll be referred to the htmlcatalog. Still, if you misunderstood me I think the wording should be expanded somewhat to remove the problems: ---New proposal: 7. Conflict resolution When more than one catalog entry applies to an entity, the conflict can be resolved by using the entry that comes out first when the entries have been sorted in the order specified below. Entries from catalog files referred to by DELEGATE entries are excluded from this sorting process. If a DELEGATE entry is chosen as applicable the process is repeated with the entries gathered from the delegated catalog file. Entries are sorted by (in this order): 1) By catalog file, in the order the catalog files were processed, reckoned by when processing of the file started. CATALOG entries are to be processed in a depth-first order. 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 The conflict resolution in XCatalogs and SGML Open Catalog files (as defined in TR 9401:1997) is 100% compatible. [Perhaps this is better off in a dedicated section that describes the differences between these two proposals?] --- End of proposal -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ 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...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format