Open XML Resources for Developers

re: Open XML Resources for Developers

dfarning — Tue, 01 Apr 2008 04:00:16 GMT

"Doug has a great post today that helps get us back to what really matters in this whole file format discussion (at least if you're a developer)."

If only it were that simple. This might come as a surprise to you, but there are a number of developers who work on platforms other then Windows.

The ratification by the ISO of a standard which we will not be able to implement is of great concern to us.

Brian, here is a challenge to you personally. Microsoft has been publicly making many promises about the new 'era of interoperability'. Will you personally vouch that a 100% compliant reference implementation of the ISO ratified version of OOXML will be created by Microsoft?

Will you personally vouch that third party developers will not be hampered by patents as they implement OOXML?

Dave

re: Open XML Resources for Developers

Ari Pernick — Tue, 01 Apr 2008 04:33:57 GMT

dfarning: What part of the OSP (http://www.microsoft.com/interop/osp/default.mspx) is insufficient?

re: Open XML Resources for Developers

bill — Tue, 01 Apr 2008 04:59:21 GMT

Yes, Brian, do you cross your heart and hope to die?

re: Open XML Resources for Developers

Chris Rust — Tue, 01 Apr 2008 05:05:37 GMT

The tools and support for Open XML already out there are great and have really assisted us in our product development. We added support for Open XML to our product 6 months ago with the expectation that it will become an ISO standard. We wait with bated breath!

Developers want compliance confidence

scotch — Tue, 01 Apr 2008 06:56:28 GMT

How is compliance with IS 29500 to be tested?

Supposing I'm an agency, working with products from two third-party vendors, both who claim that their products are standards-compliant, but where I find that I have interoperability problems when documents are exchanged.

The problem is probably due to a bug somewhere, either in my workflow, and/or in one or more vendors' products. As a manager, I need to be able to measure and control risks, and manage resources and commitments such as deadlines, in-house staff and equipment resources, and interaction with the vendors, perhaps under support contracts.

In order to manage these resources and risks, I need to be able to isolate the problem, so that I can assign responsibility to suppliers as appropriate. In some cases, the situation might be sufficiently serious that litigation is warranted.

Given a choice between OOXML (ISO 29500) and ODF (ISO 26300), I believe that, at present, 29500's greater complexity, its use of non-standard technologies and its somewhat unclear language in places makes it too risky to be a viable choice at present. There seems to be consideration of a maintenance phase to look at some of these items.

The way to improve this situation is to rework the specification to reduce the risky components, and/or to use tools to evaluate in detail the complex areas.

I'm reminded of the situation of risks associated with operating system vulnerabilities. People can use tools such as virus scanners and firewalls to help locate and close off problem areas. It has taken five to ten years for the risks to be understood and for the tools to evolve to manage the problem.

So, the maintenance of the new standard is very important in tracking the evolution of these risks. I understand that SC34 will be in charge of the maintenance; I am interested in knowing what items are expected to be addressed, and in what timeframe.

What products and services are available to help me manage these risks? Doug Mahugh points out "Package Explorer", and says that it can help when validating the contents of documents. I notice that the license for this Shared Source-Permissive License product expressly disclaims warranties and guarantees, and places the entire burden of risk onto the user. (With the usual local-consumer-rights caveats.)

Are there other validation tools available, or known to be in production?

-scotch

re: Open XML Resources for Developers

hAl — Tue, 01 Apr 2008 09:17:42 GMT

@Dave, you want a 100% compliant implementation.

As a reference for what you exactly mean with that, could you answer this question ?

How much of a percentage would you define OpenOffice is a fully compliant reference implementation of ODF ?

re: Open XML Resources for Developers

Rob Brown — Tue, 01 Apr 2008 14:21:31 GMT

Hi Brian,

Well, the results are in - http://lists.opendocsociety.org/pipermail/members.announce/2008-April/000002.html - so you can stop being cagey about it now. As I said before, congratulations!

Is it true that you and your blogging brethren have been quiet for the last few days, not due to "respect for the standards process", but simply because of inebriation? ;-)

re: Open XML Resources for Developers

hAl — Tue, 01 Apr 2008 14:55:02 GMT

Here a PDF with the (official) result on it as posted on a dutch ICT newssite:

http://webwereld.nl/attachments/free/OXML_uitslag.pdf

re: Open XML Resources for Developers

dave — Wed, 02 Apr 2008 02:19:10 GMT

Well done on turning the question of how to test for compliance back to me. But that is exactly my question. How do we verify that our product are compliant? If Microsoft can't create figure out how to verify compliance to their standard.

I would hate to think that OOXML is intentional being set up as a moving target to prevent the unwashed from implementing.

If you can sense my distrust, you are right. I was once part of a company that went from Microsoft partner to competitor overnight.

As they say in Texas; Fool me once, shame on you. Fool me twice, shame on me.

re: Open XML Resources for Developers

BrianJones — Wed, 02 Apr 2008 02:36:37 GMT

There's an old saying in Tennessee, I know it's in Texas, it's probably in Tennessee. It says:

"Fool me once... shame on... shame on you... ... ... Fool me - I can't get fooled again"

Dave,

I think there will clearly be work to do now around tools; test suites; example documents; etc.

That's all super important, especially with a spec with this level of breadth.

-Brian