RE: Results of Open XML balloting at INCITS
Hi Jim: I get it. I'm not sure it matters past the contracts department. <shortForm> If ISO passes it this year or next year, OOXML will pass. A two standard world isn't going to change much that isn't already changing. Both of the competitors are obsolete. We are in a post-growth market for WYSIWYG and spreadsheets. Pre-growth analogies don't apply. If ISO rebuffed OOXML, MS would be able to claim it tried to open up but was turned away. ISO would be right back where it was when it was claimed it was too slow to create standards for the web given Internet Time and the W3C would still have rigor mortis given poisoning by gluttony. Weird how that works out. Everyone loses but Microsoft. Meanwhile current legal information is being entered into gridviews and tied by stored procedures to variant SQL databases to be displayed as HTML with CSS. So much for page fidelity. No one loses but 3M and loggers. Makes one wonder what this fuss is buying us except endorphin highs. </shortForm> <longform> deleted in the short term interest of balance of trade with China </longform> len From: Jim Melton [mailto:jim.melton@a...] Len, Some wise person (the identity seems to vary with the teller of the story) is alleged to have once said that "The nice thing about standards is that there are so many of them". When that line is quoted, it seems most often to be in the context of "There are multiple conflicting standards that could be chosen as the basis for my application -- how on earth am I supposed to figure out which one is 'better' in my situation?" The relational database industry, of which I have been a part for...ummm...a long time, is an $N-billion industry today (N somewhere between 20 and 250, depending on exactly how wide one casts one's net). It grew from $0.00 to that largish number in less than 25 years, most of the explosive growth occurring between the fifth and 15th years. When the standards agency that first promulgates the SQL standard in late 1986, that pretty much settled the question of "What language should I use for writing my database code?" and the industry took off with a shot. But, if that agency had chosen to (which it was strongly encouraged to) promulgate two, three, or more standards for various database languages (e.g., the arguably "better" QUEL from Ingres), I think that confusion would have continued to reign and that the marketplace would have taken off much more slowly. It is possible that we would still be mired in the quagmire of having different vendors promoting different "standard" database languages and locking their customers in on that basis. (Oops...the many implementation variants of SQL have a similar effect, arguably a good reason for standardizing even earlier.) There are environments in which international standardization is extremely relevant for a variety of reasons (e.g., marketing high technology products in China because of a government mandate) and there are environments where it is not (e.g., in a dyed-in-the-wool Microsoft or Apple shop). When standards are important -- mandatory or merely corporate policy -- it's nice to have one good standard from which to choose; minimally, there "must" be clear criteria for making the choice between multiple, overlapping or conflicting, standards. In the case before us today, the only obvious criterion that I see is "vendor neutral vs proprietary" (most decision makers will not understand, or even perceive, the technical distinctions). That criterion isn't very helpful, because there are environments in which vendor neutrality is vital and others where a single-vendor solution is acceptable or even desirable. Why, then, would the owner of the proprietary spec care whether or not that spec becomes an international standard? It's simple: To be able to persuade customers who want a truly neutral standard that will keep them out of vendor lock-in to believe that their proprietary spec satisfies that need so the customers will buy products built to that "proprietary-standard" spec instead of the more neutral one. It is, of course, a long-standing tradition in the standards world of a particular party hoping to get its specs anointed as a "standard" while that party's competitors try to have that spec altered sufficiently that everybody -- including the original party -- gets to share the pain of conforming to it in approximately equal measure. I'll grant you this: that's a politico-economic argument rather than a technical one. But politics and economics are ultimately how most of us manage to get paid a salary. If my competitor gains significant market advantage by having his specs anointed in a manner that moves customers from my products to his, then I've got a problem. Sure, I'd like to do that to him, but a much more palatable approach to the many fleas on the elephants (so to speak) is to have vendor-neutral specs on which even the fleas have had some direct influence. Sigh...that got longer than I'd planned, but (another wise person): I'm sorry this is so long, but I didn't have time to make it shorter. Hope this helps, Jim At 8/12/2007 08:31 PM, Len Bullard wrote: >The problem would still be policy that states standards are the basis of >procurement without naming a standard. Under such conditions, OOXML has >to seek standards status. If the objection is controversy but there are no >definitions for what constitutes controversy, this is still a matter of >voting. As to the need for fast tracking, I am neutral as long as the >reasons are technical. It may not be policy but it is common sense and the >way I *would want* American representatives to vote. > >We have to disagree on the 'only one international standard' position, Ken. >There are side-effects that can damage international standards practice and >culture. Under such a policy, choice is removed along with competition. I >think we probably disagree on the potential severity of the first if not the >fecundity of the latter. > >len > > >From: G. Ken Holman [mailto:gkholman@C...] > >Michael Kay said: > > > >http://consortiuminfo.org/standardsblog/article.php?story=2007022819130536 > > > >That is about responses to the contradictions period, which is a different > >stage in the process. ISO basically said "No", or rather "None of what you > >say is a showstopper that requires extraordinary intervention, these > >issues can go on and be addressed by the normal process": the current > >ballot produces the big issue list to get resolved. > >As I understand it, it wasn't ISO that said that but that, per the >directives, ISO invited Ecma to make comment on the allegations >coming out of contradiction period. Ecma then authored the "not a >showstopper" words based on its interpretation of the contradiction >comments and ISO dutifully distributed Ecma's words (as it would for >any fast track submitter) to the national bodies as the submitter's >response to the allegations of contradiction. > >I do not recall seeing a single ISO/ITTF assessment or official >summary of the contradiction allegations or the Ecma disposition of >those allegations. I've only seen Ecma documents circulated. The >Directives section 13.4 cites in parts "consulting with the proposer >of the fast-track document... if the resolution results in no change >to the document or if a resolution cannot be reached, the fie month >fast-track ballot commences immediately ... JTC 1 shall circulate the >comments and the disposition of such comments". > >I don't remember seeing any ISO/ITTF document stating in effect "none >of what is said is a show-stopper". > > >The other thing to realize is that no means yes. When a nation gives a no > >vote, they have to give the technical reasons why not and suggest their > >preferred fixes. > >Not true ... a national body is not obliged to give technical reasons >for a no vote. National bodies and other voting members are welcome >to vote no with non-technical reasons that have no resolution. Their >vote is counted as is all the others. This was confirmed with JTC >1. The comment about technical reasons only was misinformation >disseminated at the Seoul plenary meeting of SC 34. > >I'm posting the following comments with my XML developer hat on and >not in any official capacity regarding my standardization >responsibilities. As my private opinions on this matter were >intentionally outed against my expressed wishes by one of the >companies involved, I feel I can now comment openly with my own >opinions about this situation. > >I see ISO/IEC 26300 ODF is an XML vocabulary for office documents. > >I see DIS 29500 OOXML is an XML vocabulary for office documents. > >Adding the faerie dust of international standardization does not, in >my opinion, add anything to any legacy of existing documents that are >already in XML. The legacy and any related prevalence of existing >documents is immaterial. Legacy users of OOXML don't gain anything >by the specification becoming an international standard. Having >already chosen to use XML they get the benefits of longevity and of >access using markup-based tools. International standardization >doesn't change that. > >I wish I had thought to say this but a good friend (I haven't got >time to get his permission to attribute him) made the astute >observation that the phrase "Open XML" is redundant like the phrase >"edible food" is. "Office Open XML" is no better than just "Office >XML". Existing legacy users of "Office XML" are already getting the >benefit of using XML markup and deeming that markup to be an >international standard does not add anything at all to their legacy >investment. > >But think of a customer asking a developer to "please create an >XML-based expression of this information I have that I would like to >maintain in a spreadsheet application, and I don't care about the >application but I do care about the data". If there are no standard >formats, the choice is muddy. If there are two formats to choose >from, a standard format and a proprietary format, the choice is >clear. If there are two standardized formats, the choice is muddy again. > >International standards development processes exist to accommodate >such contradictions: when an existing standard does not meet >identified user requirements satisfied by a specification that would >be in contradiction, the maintenance of the specification should >address the user requirements following an established process. > >Therefore, to move forward the community should focus on new >developments and what choices in standardization there are when a >developer creates a new project or a vendor creates a new tool or a >customer creates a new need. There should be a clear choice to move >forward and not a confusing choice to move forward. > >I think there should only be one internationally-standardized XML >vocabulary for office documents and that the existing one should be >augmented to address identified user requirements brought to the >maintenance process through proper channels. The fast track process >is not a standards development process but a ratification process and >if it isn't clear that the specification can be ratified easily and >without contradiction then the user requirements addressed by the >fast track should have gone through a traditional open standards >development process. > >And OOXML still has a chance to do so, just in my opinion not as an >ISO fast track. I don't have anything against OOXML as a vendor's >choice format, or even Ecma's choice of format for its member >organizations. My opinion about how easy or not easy it is to work >with OOXML is not relevant. The OOXML developers worked hard to >produce an XML vocabulary that meets their needs and they have >valuable input to the development process as a result. I'm focused >here on process and the impact of having more than one international >standard when there is an opportunity to prevent having more than one >by going through development processes and not fast track processes. > >I hope this is considered helpful. > >. . . . . . . . . . . . Ken (speaking only for myself) > > > > >_______________________________________________________________________ > >XML-DEV is a publicly archived, unmoderated list hosted by OASIS >to support XML implementation and development. To minimize >spam in the archives, you must subscribe before posting. > >[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ >Or unsubscribe: xml-dev-unsubscribe@l... >subscribe: xml-dev-subscribe@l... >List archive: http://lists.xml.org/archives/xml-dev/ >List Guidelines: http://www.oasis-open.org/maillists/guidelines.php ======================================================================== Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144 Co-Chair, W3C XML Query WG; F&O (etc.) editor Fax : +1.801.942.3345 Oracle Corporation Oracle Email: jim dot melton at oracle dot com 1930 Viscounti Drive Standards email: jim dot melton at acm dot org Sandy, UT 84093-1063 USA Personal email: jim at melton dot name ======================================================================== = Facts are facts. But any opinions expressed are the opinions = = only of myself and may or may not reflect the opinions of anybody = = else with whom I may or may not have discussed the issues at hand. = ======================================================================== _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
[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