[odf-discuss] Microsoft's implementation of ODF 1.1
adjb at adjb.net
Mon Jan 5 12:22:25 EST 2009
A similar laxity in conformance requirements for ISO/IEC 29500 (OOXML)
was somewhat addressed by the introduction of the notion of "application
descriptions" at that standard's BRM (this was a joint UK-Portugal
initiative; the world's oldest treaty lives on ...).
By this mechanism "application descriptions" may be defined which
enumerate the features an application must support. The idea is that
such desciptions might be used when procuring systems. By default, two
such descriptions are provided for 29500, "base" and "full" (in which
"an application conforming to this description has a semantic
understanding of every feature").
Such a feature might usefully be added to ODF. In fact probably _should_
Personally, I believe an application description might also be defined
for OOXML and ODF which prohibits the use of XML elements/atributes that
are not explictly defined within the schemas. This would prohibit ad hoc
extensions to the format in anything other than an explicit way.
As it is, you are correct - the application conformance bar for ODF (all
flavours) is not set high, in fact it is resting on the ground.
> Jesper Lund Stocholm asks Microsoft's Doug Mahugh a right-on-the-mark question:
>> The list of elements and attributes "not supported
>> in core Word/Excel/PowerPoint 2007" is quite long.
>> Can you tell us what will happen, when Office 2007
>> encouters an unsupported element.
>> Will it simply be ignored?
>> When roundtripping - will it be deleted or preserved?
> Peter Amstein answers for Doug Mahugh:
>> On load, Office 2007 SP2 will simply ignore the
>> unsupported elements and attributes in ODF files.
>> We do not attempt to round trip unsupported elements
>> and attributes, they will be removed from the ODF
>> file if you resave it using Office 2007 SP2. This is
>> consistent with our implementation principles and our
>> desire to provide predictable behavior. We
>> considered trying to roundtrip elements and attributes
>> that we do not understand or support, but we found if
>> we did this that we could not be sure the resulting files
>> were internally consistent and conformant ODF files.
>> As an aside, there are some cases where we write
>> elements or attributes on save that we do not support
>> on load, for the sake of better interoperability with
>> other applications that use ODF. Those cases are
>> described in the implementer notes as well.
> Cf., ODF v. 1.1 section 1.5 states in relevant part:
>> "Conforming applications *either* shall read documents
>> that are valid against the OpenDocument schema if
>> all foreign elements and attributes are removed
>> before validation takes place, or shall write documents
>> that are valid against the OpenDocument schema if all
>> foreign elements and attributes are removed before
>> validation takes place.
>> "There are no rules regarding the elements and
>> attributes that actually have to be supported by
>> conforming applications, except that applications
>> should not use foreign elements and attributes for
>> features defined in the OpenDocument schema."
> One moral of the story: If you sign a check in blank and leave it
> lying on the street, someone is apt to pick it up and fill in an
> amount that will cause you some discomfort. Standards are no
> Also, in my opinion nothing in the latest draft of the conformance
> section for ODF v. 1.2. blocks Microsoft from doing the same with ODF
> v. 1.2. <http://www.oasis-open.org/committees/download.php/30360/conformance-definition-proposal-v6.odt>.
> Best regards,
More information about the odf-discuss