Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Interoperability
 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. I am not sure that that is the barrel of worms that is easiest and most fruitfully dealt with first. (Can a barrel of worms be fruitful? ) I believe we need to approach things from a completely different angle than just the symptoms "xmlns:* breaks DTDs" or "DTDs (i.e. IDs) break databases" or "database influences complicate simple XML for data interchange" or "schema languages are too complicated" or "I don't need this therefore it should not exist" etc. 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." At the moment, we are little better than in SGML days: we have a choice of many more tools but they still take a too much effort to set up. Once set up, we have interoperability of data between our application and some-one elses, but the establishment costs are still too high. So a lot of the potential of standard generalized markup languages has not been realized yet, because of this inflexibility. There are three architectures we could to consider: 1) URIs ---------- The WWW architecture would have all resources related to a document always available on servers at absolute locations. This is good for standard resources, but it provides no mechanism for value-adding: we have not format to allow an integrator to make an "XML application" to distribute to clients. Obviously it breaks when you disconnect from the web too. 2) P2P --------- Another alternative is the peer-to-peer system. Because there is no peer-to-peer protocol that has won the day yet, this is only useful for vendor-specific tools at the moment. (My company is using this method for our forthcoming product, for example) 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 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.) 3) It allows us to transmit any kind of associated resource connected to a document type out of band. 4) It allows us to move towards XML portable applications (i.e. distributable applications which use XML data). So vendors or integrators can add their own customizations for multiple tools, to suit the needs of particular customers. 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. Or it could contain product-specific versions of stylesheets or DTDs so that we can provide a nice one for the browser/tools of choice and a simpler one for others. Or an integrator could have their own directory to distribute updated OmniMark scripts along with the latest versions of the DTDs. 5) If a DOCTYPE declaration is missing, then there is an alternative source for supplying entity references. (CATALOGs could be integrated too.) 6) By taking care of a large class of problems for application creation and deployment, it clarifies the areas where XML and standards above it can be improved: they can focus on all the parts left over. At the moment there is a hodgepodge of issues that everyone will just get bogged down in. What would it take? Step 1) Someone (OASIS? xml-dev) develops a simple spec (like DZIP) for XAR Step 2) Vendors add a standard directory location where their application looks for XAR files and, if one exists, read DTDs etc from them. (They can also look for vendor specific plug-ins etc.) 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. Cheers Rick Jelliffe 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
