Re: What to do given both SYSTEM and PUBLIC?

> From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>

> In fact, we should SERIOUSLY consider standardizing an archive format like
> SDIF-for-the-Web of JAR-for-XML. I am really sick of having to manually
> figure out what SGML entities, DTDs, and stylesheets go with a particular
> SGML document. Let's correct that for XML. Wouldn't it be nice to be able
> to take a single file, with all of the formatting, catalog and entities and
> use it in Author/Editor/XML or AdeptXMLitor.

It sure would!

The SGML Open TR9401 catalog (see "Issue B" of TR9401) can be used to
do this.  A catalog can be created that points to all the bits and that
has a DOCUMENT entry to point to the entity in which parsing shall
start.  If you point an application to such a catalog (and nothing
else), the application should have all it needs to work.

[Vendor-specific disclaimer:  at the present time, ArborText's 
Docarch tool is currently needed to handle such a situation
since you must first "Import" the various doctype files and
"Generate" a compiled doctype.  Once the compiled doctype is
created, you can then point Adept itelf to such a catalog.
Improvements in this process are planned.]

Another alternative (and one I would support) is some sort of MIME-SGML
interchange standard.  The experimental RFCs 1872, 1873, 1874 outline
one such method.

Whether using a TR9401 catalog and/or a MIME solution, there needs
to be some "packing" and "unpacking" process that determines what
all is needed in the package, finds and collects all the bits, and
generates the interchange package and/or catalog or expands the
interchange package back into a bunch of files appropriately placed
and named.  That is, defining a packing mechanism doesn't solve the
problem if it still requires manual effort to create or process the
package.  I wouldn't add such packing/unpacking requirements to XML,
so the definition of XML and the solution to interchange packaging
seem to be separable issues.