Cart
[Home] [By Thread] [By Date] [Recent Entries]
Rick Jelliffe wrote: From: "Joe English" <jenglish@f...> > 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>
|
