No subject

[Lars Marius Garshol]

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