From Doug.Mahugh@microsoft.com Thu May 17 10:49:43 2007 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Date: Thu, 17 May 2007 10:48:52 -0700 From: Doug Mahugh Subject: RE: DIS 29500 Contradiction of ISO/IEC 26300, part 7 In-reply-to: <464C4D6E.7030007@durusau.net> To: "patrick@durusau.net" , Dave Welsh , Frank Farance , Jerry Smith , Jon Bosak , "Levine, Leonard F CIV DISA GES-E" , Norm Walsh , "Lynne A. Price" , Rex Jaeschke , Richard Barber , Robert Weir , Steve Carton , Tim Schoechle , "Mason, James David (MXM)" , Kevin Trainor , Eduardo Gutentag Content-language: en-US Accept-Language: en-US Thread-topic: DIS 29500 Contradiction of ISO/IEC 26300, part 7 Thread-index: AceYgPWkHsZOSOuUTce7lqS68tnaHAAKoVkw acceptlanguage: en-US X-PMX-Version: 5.2.0.264296 X-MS-Has-Attach: X-MS-TNEF-Correlator: Hi Patrick, In my opinion, the statement "the purpose of DIS 29500 is to provide an XML representation of Microsoft Office 97-2003 binary formats" is correct but incomplete. So your entire argument put forth in the series of seven emails this morning starts from a misleading and incomplete assertion. I'll try to explain ... DIS 29500 serves other purposes that are not served by ISO/IEC 26300, especially in the area of integration options for external schemas. (By "external" I mean schemas that are not part of the spec itself -- in common usage we tend to call these "custom schemas" as opposed to the "reference schemas" in DIS 29500). I teach Open XML workshops for developers, and the capability to embed custom schemas into documents is something many developers find useful and exciting, and it's something ISO/IEC 26300 has never made any attempt to address. For example, I routinely show developers how we can create a schema on the spot (one that has never existed before), and embed instances of that schema in Open XML documents and/or tag the content of Open XML documents with that schema. This has no impact on interoperability within the world of simple desktop applications (such as word-processing programs), because the documents are still well-formed Open XML and consistent with the DIS 29500 spec. As a simple example, the tagging of content with that custom schema only adds customXml elements to the document body, which are part of the WordprocessingML schema, and the custom elements appear as attributes of those customXml elements. This allows the document body to be well-formed WordprocessingML even though custom semantics have been added, just as microformats (with their encoding of semantics in class attributes) allow HTML documents to continue to be well-formed XHTML even though non-HTML semantics have been added. But -- and here's the benefit that makes custom schema support so useful to developers -- the embedding of those customs schemas enables interoperability with other types of systems (custom systems typically) that is not possible through the use of any other existing standard, including ISO/IEC 26300. Other systems can read content from the document based on their own semantics, as defined in schemas external to DIS 29500, and that makes many types of solutions possible that could never be implemented with ISO/IEC 26300. Consider Mindjet's integration between Word 2007 and their Mindmanager product, which has been shipping since late last year. They embed instances of their own proprietary schemas into a DOCM, enabling lossless round-trip interoperability between the two products. Sure, they also throw some VBA macros and other stuff in there, but that has nothing to do with the core architecture of the solution. As an example of that, you can do a lossless round trip between Mindmanager and Word 2007 without ever enabling macros in Word, so that the VBA stuff and the ribbon extensibility never even happens. To use an extreme analogy (just to make my point clear), saying that "the purpose of DIS 29500 is to provide an XML representation of Microsoft Office 97-2003 binary formats" is like saying "the purpose of ISO/IEC 26300 is to provide an XML representation of a document's page-margin requirements" -- technically correct, but incomplete and therefore misleading. - Doug -----Original Message----- From: Patrick Durusau [mailto:patrick@durusau.net] Sent: Thursday, May 17, 2007 5:41 AM To: Dave Welsh; Doug Mahugh; Frank Farance; Jerry Smith; Jon Bosak; Levine, Leonard F CIV DISA GES-E; Norm Walsh; Lynne A. Price; Rex Jaeschke; Richard Barber; Robert Weir; Steve Carton; Tim Schoechle; Mason, James David (MXM); Kevin Trainor; Eduardo Gutentag Subject: DIS 29500 Contradiction of ISO/IEC 26300, part 7 Greetings! I think based on the foregoing we should take the following position: That an apparent contradiction exists between DIS 29500 and ISO/IEC 26300 and for that reason we should vote no with comments as follows: **** Comment: The US NB perceives a contradiction between DIS 29500 and ISO/IEC 26300. That contradiction can be resolved by the following steps: 1. Ecma discloses and includes in DIS 29500, a normative mapping from the binary formats of Microsoft Office 97-2003 to the XML format it defines. 2. Ecma demonstrates that the mapping from #1 cannot be achieved with ISO/IEC 26300. (Allowing for responses by NBs or other interested parties.) If Ecma provides the mapping requested in #1 and demonstrates that ISO/IEC 26300 cannot map the information in question in the XML format it defines (#2), considering any contrary suggestions, then the US NB will change its vote on this issue to yes. **** I think that this approach takes the issue away from the "blog collective" and places it on firm technical grounds. We may still disagree on some points but I trust the depth of experience with XML represented in V1 will lead us to largely the same conclusons. Or enough so that we can reach a consensus on the comment and proposed resolution (assuming we don't agree on every minor point). Hope everyone is having a great day! Patrick PS: Question: I have been told but don't know of my own personal knowledge that the binary formats of Microsoft Office 97 - 2003 may have changed with service pack releases. Can someone confirm that information or provide a pointer to the answer? If that is true, a normative mapping would have to account for those changes. -- Patrick Durusau Patrick@Durusau.net Chair, V1 - Text Processing: Office and Publishing Systems Interface Co-Editor, ISO 13250, Topic Maps -- Reference Model Member, Text Encoding Initiative Board of Directors, 2003-2005 Topic Maps: Human, not artificial, intelligence at work!