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.

In the simple case, yes.  The meta-document could also describe relationships
or alternate renderings.  For example, there might be a set of style-sheets
that could be applied depending on the user.  There might be one for large-type,
one for regular presentation, and so on.  Thus, instead of a packing list that
says, "here's all the stuff, go!", you can specify alternatives and 
relationships that more complex browser systems can utilize.  

What I am really interested in from XML is the ability to layer intelligent
frameworks over the standard that can load semantics from the server (currently,
Java code).  Thus, just being able to specify the "packing list" isn't
sufficient.  

Here's a wish list for the meta-document:

1. Specify multiple styles with semantics about who should use them and
   when they should be used.
2. Specify client-side transformations and associate with operation "classes"
   such as "Create me a summary".
3. Specify inter-document relationships.
4. Specify target documents (notice the plural).
3. Specify client-side workflow or "sequence of events" that can utilize
   (1), (2), (3), and (4).

I really think we need to think about layer standards.  XML is the document
encoding standard.  We may want to think about and "XML Super-BOS" or 
"XML-Mime-packing", etc. ancillary standard.

<CONFUSED LEVEL=CLUELESS>
Note: Maybe I'm confused on the structure of the XML standard.  If I implement
XML, do I have to implement everything we decide on in respect to the 
major components such as the XML document encoding, XHL, etc.  For example, if
someone has an XML parser/data-model toolkit but doesn't support the
hyper-linking layer, are they XML compliant?  If they add hyper-linking, are
they then XHL compliant?  I'm confused.
</CONFUSED>

I'm really like componentized architectures where I can pick and choose the
technologies and standards I must adhere to.

HyTime people:  Can the BOS do this or this beyond what BOS was intended
for?

> >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....

Could be.  Can MIME accomplish the above?  I always thought of MIME as a
way of encoding in one data stream multiple parts and encodings.  I didn't
think there was a way to express the relationships between things.

> >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.

Yes. Yes. Yes.  Except, as below, I don't like the SO catalogs syntax either.
...but I'll support it if I *have* to.

> Some people on this list know that I have little love for the SO
> catalog syntax, but that seems sufficient to me.

Its not sufficient for more complex constructs.

It seems to me that we have two choices:

1. Accept an SO-catalog-like solution and fragment the resolution, location,
   and organization of other components that don't fit into the "catalog"
   concept of resolution into ancillary standards/constructs.

2. Find a generalized solution to these problems that is uniform and will
   allow us to capitalize on *infrastructure*.

(1) does work, has some existing products that support *some* of the
constructs,  and is sufficient for displaying documents.

(2) is required, in my opinion, for being able to go beyond displaying
documents.  It also doesn't exist.

...this all relates back to those tunnels under Chicago...

==============================================================================
R. Alexander Milowski     http://www.copsol.com/   alex@copsol.com
Copernican Solutions Incorporated                  (612) 379 - 3608

Received on Monday, 10 February 1997 13:05:03 UTC