From owner-incits-v1@incits-v1.org Sun Jun 24 16:22:50 2007 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Date: Sun, 24 Jun 2007 19:21:46 -0700 From: Patrick Durusau Subject: Re: INCITS-V1: NamingDIS29500-Durasau-12 In-reply-to: Sender: owner-incits-v1@incits-v1.org To: incits-v1@incits-v1.org Reply-to: incits-v1@incits-v1.org X-PMX-Version: 5.2.0.264296 X-ASG-Debug-ID: 1182727313-0ff200420000-E618Iy X-Barracuda-URL: http://10.10.100.8:8000/cgi-bin/mark.cgi X-Barracuda-Connect: unknown[66.110.197.207] X-Barracuda-Start-Time: 1182727313 X-ASG-Whitelist: Client X-ASG-Orig-Subj: Re: INCITS-V1: NamingDIS29500-Durasau-12 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at insimail.com Doug, Doug Mahugh wrote: > > > I'm having trouble seeing how this benefits anyone except users and > developers of Microsoft products > > Steve, I donÂ’t understand that comment. The interoperability enabled > by the customXml element, for instance, is a of great benefit to the > organizations that take advantage of custom-schema support in Office > documents: everyone from Mindjet and A.C. Neilsen to the Florida House > of Representatives and many others. > > This is an interoperability benefit you canÂ’t get with ODF. With ODF, > you have your own tags interleaved into the content, which risks > reducing interoperability in the future. As is covered in the first > paragraph of the Conformance section 1.5 of ISO/IEC 26300, you have to > use a preprocessing stage to strip out those foreign elements, but > with the Open XML approach you just have customXml elements (which are > valid WordprocessingML), so thereÂ’s no preprocessing required – itÂ’s > essentially the same architecture that microformats use to add > semantics to HTML without reducing interoperability in the future. > A quick caution, I don't think we need to discuss the relative features of ODF and OpenXML in evaluating DIS 29500. Besides, Doug's statement is not factually correct. The language of Section in 1.5 is not the best in the world but reading it with the next paragraph, which says that conforming applications may preserve foreign elements and attributes makes it clear that validation is "as though" the foreign elements and attributes were not present. There is *no* mandated preprocessing step. How you choose to ignore foreign elements and attributes is application specific. Stripping them is one rather primitive technique but there are others. I won't comment on how that compares with interoperability with DIS 29500 because as I said at the outset, our job is *not* a comparison of the merits of these two items. Our job, at least as I understand it, is to examine the text of DIS 29500 and to make comments on it that we think will result in a better proposal. How it compares with ISO/IEC 26300 in terms of features is a discussion for another day and hopefully, at least in my view, another forum. I hope you are having a great day! Patrick > > Interoperability isnÂ’t enabled by assertion, itÂ’s enabled by careful > attention to these sorts of details, and DIS 29500 has allowed for > improved interoperability in this area relative to other approaches. > All Open XML document bodies can be validated against the Ecma > reference schemas and nothing else, and that improves interoperability > relative to approaches that interleave non-standard schemas into the > body of a document. > > - Doug > > *From:* owner-incits-v1@incits-v1.org > [mailto:owner-incits-v1@incits-v1.org] *On Behalf Of *Steve Carton > *Sent:* Sunday, June 24, 2007 3:28 PM > *To:* incits-v1@incits-v1.org > *Subject:* RE: INCITS-V1: NamingDIS29500-Durasau-12 > > Okay -- I accept the rebuke -- I should have included the MS Office > Suite and not just MS Word in my missive. And your examples of the > kinds of implementations that are enabled in whole or in part by OOXML > are interesting and impressive. And perhaps these support an argument > for DIS29500 with changes to the informative sections that match the > technical advances as you are describing. > > I agree that Microsoft should expose a format that non-MS software and > people can use. But I'm not quite seeing how that makes a need for a > standard, especially since standards are (at least in part) supposed > to empower interoperability, and so far I'm having trouble seeing how > this benefits anyone except users and developers of Microsoft products > (large though that universe is, I grant you). > > Moreover, I don't see the argument that we need more than one document > standard as persuasive -- again because of interoperability. > > Steve Carton > > ------------------------------------------------------------------------ > > *From:* owner-incits-v1@incits-v1.org > [mailto:owner-incits-v1@incits-v1.org] *On Behalf Of *Stephen Peront > *Sent:* Sunday, June 24, 2007 5:48 PM > *To:* incits-v1@incits-v1.org > *Subject:* RE: INCITS-V1: NamingDIS29500-Durasau-12 > > Hi SteveÂ… > > I can speak to the value of this. Although this may have the > appearance of just being “a format for representing Microsoft Word > documents”; that could not be farther from the truth. > > Here are (just) some of the differences: > > · OOXML defines specifications for marking up 3 types of documents: > spreadsheets (SpreadsheetML), presentations (PresentationML) and word > processing (WordprocessingML) documents > > · The format allows for implementers to build their own document types > from these starting points. As an example, Xinnovation is creating our > own document type built on OOXML that is used to describe document > assembly documents; there are many other partners out there who are > working on similar new formats using the standard. > > · The standard also allows for the insertion of multiple XML document > types into any of these documents without having to create a mutually > agreed upon schema, XSD, or XSLT (transformation) with the creator of > the host document. For example, I can add some XML into a > PresentationML document by using a relationship without ever having to > contact MS; this relationship then can be fully used by any consumer > to add value to the document > > · We are working with major organizations (such as the SEC, FDA, etcÂ…) > to drive conformance of standards and introduce interoperability of > their systems with other international systems by leveraging formats > like PDF, ODF and OOXML. In working with these organizations and many > more, no one of these open standards meets all the requirements, but > when all three are combined together, we are able to meet the > objectives of these organizations. > > · We are living in a changing world and many businesses, government > agencies and government regulated organizations are being forced to be > able to interoperate with and require conformance from small > businesses. One great example of this is the FDA regulations on drug > companies for submitting information in an eCTD conformant way. IÂ’d > encourage you to look at the mind boggling requirements of this > standard and try to meet these requirements in a PDF and ODF only > world. OOXML supports some unique capabilities that make it easy for > the FDA to be able to get the drug companies to conform. > > · There are many more benefits that I possibly could not write them > all down > > > Do we need a standard at all for the XML model of legacy content of a > proprietary product line? > > The obvious answer to this is “no”; if someone wants to work with > Word, PowerPoint or Excel 2003, XP, or further back documents, they > should create “legacy” applications. > > Maybe a different question that this committee should be asking is, > “Does it benefit the US if Microsoft opens its Office document formats > to the public?” > > Considering that a large percent of government computers and a huge > number of US (and international) businesses use Microsoft Office, I > think it is in the best interest of the US to ask MS to make their > formats an open standard. A great example that proves this is an > agreement that this committee made during email discussions in April > and May. The suggestion was made, “I'd recommend that we submit our > final comments in ODF if possible” and even this committee chose to > work with Word because of current submission requirements and comments > like this one “I'm not on ODF. Why not just stick with Word, or use a > PDF format, but I think life will be much simpler for everyone with > the Word approach”. I might add that this is the common request that I > have heard out in the business world when asking if we could implement > ODF or PDF as a standard format for each respective organization. > > Action #1 outlined for this committee is, in part: > > The committee is to coordinate and develop the U.S. recommended > position to INCITS EB for approval for submission to ISO/IEC JTC 1. > > There are many good arguments to be made for why the US should > recommend that OOXML should be approved for submission to ISO/IEC JTC > 1; I have yet to hear a good argument why we should not. The only > reason I have heard so far is that there is a different document > standard (i.e. ODF); which is a weak argument considering that our > world is far too diverse to be founded on one standard in any one area. > > This is especially true when considering **document standards** due to > the high frequency and extreme diversity of documents in the current > world. > > What are your thoughts? > > Have an awesome day! > > Cheers, > > -Stephen > > *From:* owner-incits-v1@incits-v1.org > [mailto:owner-incits-v1@incits-v1.org] *On Behalf Of *Steve Carton > *Sent:* Sunday, June 24, 2007 5:03 PM > *To:* incits-v1@incits-v1.org > *Subject:* RE: INCITS-V1: NamingDIS29500-Durasau-12 > > I personally get annoyed with arguments that attack the intentions of > others. Saying that the name "Office Open XML" is "designed to cause > confusion" is argumentative here. But, that begs the question. > Irrespective of the authors' intentions, confusion is the result. > > As I read through the DIS 29550 documents (a slow process at best), > the thing that strikes me first is that this clearly seems to be a > format for representing Microsoft Word documents. How is this "open"? > > Do we need a standard at all for the XML model of legacy content of a > proprietary product line? The proprietary application vendor could > simply open their XML format up to the world. What additional purpose > is served by labeling it as a standard? Or am I missing something? > > Steve Carton > > Retrieval Systems Corporation > > 2071 Chain Bridge Road > > Suite 510 > > Vienna, VA 22182 > > 703-749-0012 > > ------------------------------------------------------------------------ > > *From:* owner-incits-v1@incits-v1.org > [mailto:owner-incits-v1@incits-v1.org] *On Behalf Of > *robert_weir@us.ibm.com > *Sent:* Sunday, June 24, 2007 3:06 PM > *To:* incits-v1@incits-v1.org > *Subject:* Re: INCITS-V1: NamingDIS29500-Durasau-12 > > > > > > > What *does* move me to agree that the name "Office Open XML" > > should be changed is that it is designed to cause confusion with > > OpenOffice, a leading open-source ODF application. It is not the > > purpose of the standards we work on to cause confusion, and > > certainly not to deliberately cause confusion. The name should be > > changed to something that avoids this confusion rather than > > actively promoting it. > > > > Jon > > > > I'd second that. I've done some research in this area to see how often > the name of the standard is misstated as "Open Office XML". This is > happening everywhere, and by doing so is causing user confusion as > well as diluting the value of the Open Office trademark. For examples, > query Google for "Ecma Open Office XML" or "Microsoft Open Office > XML". You should get zero hits for these phrases, but instead you get > hundreds of hits, from the press, from analysts, even from Microsoft. > > I've updated my analysis of this problem here: > http://www.robweir.com/blog/2007/01/amusing-but-still-confusing.html > > I'd like to see us submit a comment requesting a name change. Maybe > "Legacy Office XML" or LOX. > > -Rob > > ___________________________ > > Rob Weir > Software Architect > Workplace, Portal and Collaboration Software > IBM Software Group > > email: robert_weir@us.ibm.com > phone: 1-978-399-7122 > blog: http://www.robweir.com/blog/ > -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps) Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300)