OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Our Position on the Conformance Proposal

Stephen Peront <stepper@microsoft.com> wrote on 02/26/2009 10:46:22 AM:
> Hello Michael/Rob and TC Members/Observers...
> Several TC members have asked us to clarify our vote against the 
> most recent committee draft (CD).  Let me note at the outset that 
> the sole reason for our "no" vote was the conformance proposal that 
> had not yet been voted on within the TC.  I will therefore describe 
> our general view of conformance, explain our disagreement with the 
> current proposal, and recommend an alternative approach. 
> Conformance Principles.  We believe the following principles should 
> guide document format standards activities in general, and ODF 
> activities in particular:
> - Conformance should be defined in terms of the minimum 
> requirements; it should not be used to establish an "upper limit" 
> for implementations.

Then let's define ODF has being a sequence of 1's and 0's in a binary 
file. Remember, even a requirement that ODF must be well-formed XML is 
setting an "upper limit" for what a file may contain. 

So I don't think there is a question on whether there should be an upper 
limit or not. Specifying constraints is the nature of standardization. The 
question is where we draw the lines.

> - Extensibility mechanisms are useful for all file formats. 
> Extensibility is central to XML, of course, and it's useful in the 
> context of a file format for all of the same reasons that it's 
> useful in other XML applications and vocabularies.

Exactly.  That is why the "extended" conformance class allows extensions.

> - The ability to add custom semantics to documents, and in 
> particular custom semantics that are not broadly applicable (and are
> therefore unlikely to ever be formalized as an international 
> standard), is critical to many document users.  This is especially 
> true for organizations that are automating large-scale workflows and
> business processes.  Such capabilities should be as simple and 
> straightforward as possible for implementers because they are 
> typically used in rapidly changing competitive environments where 
> needless complexity would slow the pace of innovation.  It should 
> also be possible to validate document content against the standard 
> without a need to understand the custom semantics that may be used 
> in the document.  We believe these types of extension points are a 
> "must-have" feature for modern XML-based document formats because 
> they enforce a standardized approach to custom semantics.

I agree 100%.  That is why we have an "extended" conformance class for 
exactly that kind of use.  I think the only controversy is that you seem 
to be suggesting that you cannot meet your use case unless you are at the 
same time able to deny others the ability to meet their use cases.  Is 
there anything about having multiple conformance clauses that prevents 
your use cases from working?  If so, please point out the difficulty.  If 
not, then why do we have a problem?

> - We have found many interoperability problems between existing ODF 
> implementations in our testing, and for the most part these have not
> been caused by the use of foreign elements.  Rather, the problems 
> we've found are caused by other issues such as variation in 
> interpretation of the standard, unsupported features in some 
> implementations, product bugs, and other undocumented details of 
> various implementations.  If the goal is to improve real-world 
> interoperability, we feel implementers can make a big difference by 
> documenting these sorts of details, and the removal of foreign 
> element support from ODF won't do anything to address the vast 
> majority of interoperability problems we've encountered.

This may be true, but this does not eliminate the value of having a 
conformance class that denotes an unextended ODF document.  In fact, I 
fail to see why you can't just be happy that your use cases are satisfied 
by the "extended" conformance class?  Why do we also need to deny others 
the ability to have a conformance class to suit their needs?

> The Current Proposal.  Looking now at the specific conformance 
> clause that appears in the latest CD, the aspect of it that we find 
> most problematic is the distinction between "Conforming OpenDocument
> Documents" and "Conforming OpenDocument Extended" documents.  This 
> distinction implies that it is not possible to allow for standards-
> based extensibility, which is not true.  ODF has historically 
> allowed standards-based extensibility (through use of language 
> similar to the current proposal's "extended" class), and so does 
> IS29500 (through the semantics of the customXml element, as well as 
> the Markup Compatibility and Extensibility mechanisms defined in 
> Part 3 of IS29500).

I read no such implication that there is no standards-based extensibility 
in ODF.  In fact the "extended" conformance clause quite explicitly 
defines a specific extensibility mechanism which is allowed in those 
documents.  How do you read it otherwise?

> The distinction between "conforming" and "extended" documents would 
> also create unrealistic expectations because of the misleading 
> implication that "conforming" documents are more interoperable than 
> "extended" documents.  As I mentioned above, the vast majority of 
> real-world ODF interoperability problems we've seen have nothing to 
> do with this distinction.

Where does the draft say anything about interoperability and extensions?

> Next Steps.  There are two possible solutions that would address 
> 1) Eliminate the "conforming" class altogether, and use the existing
> definition of the "extended" class (for producers and documents) as 
> the one and only conformance class/level.  This would mean that 
> implementers would continue to have the same extensibility options 
> that they have  had in prior versions of ODF.

This proposal was already considered. We also considered the exact 
opposite, having only a single conformance class, which did not allow any 
extensions at all.  Their was consensus for neither proposal.  The present 
proposal is a compromise that gives two conformance clauses, one for each 
use.  This compromise had greater support than either of the single 
conformance class proposals.

I have a feeling that if we did reopen discussion on this topic, we'd be 
more likely to end up with a single conformance class that disallowed 
extensions altogether than a single conformance class that allowed 
extensions.   To me it appears that allowing an "extended" conformance 
class was a gracious concession.  "Live and let live".  Your ability to 
have an "extended" conformance class does not interfere with someone 
else's desire to have an unextended conformance class, and vice versa. If 
you upset that compromise, and go for an absolutist "my way or the 
highway" approach, the results might be even less acceptable to you. 
That's my personal observation.

> 2) Add some other extensibility mechanism, such as those used in 
> IS29500, which would allow for standards-based validation of 
> document content that may contain custom semantics from non-
> standardized namespaces.  This would require some engineering work 
> within the TC, and for that reason we are slightly inclined toward 
> option #1 above, but we would be glad to contribute to this work if 
> the TC would like to explore other extensibility mechanisms.

I'd certainly consider something like this for the "extended" conformance 
class.  As I've stated before I think the naive extension mechanism 
defined in the "extended" conformance class gives insufficient guidance to 
producer/consumer parties on how to coordinate issues of versioning, 
fall-backs, editing semantics, etc.  I have looked at OOXML's Part 5 and 
it addresses some, but not all of these issues.  With work it could 
probably be turned into something useful for us. 

But I don't think this eliminates the desire for an unextended conformance 
class for ODF.

> One question that has arisen in our discussions to date is "why not 
> use RDF for custom semantics in documents?"  Although it is 
> theoretically possible to use RDF for document semantics, there is a
> great deal more complexity in that approach than in the simple 
> straightforward use of foreign elements (as in ODF 1.1) or customXml
> tagging (as in IS29500).  This complexity grows rapidly if there are
> nested structures, which are typical in these scenarios.  If we are 
> going to require implementers to re-design their extension points, 
> we feel the TC should work to provide a more straightforward mechanism.

In the current draft this is moot, since arbitrary XML extensions 
("foreign elements") are indeed allowed, in the "extended" conformance 
class.  So you use the tool that is most appropriate for your task.  None 
of this is contradicted by having two conformance classes.

> A final point I'd like to reiterate is that our implementation of 
> ODF 1.1 in Office 2007 SP2 does not use foreign elements at all.  We
> have not extended the spec in any way.  Others have extended the ODF
> spec, however, including many smaller implementers who have at most 
> one vote in this process, and in some cases no votes.  We believe it
> is inappropriate to force all implementers of ODF to submit every 
> potential extension to the TC for consideration in a future version 
> of ODF.  Consider, for example, an implementer who had an idea for 
> an extension in 2006 - they would still be waiting today, in 2009, 
> for the next version of the spec which might contain that extension.
> And worse yet, there is little chance that a small implementer could
> get any extension into a future version of ODF without support from 
> the larger implementers, as a simple analysis of last week's voting 
> on the CD would show.

No one is forcing anyone to submit anything to the ODF TC. Implementations 
will be able to continue to make arbitrary extensions to ODF, according to 
the "extended" conformance class.  Capabilities have not changed.  All we 
are doing is labeling the two cases more precisely, so those who wish to 
distinguish extended from unextended ODF documents may do so in a formal 
way.  Anyone's ability to extend ODF is in no way diminished by this.

> I hope this helps clarify our voting on the CD last week.  Please 
> let me know if you have any questions, and I look forward to working
> with the TC on finishing up ODF 1.2.

Thank you, Stephen.  I look forward as well.


> Rgds,
> -Stephen
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]