Re: draft proposal for catalog resolution
I like most of this alot. I would certainly support it, and Peter's
simple (but less robust) suggestion as a second choice. One quibble:
Michael Sperberg-McQueen wrote:
> At user option, however, they must also support the
> mechanism described in this section.
> At user option, the XML processor must look first for a catalog file on
> the local system; the location of this catalog file, and the method of
> identifying it, are outside the scope of this specification.
These sound like we are specifying a bit of processor user
interface. I would remove the first "At user option" and change
the second from "At user option, the XML Processor must" to "the
XML may" -- who are we to say that Netscape (or whoever) must provide
a catalog escape route?
Let this be an area for market differentation. As long as the processor
faithfully tries to follow the instructions from the author, in the
remote catalog, its mechanisms for finding "better" instructions should
be unconstrained. It could be a remote catalog, a URN resolution service
or annoying popup dialog box. Let the market decide.