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.

Received on Monday, 10 February 1997 09:52:56 UTC