Re: There Are No Metadocuments

Dave Peterson wrote:
>
> The "pre-SGML", if you will, concept of a document was simply
> something that is printed.  SGML looks at a document as a
> collection of potentially reusable information, which may
> be reused in many ways besides republishing it on paper again
> in a slightly different format.  "The document" is something
> that can be published, searched, spoken (a very non-paper form
> of publishing), indexed, etc., etc.  If, as you suggest, that
> this something together with its publishing specifications is
> a document but that with different publishing specifications
> is a different document, then with its indexing specifications
> it's yet another document, when published by speech synthesizer
> it's yet another, etc., etc., etc.,...  Put all these things
> together and you've got a metadocument, in many people's mind.
>
> If the union of all of your related-by-having-the-same-content
> documents is a metadocument in some people's mind, there are
> others that would like in this brave new world to use "document"
> to mean the intersection: the core structured data set.
>
> ...And those who draw the line somewhere in between.
>

Very well put.  Now, I'm all for not drawing lines.  I would prefer
flexibility in infrastructure.  Is it possible that we have:

1. An SO-catalog spec as minimal conformance.
2. Something describing the union/intersection model described above
   for metadocuments.

??

...or, is this contrary to our goal?

At some point in time, we are going to have to reject the premise that XML
should be simple and built by a CS graduate in a week (or whatever silly
premise it was).  Was this a design premise when SQL was created?

Complex problems never cease to be complex problems and simple solutions rarely
solve them.

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.

>From an implementor's standpoint, writing code to handle catalogs is pretty
trival.  It is just some amount of work to shake out the features and bugs.

>From a development user's standpoint, using catalogs in a simple environment
is quick easy, quick, and convient.  Using catalogs in a complex environment
is a *big* problem.  They can be large or complex and difficult to handle
(sound familiar?).  Thus, they don't scale well for the non-simple user.

Can we accept this?

I am certain that SO-catalogs can be worked elegantly into a metadocument
architecture such that we could be compatible with them if we choose to
implement a metadocument architecture in the future.  Is it possible we could
have one specification that incorporates both?

In addition, it would seem that the metadocument archictecture has somewhat
been approached by Sun in Java.  JAR files are "archive" files that allow
delivery of class files, data (documents, images, etc.) all within one
stream from the server.  I haven't experimented with this very much but it
would seem that they had a similar issue: my program is made up of distinct
components that I must locate and load from the server.  They decided that
having one archive to retrieve would improve efficiency.

In light of this, is a metadocument archive something that will be the new
paradigm for delivery of content/applications arcoss the web?  If so, do we
need to consider this as a necessary component of XML?

Remember, I want more than deliver of *documents* that can be printed/previewed.
I want active documents that use components that are information and semantics.
(Add one XML document and one DSSSL stylesheet into a blender, blend on
highest setting until a soupy mixture results.  Pour into computer.)

I am always guilty of wanting the ideal (or at least, my ideal).


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

Received on Tuesday, 11 February 1997 16:25:56 UTC