Re: XML catalog draft
On reflection, and although I agree with pretty well every word in
the XML catalog draft, and think it's a fine piece of work, I cannot support
its inclusion in XML. Background:
1. We left out PUBLIC originally because we didn't want to bless
a syntax (e.g. FPI or URN) or a resolution mechanism. Making
everything a URL had the virtue that it works.
2. People said they wanted PUBLIC. Michael asked: "even without a single
resolution mechanism?" Several, most eloquently Deb Lapeyre,
said "Yes." I for one (and I think most of the ERB) could find
no good reason to resist this desire.
3. The recent draft blesses a resolution mechanism (Socats) which it
specifies at some length, in a process that encodes a lot of design
decisions (DELEGATE/CATALOG, prefix rules) very compactly, but does
not really provide a solution to find the catalog. I think the
design decisions are good.
What bothers me is:
a. The length and complexity of the discourse on catalog usage; I think
the XML spec should be shorter, not longer.
b. The fact that this discourse overlaps with TR9401; I think that we
should avoid rewriting parts of other specs; with the obvious exception
of ISO 8879. We do not do this with URLs, for example.
c. The fact that some but not all of TR9401 is here; notably missing is
the find-the-catalog logic. Are the parts of 9401 where there is
overlap guaranteed not to change? Are the parts of 9401 that are
omitted notably lacking implementations?
I think we should:
- allow a PUBLIC keyword/string as appropriate
- make a decision as to what should be done when both PUBLIC and SYSTEM
- provide a pointer to TR9401 in the write-up on the PUBLIC identifier,
saying that this is one proven-in-practice way to resolve them
- provide support to catalogs by providing a special PI, as recommended
by a couple of WG-ers, to help define the BASE and thus find the
- investigate the problem of what seems like the unnecessary
restrictions on MINIMUM LITERAL; I don't think it's legitimate to
say that a PUBLIC identifier can't be a URN, which this would do.
I'm not sure what the right thing to do is with the current
catalog proposal. It seems to represent the best thinking of the people
who know on how to get good mileage out of Socats; it would be a
pity to lose that. But at the time it just doesn't seem like a good call
to wire this into XML.
Cheers, Tim Bray
firstname.lastname@example.org http://www.textuality.com/ +1-604-708-9592