Re: XML process modelling [was No Metadocuments]

My stuff:

> | Here is, again, my opinion:
> | 
> | 1. The "Minimal-constructs-to-declare-success" is some kind of SO-catalog model.
> |    It has its drawbacks which was well pointed out.
> | 
> | 2. The uniform and scalable infrastructure is a metadocument architecture or
> |    whatever you want to call it--a bootstrapping document that starts the
> |    whole process off.  This is more complex and, to some extent, will require
> |    rejecting the premise that XML must be kept as simple to implement
> |    quickly.

Terry Allen wrote:

> This is argument by assertion.  Let's begin at the beginning (where it would
> have been useful to start last year).  Who's on first?  
> 
> I imagine that an XML pile-o'-stuff is first requested not by an XML
> "processor" but by an app.  One scenario runs thusly:
> 
>  - App sends URL to URL-handling engine
> 
>  - URL-handling engine tickles the HTTP client to send a GET
> 
>  - Server responds by sending XML pile-o'-stuff, which can range
>    from a single XML file (with pointers to other needful entities)
>    to a complete set of entities, DTDs, and the like
> 
>  - This pile-o'-stuff is routed to the MIME unpacker (if need be)
>    or to the app that requested it.  If to the MIME unpacker, then
>    the unpacker and the app probably need to communicate with each
>    other.  pile-o'-stuff gets unpacked suitably
> 
>  - App sends appropriate pieces of pile-o'-stuff to the XML parser
>    (processor), possibly in a complex interaction
> 
>  - Parser returns parsed XML (for which there is, amazingly,
>    no API specified) to the app, which may need to go back to
>    square 1 to obtain additional info that wasn't included in
>    the pile-o'-stuff
> 
>  - Eventually the app is happy and does something with the
>    parsed XML that either the author or the user or the parser
>    or the app or some combination decides is the Right Thang.
> 
> Now where in this scenario do you want to use 1) catalogues
> and, or, 2) bootstrapping documents, and what is more complex
> about 2 than 1?  Have I left out some steps?
> 

Well, yes and no.  What I am trying to differentiate is deliver of documents
from document applications.  There is one level of target applications that
*only* need to be told where to get the data and the respective components. 
For example, an XML browser needs the XML document, the respective entities,
and a style-sheet--others need more.

What if I view an XML application as a framework of services.  This model is
already prevalent in the web today.  Currently, I can do the following:

   * Render information in HTML
   * Display "applets" in java.
   * Send data to plugins.

What if I view each of these as a set of client side services (or as a 
server in the X11 model) and state that I want to deliver XML documents,
DSSSL stylesheets, DSSSL transformation, etc. as data and a description--the
metadocument in my model--of how these things go together.  

In this model, retrieval of the components (entities) of any particular XML
document is only part of the problem.

I am beginning to think that I am talking about a layered application standard
rather than something directly related to the *XML* standard.  There is no
reason why we couldn't come up with a layer standard that allows us to
transmit more complex document applications and, on the way, solve some of
the more problematic things like "where is my catalog anyway?".

The big benefit of the metadocument approach for entity resolution is that
there is only one way of getting configuration and instruction information
rather than having catalogs for one thing and something else for the
rest.

<THOUGHT type=out-loud>
One of the things I would really like to see out of an XML environment on
the web is the ability to deliver complex document applications to arbitrary
XML client environments.  Catalogs alone won't do this.... but maybe this
"want" has little to do with catalogs and more to do with a client application
profile.
</THOUGHT>

The problem I'm having with catalogs is that you have to start adding in
all kinds of other "things" to allow a browser to operate intelligently.  Things
like: "a list of style sheet options", auto-table-of-contents-stuff, etc.
The object-purist in me raises a red flag as says that we are designing to the
specific case.  On the other hand, XML is not just for browsing across the
web.  We need to cleanly solve both situations.

Do we want to parse documents or define application frameworks?  That is my
question.  The latter will happen regardless of the standards we produce.

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

Received on Wednesday, 12 February 1997 10:10:42 UTC