RDDL and packaging was Re: [xml-dev] Interoperability

["Jonathan Borden" <jborden@mediaone.net>]

Rick Jelliffe wrote:
From: "Joe English" <jenglish@flightlab.com>

> The main drawback to omitting <!DOCTYPE ...> declarations
> is that information about the document type has to be
> carried out-of-band (e.g., a note saying "the files
> in this directory use the TMML vocabulary, see
> <URL: http://tmml.sf.net/ >" in a README file).
> I suppose using XML namespaces would rectify this, but
> that's another barrel of worms.

 <jb>
The _nature_ of an XML document may be infered from the namespace of the
root element. When a namespace URI is used to retrieve/locate a RDDL
directory, the proper DTD is identified.

I've discussed this on and off for the past year but perhaps until now noone
has seemed too interested in this topic! I have also been surprised.
</jb>

...

I believe the root of the problem is that there is no
vendor-neutral way to distribute XML applications.
We have all sorts of formats for bits and pieces:
schemas, transformation scripts, stylesheets, digital
rights, not to mention the zillion proprietary plug-in
formats.

Yet there is no way I can say to my friend
"Here is a file with all the resources needed for you
to work with DOCBOOK: you can just plug it into
your XML system (editor, composer, database,
web application, etc. etc.) and you can start using it
straight away."

<jb>
this is the goal, I don't draw a clear distinction between the 3
mechanisms/architectures you outline below. e.g. URIs may be used by P2P
applications, similarly URIs may be used in "local" systems to identify
_parts_ e.g. mid:xxx or cid:xxx as part of a multipart MIME message,
similarly one could use a URI to identify a single 'file' within a JAR,ZIP,
TAR or whatever bundle of files.
</jb>

There are three architectures we could to consider:

1) URIs
----------
...

2) P2P
---------
...
3) Packaging
----------------
The other mechanism, and the one I think we need,
is a simple file format for packaging all the resources
for generic and value-added XML applications: an
XML application archive format (XAR Gavin has
suggested.)   The kind of thing I am suggesting
can be found at http://www.topologi.com/public/dzip.html

<jb>
 this is an excellent approach. to integrate this with a URI we simply need
to standardize a naming convention for files located within the ZIP/JAR/DZIP
package, e.g. using something like a JAR uri scheme:
jar:./org/xml/sax/ContentHandler.class which means "locate the resource with
reference to the _current directory_.
</jb>

Why would this move us forward?

1) It gets rid of path problems. Users just need to get the
appropriate DZIP file for deploying and configuration of
XML tools.

2) It provides the equivalent of RDDL but without
the fragility of the Web.  (A RDDL document could
point to an XAR, and an XAR could point to a RDDL
document.  A CATALOG still needs to be located
or packaged so does not help.)

<jb>
Well, the path 'problem' gets converted into a _relative_ path (and this is
exactly why relative paths are useful). Note that the WWW _already_ uses
this type of architecture, e.g. an HTML document <a href="foo.html"> refers
back to the _base URI_ of the current document. In this case the _base URI_
is the URI of the package.

RDDL works perfectly well in this situation. Note that it is deprectated to
use relative _namespace URIs_ but perfectly reasonable to use a relative URI
for an _href_, so RDDL documents would be perfectly happy packaged as the
manifest of any type of package.
</jb>


The XAR could contain not
only the schema and DTD and stylesheets and public
entities, but also the scripts or plugins or libraries used
for by different tools, e.g. an MS installer script
for some application underneath the
vendors/microsoft.com directory and a BeanShell
script for our product underneath vendors/topologi.com
and an RPM package for a Linux application
elsewhere or Oracle could put their iFS type definitions
to map the document into their DBMS.

<jb>
and the natures and purposes of each of these related resources can be
described by RDDL. The point of this is that it is also essential that once
you drop this DOCBOOK package on someone's door that it contain
_instructions for use_. That's what RDDL does.

Ever put together one of those mailorder devices/toys for one of your kids?
It turns out that that little ity bity piece of paper containing the list of
parts and instructions for assembly is well, often essential for proper
construction of the toy which _looks_ so simple :-))

RDDL is the little ity bitty piece of paper inside the box, not the box
itself, nor the tools or pieces of plastic, screws etc that come inside.
</jb>
...
How would users use it?

1) I want to edit DOCBOOK. I get the docbook.xar from
docbook.org or from some value-adding vendor and stick it
in the correct directory (a kind application might help put
it in the correct place)
2) err thats it. My generic tools are XAR aware and I
can start work immediately.

Nice dream, but it seems like such low-hanging fruit.

<jb>
yep, we have all the necessary tools, we just need to 'package' them
together :-)
</jb>