Blunder Dome Sighting  
privacy 
 
 
 

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.



Click for Blog Feed
Blog Feed

Recent Items
 
Republishing before Silence
 
Command Line Utilities: What Would Purr Do?
 
Retiring InfoNuovo.com
 
Confirmable Experience: What a Wideness Gains
 
Confirmable Experience: Consider the Real World
 
Cybersmith: IE 8.0 Mitigation #1: Site-wide Compat...
 
DMware: OK, What's CMIS Exactly?
 
Document Interoperability: The Web Lesson
 
Cybersmith: The IE 8.0 Disruption
 
Cybersmith: The Confirmability of Confirmable Expe...

This page is powered by Blogger. Isn't yours?
  

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
 
Millennia Antica: The Kiln Sitter's Diary
 
nfoWorks: Pursuing Harmony
 
Numbering Peano
 
Orcmid's Lair
 
Orcmid's Live Hideout
 
Prof. von Clueless in the Blunder Dome
 
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
 
DMA: The Document Management Alliance
 
DMware: Document Management Interoperability Exchange
 
Millennia Antica Pottery
 
The Miser Project
 
nfoCentrale: the Anchor Site
 
nfoWare: Information Processing Technology
 
nfoWorks: Tools for Document Interoperability
 
NuovoDoc: Design for Document System Interoperability
 
ODMA Interoperability Exchange
 
Orcmid's Lair
 
TROST: Open-System Trustworthiness

2008-03-15

 

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.

[Update: There are three different schedule templates for JTC1 New Work Item Proposals: accelerated (24 months to published standard), default (36 months), and extended (48 months) on the lines of [1: section 6.3]:

Schedule

Committee Draft (CD)

Approval Draft (DIS) Published Standard

Accelerated

none 6 months (enquiry draft) 24 months

Default

12 months 30 months 36 months

Extended

12 months 43 months 48 months

The entire section on Programme of Work is important for an understanding of the process [1: section 6].

The JTC1 5-stage procedure has 6 stages (0 to 5), [1: section 12.1]:

  1. Preliminary: A study period is underway [probably brief for OOXML]
     
  2. Proposal Stage: the NP is under consideration (requires balloting and formulation of the work, assurance of participation, and other important formalities, [could be brief for post-IS 29500, might be contentious otherwise])
      
  3. Preparatory Stage: Working Draft (WD) under consideration [probably using either IS 29500 or updated ECMA-376 as initial WD]
       
  4. Committee Stage: A Committee Draft is under consideration [something tells me there will need to be something like that either way, using normal processes]
      
  5. Approval Stage: An FDIS is under consideration [more-or-less where the Fast-Track DIS 29500 process started and where DIS 29500 is right now]
      
  6. Publication Stage: An IS is being prepared for publication [a process yet to be completed if DIS 29500 is approved]

My personal reality check suggests that the odds of this getting off on the right foot (starting work around September-October 2008) is if there is a  published IS 29500 as a concrete starting point.   Whatever process is put in place, there must be room for feedback from implementation experience and any working agreements that are formulated as part of document interoperability efforts.  Putting the necessary technical muscle into an SC34 working group and coordinating with NB counterparts (such as INCITS/V1 and others) will be daunting and time-consuming.  Some way of providing intermediate guidance and (provisional) interpretations may also be important.  I'm not betting on the accelerated timeframe even under the best of conditions.] 

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.


[1] ISO/IEC JTC1: ISO/IEC JTC 1 Directives, 5th edition, version 3.0.  JTC001-N-8557, 2007-04-05.  1696kB PDF download available for download at ISO/IEC JTC1 Public Information, Procedural Documentation.

[update 2008-03-17T19:45Z: I received a very helpful e-mail through the NIST Media Relations Office, pointing me to the relevant sections of the JTC1 directives.  The selections, summaries, and interpretation are all mine.

 update 2008-03-16T15:45Z: I learned from an Eric Lai Computerworld article that AIM Global and Qualcomm are apparently new members of the INCITS Executive Board.  I updated my observation about that and who are voting members accordingly.]

2008-03-11

 

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.

2008-03-10

 

nfoWorks: In Search of Initiative

I've been waiting to see more about the Microsoft Document Interoperability Initiative so that I can assess its value in the context of the Harmony Principles.  I'm wondering what nfoWorks might provide by way of resources, and vice versa.  The potential changes to ECMA-379 ECMA-376 that will be part of an approved ISO/IEC DIS 29500 also need keeping an eye on.  Here's the interim situation.

      1. Unfolding Document Interoperability
      2. Format Plug-and-Play
      3. Waiting for BRM Closure

1. Unfolding Document Interoperability

The first actions under the Document Interoperability Initiative were announced in a March 6 press release [1].  The release reported that day's event in Cambridge, Massachusetts, with additional events to follow around the world.  There was not much meat in the announcement.  I found the approach to be slanted in an odd way:

"The Document Interoperability Initiative focuses on bringing vendors together to promote interoperability between document format implementations through testing and refining those implementations, creation of format implementation test suites, and the creation of templates designed for optimal interoperability between different formats."

This fits with having plug-fests to test interchange and also having round tables to learn the concerns of the vendors who ask to participate.  It seems straightforward enough.  Yet I find an odd disharmony in the statement from Jean Paoli,

"“Microsoft believes that the industry has a responsibility to come together to address the interests of users in achieving greater interoperability and effective data exchange between widely deployed document format implementations.”

The notion that putting vendors together addresses user needs occurs in the statements of other participants as well.  Somehow, I thought we had reached the point where we know to engage users and representatives of significant user communities to find out what their interoperability needs are.   I guess I think I know what users want too.  Don't you?  Out of fairness, commercial firms may have a good sense of what customers are telling them.  I suspect we will see more about that as the Document Interoperability Initiative continues.  Still, I think the notion of "industry" here is too narrow.

Meanwhile, the press release led Mike Gunderloy to question the focus on commercial vendors with closed-source products [2]:

"So far, though, participation in this new initiative seems to be limited.  Perhaps Microsoft rushed to get this together to prove that they mean open business, but the only open source company involved in the first round of meetings is Novell.  Other participants (DataViz, Mark Logic, Nuance and QuickOffice) all produce closed-source products that work with one or another open format.

"If the idea here is to prove that Microsoft gets along with and wants to support the entire document-based community, they're going to have to do better than that. Until fully open-source projects such as OpenOfice and NeoOffice sit down at the table, suspicions will remain that Microsoft continues to guide the interoperability testing for their own benefit."

It is difficult to say what went into the initial selection and what the invitation process might have been.  Sometimes the most difficult part of having multiple vendors in the same room testing their wares is arriving at acceptable mutual NDA agreements.  Even if there is no need to share or discuss their code, there is information that can be taken away concerning product directions, product readiness, and also defects exposed during any lab exercises.  With regard to "fully" open-source projects, I suspect it depends on whether those projects are interested and organized to participate.  I would hope so.

The Microsoft agent-in-charge is Interoperability Evangelist Craig Kitterman, whose blog has interesting photographs and event details.  Kitterman ends his summary with an open invitation [3]:

"I want to call out here that this is open to any vendors who are implementing open standards based document formats and are interested in working with a broader set of folks with common goals. If you are interested in participating, please feel free to contact me directly (ckitter@microsoft.com) and we can work together to see how to integrate your company, product and ideas into the next session.

"If you cannot participate directly in one of the events but would like to add your comments as to what kinds of things we can and should do as a community in the interest of document interoperability, please feel free to comment or shoot me email."

We're still in vendor church, but now there's a person who stands up for the activity.  Also, there are interesting notes on the round table held during the event.

I assume that the Microsoft-Novell joint laboratory provided the setting for the Massachusetts event [4].  Craig Kitterman's blog has a slide show that provides clues.  Craig reports that the next events will be in Korea and Germany.  I can't tell whether permanent facilities are available for periodic events and plug-fests, such as Port 25 and Building 20 in Redmond.

2. Format Plug-and-Play

The press release on the Document Interoperability Initiative also invokes the Interoperability Principles as part of announcing a new drop of the open-source OpenXML-ODF Translator software.  The tie-in:

"Microsoft has committed to support future releases of the translator taking advantage of the improvements in Microsoft Office converter APIs announced as part of the interoperability principles on Feb. 21 to provide a better integrated experience for customers to open and save ODF files. These APIs and the guidance provided by the OpenXML-ODF Translator project will also make it easier for users to take advantage of other document formats, such as UOF and DAISY."

The OpenXML-ODF Translator project (well, that is what it is called) will eventually be a demonstration of the use of the new Microsoft Office interfaces for smooth integration of new formats.

[Note to self. At some point, it would be interesting to see if it ever makes sense that there be a separate conversion interface for back-and-forth with particular harmonization levels/profiles, even of OOXML format.  I have no idea at this point.]

3. Waiting for BRM Closure

At the moment, it is not possible to do anything concrete and detailed with Office Open XML harmonization until it is known what the final ISO/IEC status of DIS 29500 becomes and what the final edited specification is.

For now, the only stable specification for working with Office Open XML is ECMA-376.  There's plenty to deal with there.  At the same time, I want to anticipate how an approved ISO/IEC DIS 29500 might impose the need for some introduce adjustments (with accompanying transition provisions).  The March 29 closure of the DIS 29500 ballot process will certainly be soon enough to intercept anything that happens with nfoWorks and the Harmony Principles in the meantime.

I have obtained the information that Alan Brown has made public so far [5].  I've found useful guidance on how ZIP usage and Open Packaging Conventions (OPC) will be adjusted.  I also searched out some items that address conformance and levels of application.  There was a proposal to provide for application descriptions that may be a future opening for what I have been vaguely referring to as interchange profiles.

My attention was drawn to Alan Brown's material by hints in a post from Jan van den Beld [6].  That post appears to have been withdrawn was withdrawn and replaced by a stronger, more-complete version.  I am hopeful that Van den Beld will provide a replacement that shares his valuable perspective on the history of Fast Track submissions.


[1] Microsoft: Microsoft Launches Document Interoperability Initiative.  (press release) PressPass - Information for Journalists, microsoft.com, 2008-03-06 (updated 2008-03-10).
This release confirms that something is happening.  I was left with many unanswered questions about the actual structure of the initiative and whether the labs were definite facilities or ephemeral events (at definite facilities).
   The humor of the press release update is that an occurrence of "Microsoft Office Open XML" was replaced with "Office Open XML," reflecting the separation of OOXML from Microsoft's possession.  And while one can't rewrite Jean Paoli's predilection for unqualified use of "Open XML," it is unfortunate that this off-putting contraction is used throughout the press release.
  
[2] Mike Gunderloy: Document Interop from Microsoft.  (web log entry), OStatic, 2008-03-07.
I'm not sure ...
  
[3] Craig Kitterman: Document Interoperability Roundtables & Labs - Take 1: Cambridge, MA.  Craig Kitterman's Interoperability Community Blog, msdn.com, 2008-03-07.
The slide-show and description of the event provide the most visibility on this activity so far.
  
[4] Tom Hanrahan: Microsoft and Novell Interoperability Lab Announcement.  Blogs, Port25, technet.com, 2007-09-12.
Although focused on the server farm, Hanrahan mentions the areas of interoperability that this joint operation supports: virtualization, web-services management, and identity federation.  In the November 2006 announcement of this activity, document-format compatibility was also part of the charter.  That still seems to be the case.
   I had bet myself that this lab would end up in San Jose or maybe Idaho.  Instead, Microsoft and Novell found a more-interesting way to require comparable travel distance from Redmond and Provo.  I keep forgetting that Novell is already in Cambridge, MA.  Microsoft is expanding its own presence with a Microsoft Research operation (not to be confused with the one at the original Cambridge).
  
[5] Alex Brown: BRM DocumentsThere is no end, but addition (web log), 2008-03-06 (updated 2008-03-10).
The four downloads provide for ample reference until the post-BRM ballot closure period ends.  The original ballot comments and the ECMA TC45 proposed responses are not included.  We'll have to wait for all of that to be sorted out.
  
[6] Jan van den Beld: The BRM for DIS 29500: Open XML, a last-but-one, normal climax in FT!  Jan van den Beld (web log), 2008-03-09.  Replaced 2008-03-11 as "A new view of the BRM for DIS 29500 has emerged: Consensus prevailed."
This post has been deleted from the blog and from the blog's RSS feed.  It's conceivable that van den Beld reconsidered how much information to provide about aspects of the Ballot Resolution Meeting.  I don't know.
The value of this post to me is the great historical perspective on the ECMA-ISO relationship and how often the Fast Track (FT) process has been used with success.  I look forward to that portion being reposted in some form.  I am grateful to see that this useful and informative post has been re-issued with additional material.
   This post brought my attention to some of the resolutions that might impact the nfoWorks effort.  Fortunately, These are all available locatable in the Alex Brown materials; the original version of this post inspired me to look for them.  Now you can too.

I received my third Waggener Engstrom e-mail last week.  It pointed me to the Document Interoperability Initiative press release.  There was nothing there to talk about, with all links being to materials already covered about the Microsoft Interoperability Principles.  Later, it seemed that the OStatic folks could find some value in Craig Kitterman's more-substantial report and contact.  Since I did not want to go through the pain of registering at yet one more site in order to comment at OStatic, I chose to make the introductions here.

The ultimate trigger for this post is the BRM information from Alex Brown and the (currently-unavailable) background from Jan van den Beld.

The nfoWorks site is bootstrapping along.  The goal is to having enough structure in place that I can start compiling notes on available materials.  My first interest is identifying what is needed to build up some document-processing infrastructure with progressive layers of abstraction for processing of open-standard document formats under the Harmony Principles.  The first clue that the site is becoming something humans can use will be appearance of a genuine home page.  This will have the first links to content other than site masonry and plumbing.

[update 2008-03-11T17:14Z: I don't know how long it will take me to stop missremembering the number of ECMA-376, especially since all I have to do is look down at my computer desktop and the folder that is named for the specification it contains.  Since I needed to correct one designation at the top of this post, I added a link to the Ecma International source of the specifications and adjusted other statements in the body of this article.  I also checked Jan van den Beld's blog and am happy to report that he has put up a refined version of the deleted post that I found so valuable.]

 
Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $