Re: XML catalog draft
> The collective information about all the components necessary to
> handle, process, identify, etc. this document--the meta-document--is
> the first-class construct. The meta-document is the starting point.
Fine. This is roughyl equivalent to the 2 MIME-SGML solutions, where
one focused on the catalog as the meta-document, and the other
focused on MIME structures.
A meta-document is just a packing list, as is a catalog. Catalogs
should only be used to identify peices in a given document, not
for the basis for name resolution.
>1. It is possible to define a known document type to encode such a
> meta-document. This is not necessary but it would seem unlikely to
> developed "yet-another-document-information-encoding" (YADIE).
We already have MIME and catalogs.
>2. The meta-document and its components could be encoded in one stream
> such that a request is made for the meta document "stream" and
> all information is shipped to the application. This does *not*
> require that all components are packed into this stream. It only
> requires that they be identified. Anyone familiar with the concept of
> JAR files can see where this is coming from.
Sounds like MIME to me....
>4. The need for "catalog location", "style-sheet location", etc. standards
> goes away and gets replaced with a uniform mechanism for describing
> component locations and relationships.
Sure, instead of pulling the catalog in after accessing the instance,
you pull in the instance after accessing the catalog.
>I have attached a very simple DTD for such a meta-document. I wrote this
>very quickly and it *doesn't* contain all the ideas that I have about this
>subject but I wanted something concrete.
Some people on this list know that I have little love for the SO
catalog syntax, but that seems sufficient to me.