- From: <lee@sq.com>
- Date: Sun, 9 Feb 97 16:39:44 EST
- To: w3c-sgml-wg@w3.org
lex@www.copsol.com (Alex Milowski) wrote:
> [...]
> Catalogs are *not* sufficient for manipulation and transmission of
> XML (or SGML) documents.
Yes, I agree. I am prepared to accept that they may be part of a solution,
but they are not sufficient.
[good example deleted; I have many more examples if they're needed :-)]
> The XML (SGML) document is at the same "class" or "level" as the
> other information components--style-sheets, graphics, transformations,
> etc. It is a very important component in the system, but not
> very useful in a practical way without the other components. Thus, it
> is *not* the starting point.
>
> 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.
One way to look at this is that when you make a link to an XML document,
you actually point at a file that points to all the other files that
you may need. That file could be an XML file with links, or it could
be an SGML OPEN Catalog file. The XML file with links would at least be
in an SGML-based syntax, which seems appropriate to me.
When this has been discussed in the past, people have objected to
the idea that they end up with (in essence) a separate catalog file
for each document.
But if that linking file actually contained the XML document itself (say),
it would be more like a document header, and the resulting file would
be self contained.
> 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.
I don't know what JAR files are (is it part of JavaBeans?) but want to
ake this comment: for fast progressive display, you have to be able to be
fetching multiple files at the same time. So you need to get the links
as early as possible, and then fetch them (conceptually) in separate
streams. Of course, with HTTPng you could use a new virtual stream over
the same connection. I think we're agreeing with each other. I'm not
alone any more! Yippee! I hereby bequeath Alex all my footwear :-)
> 3. For simple documents one-time documents, packing everything into
> a stream is very useful. The meta-document in this case may be very
> small--only a few bytes.
Yes -- where the "catalog" (and possibly style sheet itself and all the
other gubbins") is small, the overhead of separate connections, or
even separate local file opens, is greater, and the added ease of
maintenance is an even bigger benefit.
> 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.
Yes.
> 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.
Although it's disgusting, it may be better to use one of
(1) elements starting with XML, or
(2) processing instructions.
Another way would be to use entities with reserved notations:
<?XML...>
<!DOCTYPE Sock PUBLIC "bet you can't find me" [
<!Entity cat
SYSTEM "http://www.socks.com/leftfoot/1019.soc" NDATA XML-CATALOG
>
<!Entity looksgood
SYSTEM "http://www.socks.com/patterns/argyle.dssl" NDATA XML-STYLE
>
]>
<Sock>
the fabric of the document
</Sock>
An XML system would reserve notations beginning with XML, and
would understand what to do with XML-CATALOG and XML-STYLE.
They don't need to be declared (can that be kosher SGML?), so this
would be the only XML use of NDATA as it stands right now, I think.
When we talk about how to mark up an inline TIFF image, we may need
to rethink that.
Lee
Received on Sunday, 9 February 1997 16:39:50 UTC