My first reaction was much like yours, that this was a somewhat confused apples vs. orange comparison. But upon reflection, there is an important kernel of truth in Rob’s argument. There is no denying that the design of the OOXML is based upon the older binary model. Microsoft’s fundamental claim for using OOXML is that is offers better integration with existing documents. This means that they have to design XML to imitate/integrate with/replicate the data structures in the older binary specifications. So Microsoft has to defend design decision make for a different media (binary) in their XML.

Even though they use XML, there are some pretty serious design mismatches. The most glaring one to me is using bitmasks in XML. The O’Reilly XSLT cookbook shows how you can handle bitmasks, but is is a kludge and you have to make assumtions about mapping bit arrays to numbers. Endian-ness (big vs. little) means that the XSLT will not be portable between computer architectures. If you can show me a better XSLT transform, I would be happy to retract this criticism. I do not want to hear about some non-XSLT tool that runs on .Net 3.0.

I also find it curious that you claim that including dedicated markup languages in the OOXML standard is somehow equivalent with using existing standards. Especially since your first example (Dublin Core) is not defined by the OOXML format spec, although it does appear that the standard does define what subset of the Dublin Core is used. Perhaps ‘dublin core’ refers to the subset of ‘Dublin Core’ that OOXML supports.

The reason that I want existing standards to be used is that I am lazy. Somebody else has already implemented tools to manipulate standard XML, so I can simply used debugged tools that I can often find with Google in a few minutes. So to me, the fact that OOXML defines some new dedicated markup languages is a pain the the backside, not a feature – I may have to write more code, especially if I’m not coding in .Net.

If we were all creating plain text documents, then that would be all we would need to worry about for preservation. But if we create documents with graphics, even movies, then these may need to be preserved as well.

One approach would be to have something like ODF/A, an archival profile of ODF that restricted what type of embedded media could be used. For example, it may only allow open formats like PNG images, Ogg Vorbis for audio, etc.

Also, having a structured document, with clearly defined headers, footnotes, etc., defined by specific markup rather than merely placed conventionally in expected locations, is a necessity for the tools that allow screen readers and similar tools to read documents for the blind.

So one way or another, documents via markup rather than plain text is here to stay.

@Wraith,

These diagrams are illustrating the critical dependencies, not the traditional layered architectural diagram. Maybe directed arrows would work better than pyramids? But I think the approach I used better illustrates the idea that the technology at the base is the most stable, etc.

Although OOXML uses XML, Unicode, etc., this is certainly not a dependency for them. In particular, their use of bitmasks that map directly into Windows platform API’s, undocumented binary inclusions, even provisions for Unicode characters not permitted in XML, these all show that the XML is just a trivial wrapper layer, not a dependency or a constraint.

When you ask “Why did OOXML do something in a particular way?”, the answer is rarely, “Because it is good XML style to do so”. The answer more typically is, “Because that is how Word does it”. That is why I say that Word and Windows are the primary dependencies for OOXML.

Richard Chapman

OOXML is also using unicode, XML and RelaxNG and using several dedicated markup languages like dublin core and others like DrawingML that are also open due to their inclusion in the OOXML format spec.

Document persistence is actually a serious issue in architecture, as CAD models aren’t shown to have the longevity yet -and the Airbus 380 disaster shows it applies to engineering systems too. It is claimed that Catia versions were the cause of incompatiblity between french and german parts of the airplane design.

Compared to that, doc files arent as serious. IF you want long-lived printable content, PDF is actually very good. XML formats make more sense if you want to have the option of repurposing the content over many years. So does plain text, funnily enough.
-steve