Orcmid's Lair: OOXML-ODF: The Harmonization Hope = Chest

	Orcmid's Lair	status privacy about contact
Welcome to Orcmid's Lair, the playground for = family=20 connections, pastimes, and scholarly vocation -- the collected=20 professional and recreational work of Dennis E. Hamilton Archives Atom Feed=20 Associated Blogs Edge City = Numbering = Peano=20 Orcmid's = Live=20 Hideout Praxis101 Prof. von = Clueless in the=20 Blunder Dome =20 Recent Items Who = Wants ODMA.com Anyhow? NewsGator:=20 Deja Vu All Over Again Happy=20 Birthday, CACM! Re: = Video=20 Schmideo OLPC:=20 Bring on the How-Tos I=20 will Facebook no more Forever The=20 Seven Deadly Signs of Blogstipation Publiversity:=20 Public and Alternative Higher Educat... IIW=20 2007b: Internet Identity Roundup One=20 Laptop Per Child: Labor Pains	2008-02-06 OOXML-ODF: The = Harmonization=20 Hope Chest Technorati=20 Tags: ODF, OOXML, DIN, Fraunhofer Institute, OOXML/ODF Translator Project, open=20 documents, Office=20 binary formats [Update 2008-03-06 (via Brian=20 Jones): The DIN NIA 34 working group has raised its = head=20 above the waters. It is officially N= A=20 043-01-34-01 VT Working Group Translation 29500-26300. = They have=20 published a schedule and the first working-paper draft is = available for=20 download. There is a terrific little graphic about the cases = they=20 want to understand. The copyright notice on this = document is what strikes me as the fatal flaw of ISO, ISO/IEC, and = their=20 business model. Why would I voluntarily lock up the fruits = of my=20 labors in such a prison? Would you? I'm = sorry. This=20 sets off my elitism-paternalism-bullshit detector. I'm sure = it is=20 simply thoughtless, but it's a level of = ritual that does not invite my cooperation. I'll calm = down=20 later. Now I'm venting.] [Update=20 2008-03-07T20:13Z: I have calmed down and I am now = embarrassed by=20 my intemperate outburst. This is uncalled for. It = demeans the=20 worthy efforts of the DIN working group. I apologize. = I will=20 also apologize directly to the working group contact, and I will = make a=20 separate post on the lesson for me.] [Update 2008-02-16: Microsoft has delivered on = its=20 promise to ECMA TC45, originally reported by Brian Jones on = January 16[3]. =20 The specifications for seven binary formats are placed = under the=20 Open Specification Promise and freely available for download [14]. =20 The SourceForge project, b2xTranslator,= =20 has been established and its initial program of work has been = posted [15]. =20 I am hopeful that this work and the conclusion of the DIS 29500 = Ballot=20 Resolution meeting will energize the DIN NIA 34 working group on = OOXML-ODF=20 translatability [6].] This post has four points: Translatability=20 Informs Harmonization Difficulty of translation is a = rough=20 indicator of the degree to which reconciliation of the formats = is=20 difficult. =20 Models=20 Limit Translation/Harmonization There is no assurance = that=20 either format is universal enough, in the sense that it can = faithfully=20 express all documents of the other format. = =20 We=20 Must Know the Differences We need to know the = severity of=20 the model disparities and individual-feature differences before=20 concluding how much useful harmonization is=20 possible. =20 The=20 Reality in the Punchbowl People do not deal with the file = formats=20 when creating office documents. The stored formats are = below the=20 level of office-worker attention and detail. Most people = deal with=20 their office-document software in an ad hoc way, using = trial=20 and error to obtain the appearance that is desired. = Interchange=20 among those using different (versions of) office-document = software is=20 dominated by these user practices. Common formats are not = enough=20 by themselves to ensure interoperability and faithful=20 interchange. 1. Translatability Informs = Harmonization Brian Jones has reported that there is a great deal of interest = in=20 harmonization of ODF and OOXML in some way [1]. =20 Subsequently, Brian reported on the ECMA response to ISO/IEC JTC1 = DIS=20 29500 (OOXML) ballot comments requesting harmonization [2],=20 quoting from the ECMA response:=20 "Ecma believes that the work of the DIN (NIA-01-34) committee = is=20 essential to any harmonization effort. The work ... will enable = the=20 industry at large to understand the detailed differences between = the=20 formats. Based on this detailed understanding, the ODF and Open = XML=20 formats could be extended in the future in order to enable = better=20 sharing of information and allow future translations tools to = provide=20 even better translation and interoperability between the=20 formats." The announcement of the DIN initiative indicates that it will = include=20 the experience of the SourceForge OpenXML/ODF Translator Add-In = project,=20 and other efforts in its findings [5,=20 6,=20 7].=20 I agree, this is the best way we know to learn where the = stumbling=20 points are and what the prospects are for reconciling the document = models. I also appreciate that the ECMA response recognizes = that=20 current translation capabilities could be better with improved=20 understanding of the formats, but no claim to perfect = translatability is=20 made.=20 2. Models Limit = Translation/Harmonization Cautious statements about the prospects for translation are = also=20 welcome. With regard to present capabilities, Jones = quote of=20 the ECMA response contains this earlier passage [2]:=20 "There are many translation tools already in existence that = enable=20 interoperability between different formats by providing=20 useful translation capabilities between ODF, = Open XML=20 and UOF." where that's my emphasis on "useful." I maintain that getting from "useful" through "even better" to=20 "assured" is unlikely [10]. =20 I think it is reasonably-well understood that the architectures = of=20 OOXML and ODF documents are extremely different. There is = great=20 impact on how the format architectures are intended to be = processed and=20 how they map to tangible renderings of the document content. = These=20 details might be found to have common conceptual abstractions = within which=20 translation is reasonably-direct rewriting from one digital format = to the=20 other. There is reason for skepticism. =20 Harmonization of terminology and metadata provides some important=20 considerations [9]: "Existing solutions to the metadata harmonization issue are=20 few=E2=80=94systems are either limited to a single = specification, or implement=20 ad-hoc solutions that only work in that particular environment. = There=20 are many examples of 'mappings' between specifications that = provide=20 partial solutions to the problem, but generally fail due to = low-fidelity=20 translations and lack of generality (i.e. the mapping only works = for=20 limited parts of specifications). Another solution is to create = a=20 top-level data model that encompasses the common aspects of all = the=20 specifications. This has proven to be feasible in relatively=20 well-constrained domains . . . In the field of general metadata, = where=20 there is no such common ground, such an approach is = substantially less=20 likely to be successful." I am skeptical that office-document formats provide a = relatively=20 well-constrained domain. Our optimism must be tempered by=20 caution. 3. We Must Know the Differences I do agree that we need some concrete, specific undertaking to=20 calibrate what kind of harmonization is possible as a practical=20 matter: What are the features of ODF and OOXML that correspond in = ways that=20 can be preserved via useful translation and that could be a = practical=20 basis for harmonization? =20 What are the places where ODF and OOXML are incommensurate = in ways=20 that can be reconciled by additions to one or the=20 other? =20 What is left as unreasonably difficult and how does that = impact the=20 users of software that relies on one format or the = other? It will take serious effort to delineate these cases, and at = the moment=20 attention is on the Translation Working Group under DIN NIA-34 [5,=20 6]. =20 Update: I am heartened to learn that there has = been very=20 serious analysis by public agencies of the Danish government [12]. =20 Update Update: I have also unblocked my own = thinking=20 about an approach that might provide more concrete visibility on = behalf of=20 harmonization [13]. 4. The Reality in the Punchbowl Meanwhile, Sam Hiser offers a different impression of the DIN = effort=20 [4]: "The ODF-to-OOXML harmonization effort being hosted = by the=20 German standards group, DIN, is Europe's best effort to resolve = our=20 Mexican=20 Standoff between Microsoft, Sun and IBM. Even though=20 harmonization is laughably=20 complex and *will not work unless the = applications are=20 harmonized too, the best and brightest of Germany = are left=20 to hope for success." [emphasis* = mine:=20 dh] Although the mission of the German effort is translation = (=C3=9Cbersetzung),=20 not harmonization, I find there is a very important point that is = not made=20 often enough: People write, read, and edit office documents with little, = if any,=20 understanding of the particular format that makes them = persistent in=20 digital form. The XML-based open formats do not change=20 that. =20 People adapt to the software/device they are using by trial = and=20 error. We train ourselves to obtain the visible results = that we=20 want. Different people obtain superficially similar = results by=20 quite different means. =20 Even when someone has gone to the trouble to create style = sheets,=20 forms, macros, templates and other format-impacting aids, it is = very=20 loosey-goosey in practice. And it still does not require = paying=20 attention to the file format. I think that is a big deal. It is what people deal with. The = formats=20 are below everyone's direct attention and, while standardization = and=20 assurance of interchange is essential, it is insufficient, I = think, with=20 regard to what works for people who use products that "support" = the=20 formats. If interchange is the game, something else is = required. 4.1 Living in a World of Appearances Apart from the tab, space, enter, and back-tab keys, my = personal=20 control of layout is confined to an amazingly-prevalent set of = toolbar=20 icons: = = = = = = For each of the HTML editors, I often edit the file format for = desired=20 effect. Usually the editors leave my markup alone enough for = the=20 result to be achieved. I am reminded of performing similar=20 contortions with Borland Sprint, a document editor that employed a = plaintext markup scheme. =20 MediaWiki editing is also a form of direct markup, although my = control=20 over the HTML that is served up is indirect and mastered by=20 trial-and-error post-and-revise exercises. =20 The important observation is that I use these features for the=20 appearance that is produced and the tools and the symbols = encourage me to=20 do exactly that. I need not make any semantic distinctions = while=20 using the tools to achieve the formatting that serves my=20 purposes. (I am disgruntled that some products replace = indent=20 and outdent with a =E2=80=9C=E2=80=9D toggle. I don't care = that the element involved=20 is tagged <blockquote> and don't get fancy with me.)=20 4.2 For Users, It is the Computer Programs and What = Happens People ask questions about software products and getting their = job=20 done, not formats. On the Massachusetts Information = Technology=20 Division site, all of the practical questions are for working = between=20 Microsoft Office and OpenOffice.org programs, not how to use the=20 formats[11]:=20 "There are many features or ways your old office suite worked = which=20 are not accommodated in OpenOffice. Likewise, OpenOffice has = many=20 features not implemented in your old office suite. All users = share=20 different habits and rely upon a different subset of features to = perform=20 their daily tasks. While you may miss a few features that are=20 significant to you, there is often a similar way in the new = software to=20 accomplish the same task; and users report that the new suite is = fast to=20 learn." That is a great testament to the adaptability and = resourcefulness of=20 people, something that we are unable to endow in translators of = any kind=20 at this time. It is also not clear how this interactive = dance fits=20 into an interchange regimen, even among users of the same software = product=20 (release).=20 This passage shows how far the concerns in Massachusetts are = from=20 matters that might be governed by the respective formats:=20 "Yet there remain differences in the new [improved StarOffice = and=20 OpenOffice.org] tools which fail to offer improvement, and we = would like=20 users to feel empowered to report such discoveries to the = mailing list."=20 Then there is this wonderful alibi about conversion failures:=20 "Even if the number of files likely to convert with trouble = is low,=20 anyone encountering file compatibility issues will experience=20 frustration and inconvenience. In most cases still, corrupted = files or=20 those with characters slightly out of place can be fixed in the = few=20 minutes that it takes to curse one's luck. Users tend to = blame the=20 new office suite for the problems. Please keep in mind that = engineers=20 would be able to eliminate 99% of such conversion problems if = the=20 technical specifications of legacy file formats were to be=20 published." We'll see, won't we, especially since the legacy file formats = technical=20 specifications have been available for some time and will soon be = easier=20 to obtain [3].=20 Update: I think there may be ways to offer = products=20 that are specifically geared to only using harmonious features of=20 open-standard document formats [13]. =20 This would not require users to know or care about the formats and = the=20 ways that their documents comply, and the usual ad hoc = behavior=20 would work (so long as one does not have frustrating expectations = of=20 feature parity with all products).=20 [1] Brian Jones: Harmonization:=20 Finding the Differences. Brian Jones: Open XML Formats = (web=20 log), msdn.com, 2008-01-31.=20 This post reminds us of the important work on understanding = the=20 differences between ODF and OOXML was announced in May = 2007. The=20 expert working group would be conducted under the auspices of = DIN, the=20 German national body for promulgation of standards [6]. =20 [2] Brian Jones: Is=20 It Jetlag? Brian Jones: Open XML Formats (web log),=20 msdn.com, 2008-02-01.=20 =20 [3] Brian Jones: Mappi= ng=20 Documents in the Binary Format (.doc; .xls; .ppt) to the Open = XML=20 Format. Brian Jones: Open XML Formats (web log),=20 msdn.com, 2008-01-16.=20 I'm reluctantly using this sole public (but not exactly = official)=20 statement of the Microsoft offer to provide direct access to=20 documentation on the Office Word, Excel, and PowerPoint binary=20 formats. Microsoft also proposes to sponsor a new = SourceForge=20 project that will deliver tools and guidance for translations = from the=20 binary formats to OOXML. According to Brian Jones, visible = steps=20 will be taken by February 15, 2008. Also according to = Jones, this=20 commitment is being conveyed in the ECMA proposed dispositions = for the=20 DIS 29500 Ballot Resolution Meeting in Geneva, February=20 25-29. So far, the ODF Translator SourceForge = project=20 [7]=20 provides the only readily-visible public effort to convert = between ODF=20 and OOXML. The new binary format to OOXML project is not = directly=20 related to OOXML-ODF translation/harmonization. Still, = there will=20 be value for those looking into harmonization, just as there is = value in=20 examining the binary format to ODF implementation in = OpenOffice.org, the=20 OOXML to ODF implementations in the OpenOffice.org Novell = edition, and=20 the Sun ODF Plugin for Microsoft Office. =20 [4] Sam Hiser: The=20 Disappointing Formats. PlexNex (web log), = 2008-02-01=20 =20 [5] Fraunhofer Institute for Open = Communication=20 Systems: =C3=9Cbersetzung=20 ODF-OOXML (English page), Document Exchange Format project,=20 eGovernment Business Unit, FOKUS Projects.=20 This is the on-line presence of the project from the = Fraunhofer=20 Institute. According to the undated material on this page = and=20 additional information found from its tabs, the project is still = in its=20 formation stage. There is no evidence of work product or=20 indication of work activity as of February 1, 2008. The = May 2007=20 Press release (English version, PDF=20 format) suggests results will appear by mid-2008. It = appears=20 that the start-up process, is moving slowly, especially with = regard to=20 enlisting partners in the formation of an expert group under the = FOKUS=20 research-and-development service. The only promised=20 output is a white paper. I speculate that everyone is = awaiting=20 the outcome of the DIS 29500 Ballot Resolution Meeting and = subsequent=20 vote updates. =20 [6] DIN: Deutsches Institut = f=C3=BCr=20 Normung (English home page), accessed 2008-02-01.=20 If you are searching for a public face of the Translation of = Document Formats working group, you will ~~have your work = cut out=20 for you~~ now find it at N= A=20 043-01-34-01 VT Working Group Translation=20 29500-26300. NIA, the short name for DIN = standards=20 committee NA 043, is responsible for standards in the area of=20 "Information technology and selected IT applications." NIA = has=20 over 300 projects. NIA provides the DIN delegation to the = Ballot=20 Resolution Meeting on OOXML. NIA subcommittee NA 043-01-34 = AA=20 (NIA-34) is the DIN counterpart for ISO/IEC JTC 1/SC 34. = It has=20 current responsibility for the DIN alignment with 54=20 ISO/IEC standards, including ISO/IEC 26300 (ODF) and DIS = 29500=20 (OOXML), the latter being one of the 15=20 active projects. NIA-34=20 is the home of the Translation of Document Formats Working = Group, but=20 there is was no account for that on the = DIN NIA=20 web site ~~at this time~~ as of (February 1, = 2008). [update 2008-03-06: There is a web = page=20 available and the February 20-produced PDF of the first working = draft is=20 available for download.] The most-complete = version of=20 the NIA-34=20 home page is in German. The English version simply = reports on=20 the DIN delegation to the DIS 29500 Ballot Resolution = Meeting. The=20 Translation Working Group was announced= =20 in May, 2007 (the English version translates "Tag" as = "date"). =20 Again, I suspect that experts interested in this activity have = been=20 preoccupied with Ballot Resolution Meeting review and = preparation. =20 Still, it's been a long time since May 2007. ~~They = may be=20 challenging my personal record for project silence (and my = silence=20 usually means very little is = happening).~~ =20 [7] SourceForge.net: OpenXML/ODF=20 Translator Add-In for Office. Project Page, accessed=20 2008-02-02.=20 This is the most-visible active project related to = translation=20 between ODF and OOXML. The Fraunhofer Institute and DIN = pprojects=20 rely on this effort [5,=20 6]. =20 There is documentation, extensive lists of problems and=20 incompatibilities, and ongoing activity. Although the work = is in=20 C# and XSLT, the documentation and test cases are important and = valuable=20 for those interested in higher-level understanding of = translation=20 issues. Until or unless the DIN and Fraunhofer activities = open up,=20 this is the most-concrete activity available for any kind of = reality=20 check. =20 [8] Charles W. Bailey, Jr: Harmonization=20 of Metadata Standards. Digital Koans (web = log),=20 2008-01-31.=20 Bailey quotes the introductory statement that summarizes the = obstacles reconciling metadata. =20 [9] Mikael Nilsson (ed.): Harmonization of = Metadata=20 Standards, Version 1.0, Deliverable D4.7, PROLEARN, European = Commission=20 Sixth Framework Project (IST-507310), 2008-01-21 (via Charles = Bailey [8]). =20 Accessed 2008-02-04 (468kB PDF=20 file).=20 The context for this report is summarized on this Wiki=20 page. The PDF File can be downloaded using the link in = the=20 Manifest section of the Wiki page. =20 [10] Dennis E. Hamilton: Magical=20 Thinking and the Universal Document Elixir. = Professor von=20 Clueless in the Blunder Dome (web log), 2005-10-17.=20 It would appear that there is still yearning for this = prospect, just=20 as it was claimed technically simple for Microsoft to adopt ODF = as a/the=20 native format for Microsoft Office after arranging suitable = additions in=20 ODF, if needed. If we propose to attempt this to some = degree of=20 success, we need to make that degree measurable and = confirmable. =20 =20 [11] ITD: OpenOffice.= org=20 2.0 Software. Open Standards - Frequently Asked = Questions,=20 User Resources, Open Document, Open Initiatives. Official = Web Site=20 of the Information Technology Division, Mass.gov. Accessed = 2008-02-06.=20 =20 [12] Rajiv Shah, et.al: Interoperability=20 Testing and Resources? (discussion thread) OpenDocumentXML.org,=20 accessed 2008-02-07 (via Rob=20 Weir via Gray=20 Knowlton via Doug=20 Mahugh)=20 There's an RSS feed (no full content though) for this site, = which=20 has room for technical matters as well as advocacy and product=20 news. On the particular thread, there is the only = indication I=20 have found that the OpenFormula effort is going to bear fruit in = ODF=20 1.2. More important to the current discussion, there is=20 identification of some test=20 suite and interoperability work by the Danish IT and Telecom = agency. The English slide=20 set of their report is fascinating. Although the = contributor=20 of the Danish material was also unsuccessful in finding anything = from=20 the Fraunhofer Institute and DIN efforts, I am heartened to see = this=20 other significant and responsibly-undertaken = work. =20 [13] Dennis E. Hamilton: ODF-OOXML:=20 nfoWorks for Harmony? Professor von Clueless in = the=20 Blunder Dome (web log), 2008-02-07 (2008-02-08 touch-ups).=20 Here are some ideas about being able to implement processors = of=20 open-standard document formats that don't use non-harmonized = features=20 and are therefore safe-enough with regard to how users employ=20 them. There are, of course, new open questions that arise = and the=20 whole undertaking might be fruitless. =20 [14] Brian Jones: Binar= y=20 Documentation (.doc, .xls, .ppt) and Translator Project Site are = now=20 live. Brian Jones: Open XML Formats (web log),=20 msdn.com, 2008-02-15.=20 There are links to the download location for the document = formats=20 and some useful comments about maintenance that may be required = to those=20 specifications. =20 [15] Stephen McGibbon: OpenXML=20 translator project on SourceForge. Notes2Self = (web=20 log), 2008-02-15.=20 The home = page of=20 the SourceForge project, to be developed by DIaLOGIKa with = Microsoft=20 guidance, is linked and the first three milestones are=20 summarized. This is a very difficult article to write. I thought it = would be=20 a quick summary of the situation, with some useful links to the = translator=20 projects in NIA-34. It is very disappointing to find so = little=20 public evidence of useful activity under NIA-34 and the Fraunhofer = Institute, with the only visible progress still that of the = OpenXML/ODF=20 Translator Add-In SourceForge project. [update 2008-02-08T10:35 -0800: I have finally = expressed some pent-up ideas about technical approaches to = practical=20 harmonization (and determining if there is useful feasibility) [13]. =20 I've updated this post to cross-reference to that emerging = material. =20 I'm also enjoying an exchange in the comments, though I want to = bring any=20 rejoinders of mine back to the thrust of this article, which does = not seem=20 to be fully understood (whether or not agreed=20 with). update 2008-02-07T12:11 -0800: = Thanks to=20 some incoming links to this article, I discovered resources that = very much=20 lift my heart with regard to the interoperability efforts of = public=20 organizations [12]. update=20 2008-02-07T10:33 -0800: The statement about semantic-free = use of=20 markup for its effect and nothing else was garbled and I reworded=20 it. Actually, this note explains it better, but I am = satisfied=20 enough. The point is that the application software is not = entrusted=20 with the semantics, it is simply expected to do the formatting in = a way=20 where whatever the author's intention is happens to be usefully=20 preserved.] posted by orcmid at 2/06/2008=20 09:11:00 PM *Comments:=20 This = is one of=20 the best posts I have ever read that describes the gap between = human=20 activity and work, and what that has to do with representations of = information in computer systems. (I'll tip my own hand here and = say that=20 the relationship between the two, while important, is tenuous at=20 best.) Good piece of exposition, orcmid. #=20 posted by Bill Anderson: 07 February, 2008 12:06 = I = think that=20 this posting misses a few critical things: (1) ODF isn't = limited to=20 OpenOffice. If OpenOffice isn't good enough, another ODF = application (such=20 as ones from IBM or Corel) should be. If the next version of = Office=20 doesn't have a feature or gratuitously increases your training = costs via a=20 radical GUI change (as Microsoft has) or arbitrarily decides to = drop=20 legacy file format support (as Microsoft has), you're out of=20 luck. (2) Microsoft has a poor history of displaying and = saving=20 files from one version of Office in another. There's no reason to = believe=20 this will change, so people are already* dealing with this. ODF = at least=20 provides some hope of escape since the format is set in = stone. (3)=20 the OOXML spec isn't implemented anywhere, even by Microsoft and = there's=20 no guarantee that it will implement the official spec and there's = ample=20 history that shows that they'll embrace and extend any spec they = support.=20 There's very little change with the DOC format = situation. (4)=20 There's zero reason to mass migrate all legacy DOC files. DOC is a = defacto=20 standard that's been reverse engineered to death and has several = apps that=20 are able to convert this format into a modern format as the = document is=20 needed with high accuracy. If an exact visual match is needed, = export to=20 PDF is the the best option. (5) People don't care about = formats=20 until it bites them where it hurts. Anyone who has a drawer full = of 8=20 track tapes or 5.25 inch floppies or Amiga OS 3.5 inch floppies = knows that=20 having the data is pointless useless you can access it properly. = Anyone=20 with a MS Word 2.0 document knows how badly even MS Office 2000 = mangles=20 it. Word 2.0 isn't that long ago, especially in government where = many docs=20 need to be kept for over 20 years. (6) If your data is = transitory=20 and you don't care about storing it, then it doesn't matter what = format or=20 application you use. Standardizing transient information reduces=20 flexibility within different departments. The only thing that = makes sense=20 to standardize this is to avoid vendor lock-in, but even this this = case,=20 standardizing any multi-vendor format is good enough. In = short, I=20 don't see what point you're trying to make. #=20 posted by Anonymous: 07 February, 2008 = 15:32=20 OK, = I'll=20 bite: (1) I haven't said that. I have only indicated that at = user level=20 it is not the format that people deal with or express much control = over=20 (apart from the general choice), it is the software product, and = that=20 applies to all of the software products. (2) I'm not so = sure how=20 poor Microsoft's history is, and we should probably calibrate that = somehow. However, ODF is not set in stone and it is ingenuous to = claim=20 so. (3) I hear this claim a lot. What is the basis for = that? Where=20 is it that new documents in Word 2007 when saved are not in OOXML? = Documentation please. (4) I don't think I raised this at = all. Where=20 do you see me promoting or even considering mass = migration? (5) You=20 are making my point about what people care about and what is at = their=20 level of attention. (6) I think the summary at the top of = the post=20 says all that I intend. I think it is material when one considers=20 interoperating using products of different vendors. I really was = not=20 addressing preservation, but I certainly agree that known = standards (de=20 factor or public) matter for that. #=20 posted by orcmid: 07 February, 2008 16:56 Here's my=20 followup: (1) The point I'm making is that I agree, but that = because=20 you're not locked in, you have choice on UI and function, which = can't=20 happen with OOXML (which is controlled by one vendor with self = interest in=20 vendor lock in). HTML-like formatting is perfectly good for email = and it's=20 all that many people need, so why should these users be burdened = with=20 something as large and complex as MS Office or OpenOffice? At the = opposite=20 end of the spectrum, there are highly technical desktop publishers = who=20 need a high degree of control and a lot of the "cute = user-friendly"=20 feature of MS Office or OpenOffice get in the way. Each needs a = different=20 interface and different application, but both can exchange = documents if=20 you have standardized the document format. (2a) Okay. = Calibrate=20 that against paper. I have a stack newspapers that I found between = the=20 floors from 1942. Although it's brown, sooty and fragile because = it wasn't=20 taken care of, it's still very readable. It paints a very = different=20 picture of the time than what's portrayed in the media. Or if you = want a=20 software calibration, ASCII text. I have some text documents from = my=20 Commodore 64 with my school projects that are still readable. I = also have=20 several books with TROFF formatting (created in the 1960s) that = still work=20 today on any modern Unix machine. Ditto for LaTex. Any good = document=20 format needs to be at least that good at keeping = legacy. (2b) ODF=20 1.0 is set in stone and so are ODF 1.1, etc. And all are = backwards=20 compatible since so many parties involved have a vested interest = in not=20 rewriting their tools. That's the whole purpose of=20 standardization. (3) Here's a reference for Microsoft = Office. #=20 posted by Anonymous: 08 February, 2008 = 04:50=20 Interesting.=20 OK, let's continue this a bit. (1) I don't see how OOXML, = the=20 format, has anything to do with UI lock-in. I think the people at = MindJet=20 would be surprised. I don't want to speculate so far out to = whether there=20 is lock-in. I think you and I are reading different things into my = comments about what users do, which applies to any UI and how = users train=20 themselves to a UI to get the results they want. I suppose in one = sense we=20 are agreeing on the phenomenon, but not on what OOXML has to do = with=20 it. (2a) I meant calibration on the extent to which = Microsoft has=20 broken its own formats in their successors. I'm with you on paper, = and=20 other enduring formats (text, etc.), although some of those have=20 incompatibilities, whether code-page dependencies in text and=20 e-mail-format difficulties. (2b) Considering that ODF is = still=20 incomplete/underspecified and the conformance requirements are=20 next-to-nill, how can you say ODF is set in stone? I just don't = follow=20 that and then ... (3) Your reference didn't come through. = I'd like=20 to see it. (3b) Also, I should have asked this = differently. Name=20 one ODF-supporting processor that implements the ODF spec and only = the ODF=20 spec, with no un[der]-specified in ODF content. That means no use = of=20 namespaces not supported in the ODF specification (and no abuse of = ones=20 that are). (7) So let's come back to the prospects for=20 harmonization. What are you views on that: possible? not possible? = irrelevant? dangerous? what? #=20 posted by orcmid: 08 February, 2008 09:55 Not = possible=20 unless dangerous. This is not something Microsoft would want, so = they=20 won't co-operate, and their sincere co-operation would be = absolutely=20 necessary because OOXML is, despite all the pages and pages, = seriously=20 underspecified and anyway a "harmonized" format wouldn't fly if = Microsoft=20 didn't adopt it. But there is one condition under which = Microsoft=20 would want it: If they controlled it. In which case it would = just be a=20 way of killing ODF. They'd end up with a "harmonized" format for = all the=20 different word processors to use--that only Microsoft Word could=20 use. Rufus Polson #=20 posted by Anonymous: 08 February, 2008 = 11:06=20 Here's the link=20 that got stripped=20 = out: http://surguy.net/articles/ooxml-validation-and-technical-review.= xml ooxml-validation-and-technical-review.xml #=20 posted by Anonymous: 08 February, 2008 = 17:11=20 Good = heavens, is=20 that all? This is pretty trivial. If it is the only example it is = mildly=20 ridiculous. I agree that it is a bug, and easy to see how = it got=20 there. (I bet MSFT didn't have a test case for this until it came = up in=20 the comment about the Translator project.) I figured there = was a=20 problem with Microsoft using more than what was in the spec, but = this is a=20 bug in the implementation of an initially-uncommon feature in the = spec. It=20 is a bug, though. This is in the section of OOXML on = versioning of=20 the format itself where a new attribute introduced by someone = making an=20 extension can be tagged to be ignored, preserved, or deleted by an = OOXML=20 processor that doesn't understand the extension. They were = not=20 honoring the instruction to preserve them. I wonder if this was = fixed in=20 Office 2007 Service Pack 1? I'll see if I can find the test file = and=20 check. I'll also see if the spec. is solid around what = should=20 happen if the content of the element that has such an attribute is = edited. #=20 posted by orcmid: 08 February, 2008 19:52 Oops! Not a=20 bug. OK, I looked into ECMA-379, Part 5, clause 9.1.3, = and it=20 is not a bug. The relevant bits are on p.17, lines 5-23 just = before clause=20 9.1.3.1: "Even in the presence of explicit preservation = guidance in=20 a markup specification, any markup editor might choose to discard = together=20 all ignored markup without regard to the presence of any = PreserveElements=20 or PreserveAttributes attribute. ... [M]arkup consumers shall = always=20 accept, but possibly disregard PreserveElements and = PreserveAttributes=20 attributes on any element." It turns out that the = PreservElements=20 and PreserveAttributes stipulations are hints, and it is not = mandatory to=20 honor them. So technically, as much as I don't like it = myself, the=20 behavior of Microsoft Office Word 2007 is acceptable either way. = There are=20 other nuances, but this is the bottom line of what ECMA-357 says = on the=20 topic. #=20 posted by orcmid: 08 February, 2008 22:17 Post=20 a Comment