Re: XPDL (was Re: XML is broken)

Subject: Re: XPDL (was Re: XML is broken)
From: Chris Lilley <chris@xxxxxx>
Date: Tue, 06 Apr 1999 17:39:40 +0200

Gavin Thomas Nicol wrote:
> 
> > >manifest
> > >  root xml doc
> > >    subsidiary xml doc1
> > >    image 1
> > >    subsidiary xml doc2
> > >       subsidiary xml doc3
> > >  stylesheet alternative one
> > >    stylesheet 11
> > >    stylesheet 12
> > >    image 13
> > >  stylesheet alternative two
> > >    stylesheet 21
> > >    stylesheet 22
> > >    image 23
> > >
> > >The mechanism of compound xml documents is clearly transclusion using
> > >XLink, and for stylesheets, import.
> 
> This "manifest" could also be called a "catalog",

It could, but that would imply quite a different model

>  and SGML systems have
> had such beasts for many years in various different forms. Some systems
> only used them for document-component lists, and others for both
> processing data and document components.

I am aware of the SGML Open catalog. I use one. I was not suggesting it.
You may be referring to some other catalog mechanism, though.

A catalog file is a marshalling resource; it is analogous to a (real, as
specified) mailcap file. All documents are handled by the same one,
typically.

What I was suggesting was quite a different thing. At present, the
document instance is used as a sort of dual\-function manifest - it
contains a lot of the content, and it also contains the manifest for the
compound document. So in a typical HTML document for example we find
links to images, to sounds, videos; links to stylesheets, links to
external JavaScripts, etc. And to link to that compound document, witha
simple link, we link to the document.

The manifest I was proposing would be a separate thing, with no content
at all, just links.
You would point to one, and get one (or more) documents, plus assorted
stylesheets, images, etc, as needed. And if you wanted a different view
or to assemble a different compound document, you would make a new
manifest which would have a separate address,  and link to that. None of
the original components would need to change, there would be no
hardcoded stylesheet links (or PIs etc) in the actual content, just in
the manifest. And you miht already have some of the components cached.

> Something like this is crucial to the success of XML (get's rid of all
> the PI nonsense), especially for email where multipart messages containing
> XML will be sent.

Well yes, there is a MIME multipart and there is the cid: URL scheme to
refer to the different multiparts. But that is monolithic, and defeats
cacheing.

> I worked with Don Stinchfield on a catalog-based proposal
> for email of SGML some years ago, and it had many advantages... including
> mixed push/pull and not requiring any new mime multipart types (HTML
> in email requires multipart/related).

This is good, but seems to overload two concepts:

1) listing every component needed for a compound document 
2) providing them all as one blob.

> Using XML for the encoding is obviously The Right Thing.

Clearly. Actually, using XML and XLink and XPointer is clearly The Even
Righter Thing.

--
Chris



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread