Rick Jelliffe had a great post earlier this week discussing the problems you get when you allow for really loose conformance. We've had discussions around this issue in Ecma for the past 9 months. On the one hand, we don't want people to feel like they have to implement the entire standard to be compliant. We want people to benefit from the work we've done, and to choose which parts of the standard they want to use. We also want people to use the standard as a launching pad for their own innovations. But as Rick points out, this can be problematic:
The ability to create extensions or subsets willy nilly is the antithesis of a standard. It is the difference between "I bought product X because it says it supports standard Y but it often fails and I am pissed" and "I bought product X because it says it has partial support for standard Y and I accept it doesn't work completely."
The way we've decided to go in terms of conformance (and you can read this in the 1.4 working draft of the spec) was to make it possible to use as much or as little of the spec as you want, but if you claim conformance to any part of the spec, you must fully conform to that part. If you don't fully conform to that part of the spec, you can still be conformant as long as you state which things you did not implement. Here is the "Goals" description from the spec:
The goal of this clause is to define conformance, and to provide interoperability guidelines in a way that fosters broad and innovative use of the Office Open XML file format, while maximizing interoperability and preserving investment in existing files and applications (§4). By meeting this goal, this Standard benefits the following audiences:
So based on those goals, and the nature of the spec, we identified the following issues:
The important thing to then get clear on is what the standard specifies. Section 2.3 of Part 1 defines this:
To address the issues listed above, this Standard constrains both syntax and semantics, but it is not intended to predefine application behavior. Therefore, it includes, among others, the following three types of information:
And then we defined document conformance; application conformance; and listed some interoperability guidelines.
It's actually interesting how much time it took for the TC to really get comfortable with this section of the spec. It's extremely important to get right though, and Rick's post reminded me of that.