RE: XPDL (was Re: XML is broken)

Subject: RE: XPDL (was Re: XML is broken)
From: "Gavin Thomas Nicol" <gtn@xxxxxxxxxxxx>
Date: Mon, 12 Apr 1999 22:33:56 -0400
> > This "manifest" could also be called a "catalog",
>
> It could, but that would imply quite a different model

I don't think so.

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

This is *sometimes* the case, and perhaps even *often* the case,
but certainly not *always* the case. The proposal I referred to used a
per-packaging catalog (the manifest you refer to). The more powerful
concept is allowing the combination of the two models.

> The manifest I was proposing would be a separate thing, with
> no content at all, just links.

This is precisely what I was talking about. The "catalog" forms
the "hub" of the compound document.

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

Yep.


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

The whole mime packaging of HTML is a bit of a mess. The use of
multipart/related and the cid URL type is *quite* inferior to the form
discussed using catalogs. A lot of politics was involved there though...

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

I would argue that these are roughly forms of the same thing. The
catalog is *central*, and whether the data is packaged with the
catalog, or not, is totally irrelevant to the proposal.

FWIW. I *did* prototype this under Unix, and we were able to
mix push and pull models completely. The other proposal required,
in effect, a closure of the compund document to be sent.

>
> > Using XML for the encoding is obviously The Right Thing.
>
> Clearly. Actually, using XML and XLink and XPointer is
> clearly The Even Righter Thing.

No argument there. The thing to remember is that XLink and XPointer
are simply syntactic conventions. Ultimately, the semantics (the
model) is the most important thing.


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


Current Thread