Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Orcmid's Lair
 
Praxis101
 
Spanner Wingnut's Muddleware Lab

Recent Items
 
A Conceptual Architect Am I?
 
Cybersmith: Attributions for Code You Use
 
DMware: ODMA's Dark Matter
 
Cybersmith: No-friction Bits and Pieces
 
VC++ Novice: Is Native C++ a Dead Language?
 
nfoWorks: What Are those Harmony Principles, Agai...
 
nfoWorks: Tracking OOXML DIS 29500 into the Blue
 
nfoWorks: The ISO/IEC Harmonization Opportunity
 
nfoWorks: In Search of Initiative
 
nfoWorks: The Harmony Get-Ready

Archives
2004-06-13
2004-06-20
2004-06-27
2004-08-29
2004-09-05
2004-09-12
2004-09-19
2004-10-10
2004-10-24
2004-11-07
2004-11-28
2004-12-05
2004-12-12
2004-12-26
2005-01-30
2005-02-06
2005-03-06
2005-03-13
2005-03-20
2005-04-03
2005-04-10
2005-04-17
2005-04-24
2005-05-01
2005-05-08
2005-05-15
2005-05-29
2005-06-05
2005-06-12
2005-06-19
2005-06-26
2005-07-10
2005-07-17
2005-07-31
2005-08-28
2005-10-09
2005-10-16
2005-10-23
2005-11-13
2005-11-27
2005-12-04
2005-12-18
2006-01-08
2006-02-05
2006-02-12
2006-02-19
2006-03-05
2006-03-12
2006-03-26
2006-04-23
2006-04-30
2006-07-16
2006-07-30
2006-08-06
2006-09-03
2006-10-08
2006-10-22
2006-10-29
2006-11-26
2006-12-10
2007-01-28
2007-02-04
2007-02-11
2007-03-11
2007-03-25
2007-04-08
2007-06-03
2007-06-10
2007-06-17
2007-07-01
2007-07-08
2007-08-19
2007-09-30
2007-10-07
2007-10-21
2007-11-04
2007-11-11
2007-11-18
2007-11-25
2008-01-27
2008-02-03
2008-02-10
2008-02-17
2008-02-24
2008-03-09
2008-04-06
2008-05-18
2008-05-25
2008-06-01
2008-06-08

A Conceptual Architect Am I?

I am working on an article, "The Working of Computation," that applies What Computers Know and the secretly-connected Reality is the Model.  This is a lead-up to the long-delayed What Programmers (Should) Know and, ultimately, Bridging the Gap that Cannot Close.   This is seriously intended to have practical significance, no matter how abstractly it is couched.

In working on some diagrams, I noticed that some particular ones are very conceptual.  I want to call them some sort of architecture, not some sort of model.  I have used "performance architecture" as the term for a long time, and I was wondering whether "conceptual architecture" might be preferable.

With that in the back of my mind, I stumbled over this article earlier today: "CaaS Conceptual Architecture."  Since the term seems to be in use, I wondered whether it is being applied in a way that works for my situation as well.  Going from the cartoon, it appears to be a typical architectural "stack" diagram:

The Channel 9 videocast explains that this is about the pieces that can be combined to provide the architected facility (an instance of Communication as a Service, in this case).  The color codes indicate the degree of control that is available for composing such a structure: red (little or no control), yellow (some control), blue (have a ball).

I'm satisfied that I am offering something similarly conceptual but from a different perspective and using a different form of diagram.

Just to check on the use of the term, I also did a search on "conceptual architecture."  Here the trouble started.

On Wikipedia, I learn that "conceptual architecture" is a particular architectural style in the architecture of physical structures.  Conceptual architecture features "the construction of a concept" in contrast to architectural focus on craft and construction.  I would not have been surprised to see Christopher Alexander connected in some way, but that is apparently not the case. Well, as applied to computational systems, maybe I am constructing concepts, although I'm not familiar with those famous architects nor conceptualism as a doctrine.  The doctrine has to with considering that universals have no objective reality and are, more or less, mental: objects of thought.  I'm not prepared to make any metaphysical claims on that topic.

I recently had to satisfy myself once again that I am not a Platonist, and now I have do deal with being a Conceptualist or not?

I think I will ignore the implications and stick with diagrams being used to establish an abstracted, conceptual perspective of a subject and leave it at that for now.  Some of the diagrams will be highly conceptual (a.k.a, diagrammatic) and also helpful in organizing a conceptualization of the subject.   Ahh, I think I should just go finish the article I have in mind.

Cybersmith: Attributions for Code You Use

If you choose to distribute open-source code, or create software that relies on licensed code of others, you'll have to deal with two issues:

1. what licenses you are willing to agree to for code that you rely on, and how you provide attribution to the third-party works that your software depends on
     
2. What license you will offer to others and how you want others to be able to understand your license requirements

These are interdependent considerations.  Here I focus mainly on the first case because an useful example has come up.

Facebook has open-sourced a big chunk of its platform using CPAL, the Common Public Attribution License.  This is an OSI-approved open-source license.  Mike Gunderloy has opined that the attribution requirement that Facebook has specified in the license is onerous and designed to prevent others using the code because it requires that

"each time an Executable and Source Code or a Larger Work is launched or run, a prominent display of the Original Developer's Attribution Notice (as defined below) must occur on the graphic user interface (which may include display on a splash screen)"

where the specific attribution to be carried into derivative code is

"Attribution Copyright Notice: Copyright © 2006-2008 Facebook, Inc.
Attribution Phrase (not exceeding 10 words): Based on Facebook Open Platform
Attribution URL: http://developers.facebook.com/fbopen
Graphic Image as provided in the Covered Code: http://developers.facebook.com/fbopen/image/logo.png"

quoting from the Facebook version of the CPAL license.  Gunderloy makes the observation that

"While this seems reasonable to recognize the work of the Facebook developers, it does act as a sort of 'poison pill' to prevent others from simply cloning Facebook on to their own sites - at least, others who don't want to give prominent credit to a rival."

Gunderloy seems to forget that one can always negotiate a different license with Facebook.  He does point out that Facebook did not make use of the CPAL dual-license provision and the license as used is GPL-incompatible because CPAL is a derivative of the GPL-incompatible Mozilla license.

Dare Obasanjo has posted his "Thoughts on Facebook's usage of the CPAL as a 'Poison Pill' and Other Such Nonsense."  Obasanjo does not think the attribution requirement is all that onerous, and I agree, although I think the requirement of prominent advertising is a bit heavy-handed. 

I would not use CPAL-licensed code simply because the license is too bloody long and complicated.  It also appears to be a reciprocal license, although I am not going to dive in close enough to be certain.  I pretty-consistently avoid making derivative works of reciprocally-licensed code although I can imagine conditions where I would be willing. 

One of my principle concerns in choosing an open-source license is that the license be dirt simple.  I want recipients to easily determine and be very clear on what they are permitted to do, with simple conditions on compliance.  I prefer something that can be fronted by a statement as simple as a Creative Commons Attribution Deed. 

Obasanjo notes that the BSD license requires attribution too (you must carry forward a copy of the original notice).  This has not bothered open-source efforts that use BSD code, even if under some GPL version. Sun pretty much has the practice down pat in its open-source efforts and closed-source ones too, with the THIRDPARTYLICENSEREADME that is commonly found in directories of programs such as OpenOffice.org.

When the extreme anarcho-libertarian wing of the open-source folk overcome their fear of being taken advantage of , they might notice another very important reason to provide accurate attribution. It provides an account of the provenance of their code and can be important in determining whether it might carry a later-discovered security exposure or bug reported in the original version. Attributions are an important feature of accountability, which is why I provide attributions whether or not they are required by licensed code that I incorporate or make derivatives of.

I am not interested in going overboard on the "prominent display" aspect.  I think provision in conjunction with a Help | About ... menu item is fine.  That's good enough for my attribution concerns.  And, meanwhile, the standard rules apply: if you don't like the license, don't use the licensed work in ways where the unpleasant terms come to bear. 

If you are wary of signing your own work and of providing attributions of your sources, that's fine.  There is apparently a large community of like-minded folk who fear some sort of liability around simply being accountable.  I will decline to let your code anywhere near any effort of mine, however.   I'm also that way if the license for your code is not one I am willing to work under.  It's simple, really.

I would normally have made this a simple comment on Obasanjo's blog, except some sort of Web 2.0-ish updates to the blog has my commenting-effort fail.  There are some annoying pop-ups that I don't understand but that I can't dismiss, even though the site remembers my profile information and allows me to enter a comment.  I just can't submit it because there is some sort of coComment failure every time I try.  I'll have to hunt down Dare's e-mail address and let him know that this is a mess.  Meanwhile, I've fleshed this out as an appropriate cybersmith topic.

 
Comments:

 
I turned of CoComment on my blog.

# posted by  Dare Obasanjo: 06 June, 2008 12:22

 

 
Hi.

What sort of errors you did get when submitting the comment ?
I can see that coComment have been disabled on that blog now, but there are still some JavaScript errors on the page that could have caused the failure.
Dare Obasanjo: if you turn it on again, we could investigate and fix the issues.
You can contact me or our integration team to plan this: christophe _AT_ cocomment.com or integration _AT_ cocomment.com

# posted by  christophe: 07 June, 2008 00:15

 

Post a Comment

DMware: ODMA's Dark Matter

I'd originally thought of posting about "ODMA in the Cloud."  That doesn't work in the Web x.0 sense of the Internet "cloud."  It does work to think of ODMA being "out there," unseen, yet its mass -- however tenuous -- is felt.  Here's what I mean by all of that.

Into the Hidden Universe and Beyond ...

The Open Document Management API consists of three important elements:

1. A standard: the specification of an application interface and integration model that is relied on by a community
     
2. A Software Development Kit: an SDK providing header files and some samples that are intended to support programming against the API and developing services that offer the API (via the integration model)
     
3. Middleware: The ODMA Connection Manager, a software module that is installed as a bridge between applications (clients) and document-management subsystems (integrations) on the same computers

ODMA is a middleware arrangement in much the same way that ODBC and TWAIN are.

From the beginning with ODMA 1.0 in 1995, the elements of ODMA have been freely available: the API is free to use, and the middleware software is freely distributable and installable on Windows-equipped computers.  (There have been occasional mumblings about support for non-Windows platforms, but that has not happened so far.)

In this way, ODMA has been cast upon the waters.  There is no reason to know where ODMA integrations are installed, how many of them there are, and how varied they are.  It can be presumed that ODMA adoption and usage has been steadily decreasing since completion of ODMA 2.0 in 1998, yet there is regular access to the ODMA Interoperability Exchange site where all of the elements remain available.

ODMA No-see-ums

In the course of active ODMA definition work, there have been three versions of ODMA:

• ODMA 1.0, the original form
     
• ODMA 1.5, introducing some additional administrative support and a form of federated search, and
    
• ODMA 2.0, apparently over-reaching the sweet spot along with tidying-up some operability cases.

There are different specifications, ODMA Connection Manager implementations, and SDKs for the three versions.

The promise is that versions are upward compatible.  In addition, an ODMA-aware desktop application can specify the version of ODMA that it is designed for.  Configurations of ODMA are expected to decline to serve an application that depends on a version later than the level supported by the installed Connection Manager and document management system that is being accessed.

What we don't, and pretty much cannot, know is which

• versions of ODMA Connection Manager are still in use, and in what quantity
   
• versions of ODMA integration are supported by ODMA-compliant document-management systems
    
• versions of ODMA are required by ODMA-aware desktop applications and how prevalent and varied they are, even though it is clear that ODMA 1.0 is the most-commonly required support that application programs require

Although there is a registry of ODMA-aware applications and ODMA-compliant DMS integrations, contribution of this information (and avoiding of duplicate DMS IDs and application IDs) is completely voluntary.  Much of the information in the registry is out-of-date (as is much of the identified software) and there's not much to be done about it.

There is, in typical fashion, no good way to know how many implementations deviate from the specifications and how many may have "forked" the API and/or the Connection Manager software to accomplish a custom arrangement. 

The only time that potential breakdowns of implementations and implementation-quality issues surface is when someone seeks support on one of the e-mail lists provided for ODMA support.

ODMA as Interoperability Laboratory

It is surprisingly commonplace that people implement specifications such as ODMA without consulting with each other or self-styled experts such as myself.  It is clear that checking is mostly for successful operation with an important software product (typically Microsoft Word) or a given document management system (Novell Groupwise, Lotus Notes, and Documentum, among others).

There has not been, as well as I recall, any concerted interoperability testing of ODMA implementations beyond that required for a few early demonstrations at trade shows.

There are places where ODMA is known to be under-specified.  These are invitations for developers to invent an answer.  This is in addition to the ordinary risks of misinterpreting the specification and failing to confirm that interpretation (probably thought to be obviously correct).

Along with that, there are some promises made in the specifications that were claimed but not actively verified.  One is the promise that the specification is upward compatible.  For example, ODMA-aware applications developed against the ODMA 1.0 specification should be able to work perfectly well with other elements developed against the ODMA 2.0 specification.  That promise has been broken, although it is not clear whether that has been much of a hindrance, and if not, why not.

It is both surprising and somewhat discouraging that there have never been any complaints about those breakages and a few others that have come to light over the years.

There are defects in the specification, there are defects in implementations, and ODMA integrations seem to be limping along mostly without serious incident, nonetheless.  Of course, I am unlikely to be told where an ODMA integration was abandoned because it didn't work successfully with products that mattered in a particular situation.

I think that many features of the ODMA situation are typical of interoperability arrangements, how they can erode, and how they can be evolved toward a condition of reliability and stability.   On the presumption that it is valuable to do so, at least for what it provides as useful experiment, I am going to recount a number of lessons that I have already experienced.  These arose in my efforts to support software products having different programming and integration models (e.g., Java, .NET, and COM/ActiveX) than that of the native Win32 elements of ODMA. 

Looking at how ODMA interoperability is enhanced is an opportunity to see how the same kinds of considerations also apply in more complex situations where demands for strong interoperability are expected to increase, not diminish.

Cybersmith: No-friction Bits and Pieces

I'm a little distracted by James Waletzky's Tuesday, May 20 installment of Progressive Development:  Motley says: "Spend less time in OneNote and more time in Visual Studio"

In this installment, Maven makes a paen to the ways that Microsoft Office OneNote is valuable in routine capture of notes and material related to a project.  Maven also extolls use of shared OneNote files for collaborative creation and maintenance of all of those artifacts other than code that must be developed and maintained in the course of a software development.  The idea is to reduce the friction in creation and sharing of such materials among the members of a development team.

I'm a big believer in the Extreme Programming "Travel Light" maxim (and my current career situation fits that perfectly).  Although I have friends who swear by OneNote, and I do make use of it on my Tablet PC, I haven't caught the fever.

I'm concerned that the step-function for using OneNote (and the debt that accompanies yet-another siloed, proprietary document format) involves a large tax in terms of the level of Microsoft Office System commitment that must be made to support collaboration among members of a development team. 

When the Office System (and Sharepoint) pill is too large (or the project is distributed in a way where it is simply impractical or unaffordable), other, lighter-weight approaches must serve.  Project wikis come immediately to mind, as well as the use of distributed versioning for documents (to help in resolving conflicting updates and provide off-line as well as on-line working).  Some people even use their bug-tracking system this way, although I don't find that satisfying myself. 

What tools work for your (distributed) project-team collaborative-document and speedy note-taking and informal status needs?  Do you use them for in-house projects, distributed projects, or both?  How about collaborations in an open-source project?  How do you navigate the need for sharing and collaborative documents and the desire for easy, rapid note-taking, project narration, feature discussions, easy time tracking, etc.

 
Comments:

 
EverNote might be a lighter-weight solution: http://wapreview.com/blog/?p=558

I'm not keen about using a cloud service, but if I could get to my own Windows Home Server from anywhere, that would be cool.

The collaborative use is unclear.

What have you found?

# posted by  orcmid: 22 May, 2008 10:59

 

Post a Comment

VC++ Novice: Is Native C++ a Dead Language?

This week, James Waletzky posted a valuable observation about the ongoing usability of C++: Motley says "Native C++ code development is obsolete."  I recommend the entire post, the comments, and all of the other Progressive Development posts (with my cataloging here for an overview).

Here, I think is the key take-away and the main reason I am so keen to support VC++ novices:

Maven: ... I would argue that you are a better developer now because you had a C++ background. You understand what a pointer is don't you?

Motley: Don't insult me.

Maven: Do you ignore the concept of a pointer in managed code?

Motley: Absolutely not. There are times to pass objects by reference. There are times when using COM Interop that I have to worry about AddRef and Release. There are times when I do server-side development that I have to explore heap fragmentation issues (and in rare circumstances heap corruptions). Understanding a pointer is a necessity.

It's not just about pointers but storage structures, data representations, efficient economical use of resources, and encoding abstraction-manifestation techniques generally.  It's also about having the choice of a tool that is fit for the job. (and These days, one can mix tools and interoperate with libraries built from between the different program codes, when it is worth the effort and maintenance complication.  Learning to confine such complexity is part of the lesson.

It also comes down to what you want to become proficient at and how quickly, balanced by the importance of understanding the fundamentals deep enough to get out of trouble and also to avoid trouble in the first place.

For those who are concerned about Microsoft's continuing support for C++ development, the new version of MFC (the Microsoft Foundation Classes) and additional standard-library functions slated for the next version of the C++ standard have been released in a VC++ 2008 Feature Pack.  The feature pack is not available for VC++ 2008 Express Edition, although there is expected to be some future availability (although that might only be the non-MFC additions as part of VS 2008 SP1 when available).  Stay tuned.

nfoWorks: What Are those Harmony Principles, Again?

As part of readying the nfoWorks site for hoarding my hunter-gatherings for available materials in the wild, I have produced a refinement of the original attempt at some Harmony Principles.  The latest attempt will now be kept part of the "About nfoWorks" page, and an early draft (0.1 beta) is now available.

There is additional information being filled in over the next several days:

1. Harmony Principles
2. Deliverables
3. Incremental Development
4. Start-Up Activities
5. Related Work
6. References and Resources

This is a typical first draft, with many sections simply being placeholders for content yet to come. 

In arranging this material and the site, I did not have the foresight to create a blog or provide RSS feeds of the accounts being made on the site itself.  This post is my penance for that.  There is no way to make comments on nfoWorks, but you can always comment here and I will take notice.

Meanwhile, here are the basic ideas:

nfoWorks explores just how well documents can be made fully exchangeable when using a mix of different OpenDocument and Office Open XML implementations.

The first question: What prerequisites and restraints must be satisfied to ensure that documents are fully exchangeable and users can be confident that is the case?

The next question: Is there enough harmonization for users to willingly create, collaborate, and preserve their work using only only harmonious features of documents?

I offer these conditions of satisfaction for a high-level sense of what's intended:

• Users can be confident their creations honor the format standards and depend only on their harmonious features.  The Harmony Principles are honored by default.
    
• Users can be confident that documents confined to a particular profile of harmonious features can be interchanged and interoperated with via any software programs that honor the Harmony Principles for the class.
    
• In the event that a document relies on features beyond the harmonious level supported by a software product, profile-allowed limitation to supported features is explicit, automatic, and user-understandable.

Additional explanation and expanding detail are found via the About nfoWorks page.

nfoWorks: Tracking OOXML DIS 29500 into the Blue

I am not tracking every little move that happens in March 2008 as we determine whether or not the edited-per-the-BRM DIS 29500 will advance to an ISO/IEC IS 29500 and promulgation as an international standard.  I have other work to do and other things to blog about.  I shall return to my normal erratic mingling of topics.  I promise.

1. What's It All About?
2. The US Score So Far
3. "Who Are Those Guys?"
4. Yes, but WHO Are Those Guys?
   4.1 Not Voting
   4.2 Abstention
   4.3 The Loyal Opposition
   4.4 Friends Across the Aisle
5. Eagerly-Anticipated Maintenance?

1. What's It All About?

I'm posting this article because of two interesting factors:

1. OOXML Maintenance might arise at ISO/IEC JTC1 Either Way
     
   There is some interest in the US National Body for immediately creating a new JTC1 SC34 work item using an accelerated timeframe.  The new project would produce an OOXML that has the BRM-recommended changes and also resolve more deliberatively all other BRM technical comments and more.  This would be a new OOXML specification (revising IS 29500 if there is one of those).
      
   The projected work is a little different depending on whether the edited DIS 29500 is approved or not.  There's a suggestion that it could take 9 months to two years, depending on the situation and the quality of the edited DIS 29500.  I have not found the relevant JTC1 procedures to understand what these accelerated timeframe processes are.  I also have no statistics on the degree of under-estimation that happens with "accelerated timeframe" projects, although there is apparently strong oversight (section 5).
     
   I raise this here as something to keep our eye on.   We have the prospect of a moving target for a few more years.  The legacy solution may require legacy handling.
     
2. What's the US National Body?
     
   There is some confusion about who these folks are and the interests they represent.  Here's a scorecard for those playing along at home.

2. The US Score So Far

United States Votes to Approve Open XML.  Jason Matusow reports that the US National Body has concluded a letter ballot that basically affirms its original approval of DIS 29500 in the September, 2007, ISO/IEC JTC1 balloting.  This is the official result.  There will be a resolution meeting for this, but I don't think there is any expectation that the outcome will change.

As Matusow points out, the vote for approval is 11-4-1 (yes-no-abstain) with one "not yet voted" (perhaps like voting "present"?).  Either way, the 11 affirmative votes ensure a 2/3 majority.

Whatever adjustments are made, this is the US National Body Executive Board determination.

• This is different than the V1 technical committee recommendation.   This is the response to a letter ballot that was conducted following the V1 technical committee recommendation.  This is the Executive Board determination.
    
• The V1 technical committee recommended approval.  There was a lengthy conference call on Friday March 7, 2008, where the BRM outcome was discussed and the committee then voted to recommend to the Executive Board that the original approval of DIS 29500 be affirmed. 
    
• The US Delegation to the Ballot Resolution Meeting voted "no" on some resolutions there.  This was a small delegation led by  Frank Farance.  These were votes on editing of DIS 29500 and not on DIS 29500's approval or rejection at ISO/IEC JTC1.  The most famous delegation "no" vote was a blanket vote on over 800 proposed responses (and although selected line-item voting was allowed, the US did not do that).
    

3. "Who Are Those Guys?"

In the United States, the promulgation of standards is accomplished by non-governmental bodies.  There is a complex of such organizations.  Keeping track of them is further complicated by the different ways they are associated with international activities, such as ISO/IEC JTC1 and other technical committees of ISO.

The pinnacle US standards organization is ANSI, the American National Standards Institute.  ANSI accredits other organizations to develop standards.  There are over 200 of those.  Some of them, such as Underwriters Laboratory, are audited designators, but most standards developers don't certify processes or products.   My favorite, after tallying the current list, is the Hydrogen Executive Leadership Panel.  (By the way, OASIS is not one of these, nor are the W3C and IETF.  Ecma International is not a U.S. organization, of course.)

INCITS, the InterNational Committee for Information Technology Standards, "is the primary U.S. focus of standardization in the field of Information and Communications Technologies (ICT), encompassing storage, processing, transfer, display, management, organization, and retrieval of information. As such, INCITS also serves as ANSI's Technical Advisory Group (TAG) for ISO/IEC Joint Technical Committee 1."  With respect to ISO/IEC JTC1, INCITS is the US/TAG and acts as the US National Body in that capacity.  It is the INCITS Executive Board that just held the letter ballot that affirms the US approval of DIS 29500.

INCITS has a pot full of technical committees (and they may have their own subcommittees and working groups of various kinds).  Technical Committee V1 is on Office and Publishing Systems.  They are a Technical Advisory Group for ISO/IEC JTC1 SC34.  We see similar mirroring in other National Bodies.  The German DIN NIA 34 has a similar function.  V1 was once a tiny little group.  Now there are 22 members and much is being said about that.  Whatever the composition signifies, V1 has a broader charge than just dealing with DIS 29500:

"Since the scope of V1 is quite broad, it is necessary to create closer liaisons with other technical committees and special groups in order to establish good relations to avoid duplication of efforts. A number of new or extended areas are gaining interest in V1 such as Voice Messaging, Icons, Data Architecture, Font Services, MHS/X.400, Publishing Applications, Models and others related to Office and Publishing Systems."

If you wonder where INCITS came from and how it operates, here is more context:

"The InterNational Committee for Information Technology Standards (INCITS) is the forum of choice for information technology developers, producers and users for the creation and maintenance of formal de jure IT standards. INCITS is accredited by, and operates under rules approved by, the American National Standards Institute (ANSI). These rules are designed to ensure that voluntary standards are developed by the consensus of directly and materially affected interests.

"INCITS is sponsored by the Information Technology Industry Council (ITI), a trade association representing the leading U.S. providers of information technology products and services. ITI members employ more than one million people in the United States and in 2000, their revenues exceeded $668 billion worldwide.

"INCITS was founded as Accredited Standards Committee X3 in 1961. The last accreditation was April 19, 2001 under the name INCITS."

When I was last directly involved in these activities, around 1970, it was still X3 and the technical committees had designations like X3.4.2, X3J3 and X3V1 (if there had been a V1 then).  At that time, ITI was known as CBEMA, the Computers and Business Equipment Manufacturers Association.

In addition to standards development being carried out by non-governmental bodies in the United States, the US also operates under a voluntary standards regime.  For the most part, there is no mandating of standards and no one, not even participants in standards development, are obligated to adhere to a standard just because it exists. 

Of course, adherence to specific standards can be required in procurement activities, and requirement of particular certification of standards-conformance might also be required.  This is all pretty-much outside the purview of the standards developers in the voluntary model.  (Some standards are given regulatory force, incorporated in building, electrical, food-processing, and other codes, but this is not under the authority of standards developers as standards developers in the ANSI regime.)

Here's the reminder that appeared at the bottom of the just-conducted letter ballot:

"Voluntary Standards are developed with the intention and expectation that the standards will be suitable for wide application. As their use is likewise voluntary, an affirmative vote does not commit an organization or group represented on the committee to the use of the voluntary standard under consideration. If you find that you cannot vote YES and wish to vote NO or ABSTAIN, please state this and explain the reasons for your position in the places provided."

4. Yes, But WHO Are Those Guys?

In January, there were 19 members of the INCITS Executive Board, but at this time there are only 17 voting members on this question.  Here is how they turned out for the letter ballot.

4.1 Not Voting

AIM Global and Qualcomm, Inc. did not return ballots and might not (yet) be (voting) members any longer.  

Intel returned a "not yet voted" ballot, as already reported.

4.2 Abstention

The IEEE abstained.  The IEEE, in addition to being a professional association, is also an accredited standards developer. 

4.3 The Loyal Opposition

The four "No" votes are from Adobe, Farance, IBM (PDF text), and Oracle.

Of these, Farance is not a household word.  Farance, Incorporated, is a technology firm that is heavily engaged in the development of standards, with some current emphasis on metadata and learning technologies.  Frank Farance was the Head of Delegation to the DIS 29500 Ballot Resolution Meeting.  As part of the August, 2007, deliberations on a US response to the DIS 29500 ballot, Farance cast this ballot recommending conditional approval (that is, "No, with comments").

A common theme is the impossibility of conducting adequate review of a 6,000 page specification under the fast-track procedure.  IBM and Oracle both refer to "procedural irregularities" with IBM recording an extensive challenge to the validity of the INCITS process.

The Farance objection asserts that "A position of 'approval' is completely unacceptable to us" so it is a procedural appeal too, I suppose.  The objection goes on to propose a remedy after enumerating the deficiencies.  More about that below (section 5).

4.4 Friends Across the Aisle

Some of the "Yes" votes are from well-known organizations: Apple, Hewlett Packard, Lexmark International, Microsoft, and Sony Electronics.  These five are not enough to carry the day. 

The remaining votes include three substantial organizations that are mostly unfamiliar to me:

• Electronic Industries Alliance (the EIA).  This is a major industry association and also an accredited standards developer (think EIA RS-232 and RS-449).
   
• EMC, self-identified as "the world leader in information management and storage."  EMC provides solutions for mainframe, IBM DB2, Microsoft, Oracle, and SAP.  Documentum is now their product.  Oh.  I need to get out more.
    
• GS1 US, another non-profit accredited standards developer that focuses on global supply-chain solutions.  If you need a Universal Product Code to stick on your product packages, you get it from GS1 US.

The last three "yes" votes are of an entirely different breed:

• U.S. Department of Homeland Security, with an expression of alignment with NIST and DoD
   
• U.S. Department of Defense, after consultation with other Federal agencies and expressing alignment with NIST
    
• U.S. National Institute for Science and Technology (NIST).  This is a Federal agency under the U.S. Department of Commerce.  Formerly know as the National Bureau of Standards, NIST is not in charge of standardization in the United States.  NIST/ITL (the Information Technology Laboratory) is an accredited standards developer, however.  NIST has, in the past, drafted Federal Information Processing Standards (FIPS) that apply to agencies of the U.S. Federal Government.  These are often existing public standards adapted for governmental use.  There is an extensive report on NIST participation in INCITS with respect to ODF, OOXML, and the DIS 29500 process (PDF text).  There is also a NIST press release on the matter.

5. Eagerly-Anticipated Maintenance?

I'm intrigued by the following statement in the NIST ballot:

"With respect to the 'Additional INCITS/V1 Recommendations Not Related to this Vote,' included in INCITS Letter Ballot 2558, NIST interprets these recommendations to be that the USNB should support one of the following options:

"1) Should DIS 29500 fail to achieve the criteria for approval as an ISO/IEC standard, DIS 29500, as modified by the BRM, should be submitted to JTC 1/SC 34 for fast processing, via the JTC 1 combined NP [New Work Item Proposal] and CD [Committee Draft] ballots process, and progressed under the JTC 1 accelerated time frame.

"2) Should DIS 29500, as modified by the BRM, achieve the criteria for approval as an ISO/IEC standard, to correct remaining issues from the BRM, SC 34 should approve an NP for a revision of IS 29500 using the JTC 1 5-stage process under the accelerated time frame."

No "Additional INCITS/V1 Recommendations" appear as part of the ballot form.  There is something about them in the Farance ballot though:

"Although we disapprove of the DIS 29500 at its present state, Farance Inc. is supportive of the 29500 technologies becoming an ISO/IEC standard. We want the work done right and done quickly to address industry and international needs. Farance Inc. has proposed in INCITS/V1 two New Work Item Proposals [NPs] for SC34: one NP if DIS 29500 succeeds and a different NP if DIS 29500 fails. These NP proposals were acknowledged in the INCITS EB ballot wording. We hope these NPs will be a starting point to trying to fix/finish issues within the 29500 text, and we hope these immediate needs can be addressed over the next 9-14 months." 

It is not clear that NIST is throwing its support behind that idea or is simply clarifying its understanding.  I have failed to find the particular JTC1 procedures that are referred to as "the JTC1 5-stage process under the accelerated time frame."  I'm still looking.

Here's what I still think.  OOXML is the new COBOL.  Really.  That's a good thing (with a 40-year life span, for starters), if the energy and pace can be achieved with the requisite quality and care.

nfoWorks: The ISO/IEC Harmonization Opportunity

What Is in the New Draft of OOXML?  Rick Jelliffe has put up an excellent post on the history of the ODF and OOXML progressions and on the results of the Ballot Resolution Meeting in Geneva.  The entire post is a valuable summary.  With regard to the improvements of DIS 29500 (if approved by ISO/IEC JTC1), Rick's description of improvement is a valuable supplement to the offerings from Alex Brown and Jan van den Beld that I have applauded concerning BRM Closure in my just-updated "In Search of Initiative" post.

With regard to the prospects for harmonization, I found this Jelliffe tid-bit particularly interesting:

"Many other related issues were also discussed in the hallways at Geneva. For example, the German DIN standards body is preparing a cross-mapping list to match features in OOXML and ODF: there really is very little information on this currently, despite the confident assertions that ODF can/cannot handle everything that OOXML does and vice versa. The Italian standards body is seeking to work on conformance suites for testing: obviously the schemas and BNF grammars allow validation testing of instances for document conformance, so I presume the test suites will be more concerned with application conformance. ISO/IEC JTC1 SC34 has been making various preparations to establish an effective and responsive maintenance regime: ODF could also benefit from this effort."

I am intrigued by anything that happens in Italy.  (Perspective: If I mention this to Vicki, she'll say, "More trips to Tuscany!"  Around here, visiting Berlin would be wonderful, living in Italy would be heaven, and taking the bus to meet-ups in Redmond is not a consolation for her.)

More than that, I think this is what our attention should be on and I am happy to see that people are turning their interest to this matter.

Jelliffe also speaks to issues of maintenance.  The maintenance prospects are important and I want to feature these passages (ripped from context but, I trust, preserving Jelliffe's sense of it), with my emphasis:

"If the new [DIS 29500] draft is adopted as a standard, it does not remain static but can be “maintained” by the relevant ISO/IEC JC1 committee, SC34, Document Processing and Description Languages. Procedures exist for National Bodies to submit Defect Reports, which again attract the Editor’s attention and National Body voting acceptance, so the kind of process seen at the BRM becomes an ongoing effort, if there is enough interest by National Bodies." 

"The upshot is that, if DIS29500 mark II and ODF 1.2 both get accepted as standards, by the end of 2008 we should have two standards which together can thoroughly cover the field of representing current and legacy office documents, each representing one of the two dominant commercial traditions, with both under active and significantly open [PDF download] maintenance to fill in the remaining gaps and to repair pending broken parts, with clear cross-mapping to allow inter-conversion, with an increasing level of modularity so that the can share their component parts, and at least with a feasible agenda of co-evolution [PDF download] and other kinds of convergence.

"And if we play our cards well, both traditions will have significant competitive motivation to accommodate the technical requirements of their competitors. Viola, harmonization?"

"I think we did pretty well in the Australian delegation, in getting many of our issues addressed completely and most of our issues addressed in part, but (like any standard!) the more you look the more holes you see. There are so many improvements that can and should be made by pro-active maintenance."

It is the opportunity before us that I find heartening in Jelliffe's analysis.  I have the same reaction to the Patrick Durasau analyses that Jelliffe links.

Contra Durasau, Part 1.  Rob Weir has a rather different post today (promising even more in his choice of serial title).  Weir is articulate and very bright.  (I base this on the fact that he plays chess, shows knowledge of philately, and probably also writes software, all better than I do.)  He lays down a challenge for ECMA TC-45, a challenge that I think requires some pro-active behavior to remedy (and the W3C model, if not the OASIS one, comes to mind for a participation-inviting alternative):

"Where are the minutes from Ecma TC45 teleconferences? Where are the public archives of their mailing list? Where is the list of individuals participating in the TC? Where is the list of voting members? Where are the public comments they have received on OOXML? You call this open?"

If I understand Jan van den Beld on this topic, it is pretty much up to TC45 to deal with this (and put in the effort required, although there is ample computer-based support these days).

Weir has a great deal more to say, and it is a worthy read.  It bothers me that it is a worthy read, and I understand my concern better after coming across Jelliffe's appraisal.  Here's what I see:

It is easy to look at past conduct of Microsoft, including how it operates the revision cycle of its productivity and developer software, and interpret that as unequivocal evidence for no possibility of any other outcome around interoperability and pro-active support for broad-based, open-process industry standards when Microsoft is at the table.  (I don't know how the joint Microsoft-IBM work on web services survived this imperative, unless it is something like certain historical non-aggression pacts designed to cynically divide up the spoils.)

Weir's no-possibility argument is his basis for claiming that DIS 29500 should not be approved. 

For me, to act from that position of no possibility is a guarantee of no opportunity.  I stand for the possibility of broad interoperability arrangements.  There is an opportunity here, and it is up to us to seize it.  If attention drifts away and maintenance and interoperability suffer, that is a challenge for those of us who see this as worthy and important work.  Of course it feels risky.  There is always uncertainty in changing the world, even in these small ways.

I'm looking forward to the bringing into being of the world that Rick Jelliffe and Jan van den Beld see as possible.

 
Comments:

 
>It is easy to look at past conduct of Microsoft

Of course it easy to see the similarity between what is happening now and what Microsoft usually does.

How hard is it to ignore past conduct of Microsoft?

The worst possible argument is that OOXML is as best as it can get. I refuse to belive that Microsoft could not have spotted the flaws already at the drafting stage. Microsoft have very talented engineers working for them and is foolish to assume that the defects in OOXML are not intentional.

# posted by  Anonymous: 11 March, 2008 14:20

 

 
"Of course it easy to see the similarity between what is happening now and what Microsoft usually does."

One problem I have is that there is no metric on "what Microsoft usually does" as if there is an absolute, always, every-time behavior. This absolutist anecdotalism is one of the weights that we all have to suffer with now. This is no more true of Microsoft than it is of IBM, or Sun Microsystems, or the Republic of France. I find there to be no useful guidance in such indictments.

I disagree about defects. This is very hard work and it is not something that Microsoft technical staff are accustomed to doing. I have said elsewhere that the move from 2000 to 6000 pages was evidence of that, and the continuing work is more evidence. I also agree with Jelliffe that the more times people pick up a standard and look at it, the more other clarification-requiring passages will be noticed. The people best equipped to notice that for OOXML are outside of Microsoft, because the Microsoft guys don't have the beginners mind for approaching the material. Standards may benefit from multiple eyes even more than open-source code.

And thanks. I think both of your concerns deserve careful and pragmatic attention.

# posted by  orcmid: 11 March, 2008 15:29

 

 
"I disagree about defects. This is very hard work and it is not something that Microsoft technical staff are accustomed to doing. I have said elsewhere that the move from 2000 to 6000 pages was evidence of that, and the continuing work is more evidence. I also agree with Jelliffe that the more times people pick up a standard and look at it, the more other clarification-requiring passages will be noticed."

Okay...we might speculate about Micrsoft technical staff lacking the qualifications into making a working standard. On the other hand this makes what Microsoft is currently doing even more bad.

If multiple eyes indeed significantly improves the OOXML standard it is pretty much given that everyone would like as much as possible of such review. Who will gain anything from a premature OOXML standard of poor quality?

Microsoft have all opportunity to send OOXML through the normal ISO track. This would have given there expertice advise about how to make the standard good. Instead they chose to use Ecma that advertise that they aim to reduce contribution and changes to the proposal.

Arnaud Le Hors has written more about the matter in one of his blog posts
http://lehors.wordpress.com/2008/03/04/what-does-the-world-have-to-gain-from-rushing-ooxml-through-iso/

"And thanks. I think both of your concerns deserve careful and pragmatic attention."

It is always good when people exchange opinions instead of republishing spin and FUD.

# posted by  Anonymous: 12 March, 2008 03:40

 

 
I looked at the Arnaud Le Hors article and I stopped reading when he went into the rubber-stamp-Ecma tirade. You know, how it goes, I'll see your rubber-stamp-Ecma and raise you an OASIS and an ISO?

I don't want to go there.

Now, I can see lots of problems with the ISO for development of these kinds of standards. My favorite model is the IETF, as I have said, and it has an ultra-open process with regard to specifications and it has a laborious staging process by which a specification doesn't even become a *proposed* standard until there are independent, confirmed interoperable implementations. Even then, the process can be tortuous and there are sometimes doubts about how a problem is being solved through standardization. One can also get into specifications in-the-sky, something that has happened in ISO activities (and ANSI ones) but that the IETF process is designed to avoid.

Unfortunately, IETF doesn't do document-format standards of the kind we are dealing with here. So we will be seeing this come around the other way where a specification preceeds heterogeneous interoperability. That is not uncommon in ITC standards, especially programming languages and formats (look at SGML and XML, for two). Many standards are based on existing implementations and are fast-tracked (FT or PAS) to support the relevant industry (EcmaScript is an example).

Sometimes it takes some special forum to deal with the bits that standards organizations do not deal with: test suites, certification of products, agreement on profiles for interchange in various communities, etc. All of that is work that is ready to begin. OOXML and ODF are good enough for that, whatever their individual deficiencies, and this is what it will take to lead to their improvement and stabilization (not perfection). It will also provide quantitative and qualitative understanding of what we have in our hands and what it takes to work with them.

Meanwhile, I suggest that the ODF fast-track (the OASIS PAS equivalent) differed only from the OOXML Fast Track in that it lacked organized opposition (Microsoft being smart, in this case, in that anyone who thought that was a good idea was over-ruled). In this case ISO was a rubber stamp (and they sometimes are) because sometimes that is just how it goes (and you should take a look at the SQL standards if you can stand the hurt on your wallet). This is a human process, not some pristine technical one.

There's this automatic assumption that ODF is solid and OOXML is a rats-nest (and in important ways it is, largely attributable to their different origins and purposes). I say that comparison is a humbug. ODF is not solid, and we will, if the smoke is allowed to clear, now take on reconciling all of that. It is rather obvious that ODF 1.0 was rushed out the door. I don't know what the hang-up is with ODF 1.2, so we'll have to wait and see.

I believe it is ingenuous that the answer is for Microsoft to go to work with the ODF folk. I don't believe the parties are willing to do that, and it will work better when ODF and OOXML are both on the table as the same level of standards. I don't see, as a pragmatic matter, how harmonization could occur otherwise, and I share Jelliffe's optimism about the opportunity.

Whether this is the way it should have been, it is too late to do anything about it. I think there are lessons for everyone, but I am not sure that the same lessons have yet been felt in Armonk, Mountain View, and Redmond.

Whether OOXML needs to go through the normal track or not remains to be seen of course. I am not a stakeholder in this. From my personal selfish perspective, I would rather have the first ISO standardization of OOXML be done with so we can get into the realities of harmonization.

Meanwhile, there are more and more Office 2007 documents out there every day, as there are more and more OpenOffice.org documents (not pristine ODF documents) out there every day.

I think it is out of our hands now. The NBs will make their determinations, on whatever basis they do so, and the score will be re-tallied at the end of March. We'll then know what's next.

This reminds me of the words of one Bob Bemer (thought of as the grandfather of ASCII, a made-up standard): "Standards are arbitrary solutions to recurring problems."

PS: I don't want to say that the Microsoft team didn't know how to write a good specification. I think it is more about how they needed to move something that wasn't designed for interoperability to something that was, and have it be well-specified specification too. I think the learning curve and the pain was underestimated all around. I'm relieved I wasn't the one who had to do that.

I apologize for the length of this response. There are ideas that might better be placed in a new post.

I do think we are touching on valuable concerns, though some of them are not anything we will be able to influence.

# posted by  orcmid: 12 March, 2008 08:32

 

 
I appreciate your willingness to look at the different sides, but I think you are missing some important issues.

One, if this becomes a standard, in its current form, WE are stuck with it! What I mean here is that Microsoft will pour on the marketing and PR hype and make every government, institution, and corporation believe they are finally able to save their documents in a format which will give them complete freedom to use any application they want (i.e. "no more vendor lock in"). The problem is that MS spit out a format that has tons of legal issues that are supposedly only partially protected by a shaky "promise", the OSP. The document format itself has so many technical hurdles that I don't believe any application will ever have the ability to fully interpret the 6000 page specification. So this "standard" will only be for marketing purposes while MS knows that all it does is protect their product (I accept their right to protect their market, but I reject using the ISO to do it).

The other main issue that concerns me from the tone of your blog is the willingness for so many people to think MS all of a sudden is willing to work openly and create a new interoperability relationship with the computing world. I use MS daily and have since 1992, and I respect their products, but I don't think for a second they have any real desire to do any of that. If they did, they would have adopted, if not exclusively, ODF as a viable "save as" format while they developed a standard that was more feature rich for saving files with MS specific data. (They already warn you in saving to other formats that they you may lose some features, why can't they do that with an implementation of ODF filters?!)

These are just some of my thoughts. I personally believe the maintenance phase is the wrong place to correct all the issues, but that this standard should go through the normal ISO channels to work out the bugs, fix all the issues that should have been corrected a year ago, and most of all, test MS's resolve to be honest and open with this format.

Thanks, Clint

# posted by  Anonymous: 13 March, 2008 08:24

 

 
Hi Clint,

I think this is where we agree to disagree. I will keep this shorter.

1. In some sense, we are stuck with OOXML either way. I think we are overlooking something about maintenance of standard specifications though. Maintenance at the standards level doesn't have anything to do with code. What will happen is that as people actually deal with the format and the specification, and work to confirm interoperability (however that works out over time), people will submit concerns and questions and proposals for difficulties with the format and/or its specification. It does mean there needs to be an open forum for confirmation of interoperabiliity and for questions and submissions concerning the specification. It is also important to avoid astronaut document standards work and keep things grounded in reality. I believe we are close enough. The proof is in the pudding of course. Finally, on this point, there is mandatory periodic maintenance review of ISO/IEC specifications (And ANSI too. I don't know about ECMA and OASIS). Standard specifications are allowed to die.

2. I think there was a timing problem around ODF interception for Office (and I bet the ODF people knew it). I can think of lots of reasons that Microsoft did not provide native/built-in support including NIH, IP concerns, and the problem of being accused of high-jacking ODF. It seems to me that if Microsoft had an implementation in Office, that would be the reference implementation by now. You think that would have gone over very well?

3. More forward-looking, Microsoft is offering improved integration hooks so that anyone can incorporate converters that work smoothly and can be the locally-chosen default. They are going to demonstrate it with the OOXML-ODF translator project. So, however odd the governance of that project is, we will see how well your suggestion about ODF integration can be carried out.

4. Finally, I am fine with the OSP. It has as much strength as Sun's equivalent promise for ODF and it frees up open-source implementations for commercial use/sale and source-code distribution. If there are any qualms here, they are ones that apply to all open-source distributions and have nothing exclusively to do with Microsoft. But don't take my word for it. (Please don't: IANAL and this is not legal advice.) If you are in a position where this is a matter of personal concern, check with an IP lawyer. (Point them to Larry Rosen's analysis too.) We have this imaginary hammer over our heads with MSFT embossed on it. For me, that is my own geek fear of uncertainty, and a consequence of pointing at the OSP creating fear of the opposite consequence. I don't think Microsoft is who needs to be feared in this case. It's one of my odd human traits.

5. Finally, and I have gone on way too long, you're right. I do give credence to the Interoperability Principles and Microsoft realizing how important genuine interoperability is to it. I think they are learning that they are in a situation that requires this of them. This is hard to do and it is not where entropy would take them. I am willing to grant that there is a pro-active effort and I will be alert and continue to hold Microsoft to account for their execution, to the extent I, as a lone individual, have any say in the matter at all.

# posted by  orcmid: 13 March, 2008 09:29

 

 
Small update.

I talked about the prospect of Microsoft Office becoming reference implementation for ODF. That's the wrong term. There is no referenc implementation for ODF. There is a benchmark implementation (OpenOffice.org), and I assure you that if Microsoft Office had native support for ODF, it would have become the benchmark, accompanied by much wailing and appeals to the DOJ.

# posted by  orcmid: 13 March, 2008 09:38

 

 
One more thing. In my (1) above I talk about maintenance of standards. I meant to point out the limitations of the long track to standards definition. The problem with the long track is getting the right people to participate (presumably in a working group under JTC1 SC34) in the particular way that is gone about.

It is my considered opinion that an open-process public maintenance operation will do more, more quickly, than what happens when a long-track process is initiated, and it will be grounded in work at implementing an agreed baseline spec.

# posted by  orcmid: 13 March, 2008 15:09

 

 
>I looked at the Arnaud Le Hors article and I stopped reading when he went into the rubber-stamp-Ecma tirade. You know, how it goes, I'll see your rubber-stamp-Ecma and raise you an OASIS and an ISO?

I suggest that really read his full argument. How can you else know what he means to say?

As for rubber-stamp-Ecma vs Oasis...I don't agree. FT is rubber stamp while PAS is critical review even while the draft work is done outside ISO. Rob Weir has explained it quite well
http://www.robweir.com/blog/2008/02/fast-track-versus-pas.html

# posted by  Anonymous: 14 March, 2008 01:42

 

 
One of the real problems is that Microsoft have not commited to acutally implement dis29500 or the future versions of that standard so what is the value in the OSP and g dis29500 for harmonization purposes if Microsoft only maybe will implement it.

What is needed is:
*Microsoft must promise to implement the _full_ dis29500, including upcoming versions, if they should be trusted.

*Microsoft must extend the patent promise to exclude the right to sell the patents to patent trolls. As written only Microsoft itself is bound to not use the patents, and that is obviously not enough.

*Microsoft must craft a OSP so that the protection apply to the GPL and open source developers even if these are used for commercial purposes.

*Microsoft must publish all patents they have that concern dis29500. This includes the many patents that Microsoft have requested after OOXML approval process begun.

*Microsoft/Ecma should remove the nonsense requirement that syntactic compability is enough to claim conformance.

The past behavior of Microsoft is not the reason people don't trust Microsoft about OOXML...it is the current behavior that is the problem that make it given that the only sane thing is to reject dis29500.

Unless Microsoft take the above actions the following results are very likely:
*The ISO label will be used by Microsoft to fool people into using Office since it "supports" an ISO standard
*Office 2007 will never faithfully implement dis29500 so all files produced will lack interoperability with producers that don't relie on the Microsoft DLL files.
*Microsoft will sell the patents to patent trolls to attack competitors.
*Microsoft will use all application-defined points and undefined points in the standard to break real compability.

Harmonization between Office 2007 reals format and ODF would be great, but dis29500 as ISO standard does nothing to ease that. The only thing lacking for things to be sorted out is that Micrsoft start to publish their mapping between formats.

# posted by  Anonymous: 14 March, 2008 01:46

 

 
The latest comments have specific claims about how Microsoft will/does conduct itself.

Let's put a time-limit on confirmation of what actually occurs. Assuming that DIS 29500 is approved and issued as an ISO/IEC standard this year, let's check on these after years (to 2013) or when the next version of OOXML is issued as an ISO/IEC standard, or when any of these feared behaviors occur, whichever come first?

# posted by  orcmid: 14 March, 2008 08:04

 

 
... let's check on these after five years (to 2013) ...

# posted by  orcmid: 14 March, 2008 09:21

 

Post a Comment