PAX: Why OOXML and ODF are inadquate bases for a forward-looking gen
Neither ODF nor Office Open XML are adequate bases for a forward-looking, general-purpose office document format. This is because the needs for level-playing-field data-interchange and the needs for full-fidelity native formats are diametrically opposed and *irreconcilable* by any single schema. Level-playing-field data interchange requires a limitation of the documents to features supported by generator and consumer, and some ability for graceful degradation. Full-fidelity native formats require complete implementation of product-specific features, which well may be more than hints added on top of a generic structure, but sometimes have to be in terms of the data models of the particular application. Furthermore, office formats embody some idea of application type (a "word processor", a "spreadsheet") however in real life, only "follower" applications fit into those moulds, while "leader" applications go boldly into new areras. For example, Adobe StructuredFrameMaker is a word processor but also a structured document editor. Lotus has WP capabilities but also groupware aspects. In Office, Word has desktop publishing, blogging and forms, Powerpoint is moving towards simple 2.5D animation, Excel is moving towards report-writing features. Furthermore, different users have different needs. Professional users of equations, bibliographic information, etc. have different requirements to lay users. Why arbitrarily choose one when we can have both? What would a better approach be? To allow and encourage modularity and plurality at the base level. Take advantage of ZIP to have multiple versions of information items. A ZIP file can be both ODF and Open XML and an HTML archive at the same time; sharing common media files or even media files in different formats. An application can save in its native format for full-fidelity when the file is opened up in the same application next time, but also save in some more general format for wider distribution. It is not as if all the desktop applications won't support import and export of all the leading formats in a year's time, when the kerfuffle has died down. Or an application can choose one format, but cherry pick data in other formats as needed, if it is using a ZIP format that supports plurality. Is this a silly idea? Well, there are very successful precedents: Apple's fat binaries, mail in multi-part HTML and text, Open Type's packaging of postscript and truetype fonts, and indeed the whole Internet stack with its semi-loose coupling between layers.* In other words, the current fuss about choosing between brand A and brand B makes the fundamental mistake that either (or both) Brand A or Brand B can be the end of the line and satisfy our needs. Now both ODF and Open XML support various kinds of extensions, modularity and so on, but they do so from the POV of "how can we support this monolithic application?" rather than from the POV of "how can we support pluralistic applications?" What is needed is to take ZIP and work out what extra conventions are needed to support this kind of plurality. OOXML's OPC goes much further than ODF in this regard, but it is still not adequate. Then once a proper layering and modularity system is in place, to modularize ODF and OOXML and XHTML etc to allow this kind of plurality. I have some more ideas on this on my blog "Can a file be ODF and Open XML at the same time" if anyone is interested. http://www.oreillynet.com/xml/blog/2007/07/can_a_file_be_odf_and_open_xml.html I thought the name .pax would be a good extension name, to give the flavour. People who think that the evolution of file formats for "office" desktop applications somehow ends in 2007 will naturally think of the current ISO process in terms of Brand A versus Brand B. It is a kind of panic attack. But I don't believe for a moment that it is the end of history: the real game we need to be playing is how to put the ducks into line so that the kind of pluralistic system becomes the natural win/win position for vendors and users. Cheers Rick Jelliffe * Now one area where this idea has not worked well has been the the ability in HTTP MIME to specify alternative content types. However, as with character set specification, I think this is because the MIME header level is the wrong place for this functionality: it needs to be a fine-grain capability inside the resource and the resource-rendering systems. What is the practical ramification on ISO standards? It means that we need to be moving towards much more fine-grained namespaces specific to particular information units, and a refactoring of data to reduce the amount of mixed namespaces in a file: for example, if a domain-specific schema requires rich text in a field, that rich text should be in a different resource to allow alternative implementations. That kind of route is the only way that I can see us ever getting to the state where everyone can be happy: vendors can innovate and compete on features, end users can have intereoperability, integrators have the most chance that the documents will include data in schemas they have already coped with, expert users can have their requirements met without overburdening lay users, value-adders can add their own niche-market alternatives to the regular formats without breaking anything. Etc. We are getting really close to this, it is no a pipe dream or unrealistic; the problem is how to get demand and support for this kind of .PAX approach in a world where people are fixated by "OR" (my way or the highway) rather than "AND" (I feel the urge to merge).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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