Re: [office-comment] Foreign elements and attributes

[robert_weir@us.ibm.com]

Jesper Lund Stocholm <4a4553504552@gmail.com> wrote on 02/25/2009 01:45:49 
AM:

> 
> 2009/2/8  <robert_weir@us.ibm.com>:
> 
> > That's why I favor removing it from the ODF core.  Having it there 
just
> > makes work for implementations to write code to handle it "just in 
case",
> > even though no one currently uses the feature.
> 
> The more I think of the idea of multiple conformance clauses the more
> I actually like it. However, a few details are not clear to me yet, so
> please endulge me to broaden my view:
> 
> What would be the purpose of having multiple conformance clauses -
> apart from complying with OASIS rules? Is it for procurement concerns?
> Is it to enable organisations to aquire either "ODF Core compliant
> applications" or "ODF Extended compliant applications"?
> 

Just to be clear, there is no OASIS requirement for multiple conformance 
classes.  The only OASIS requirement is that we have a section in the 
standard that explicitly gives a numbered list of conformance 
requirements. 

A good background read is the W3C Note "Variability in Specification"  
http://www.w3.org/TR/spec-variability/

It goes into the uses of different conformance products, classes, 
profiles, modules, etc.

Ideally we would have a single specification that everyone would implement 
100% and which 100% of users would accept.  However, this is often 
difficult to achieve.  So classes, profiles, modules, etc., allow us to 
negotiate formal structured definitions of variability in the standard. 

> Also, will an application be able to recognize a core document vs an
> extended document (apart from detecting foreign content)? Will there
> be a flag to indicate compliance level?
> 

We have not discussed this, but it sounds reasonable. 

> As a principle, I like the idea of stripping out what is not needed or
> "pure" (after all, that was kind of the idea of making
> strict/transitional editions of OOXML during processing in ISO). But I
> think it is important to think about what vendors will do if the two
> clauses are kept. Chances are that they will flash "ODF Core
> compliant" even though they are only this in theory since their
> default behaviour is the extended edition. This is actually much the
> same way OOo claims "Compatible with Microsoft Office" when in theory
> it is compatible, but it is not when using the default file format.

I think this is coming more from user requirements rather than from any 
vendor demanding a conformance class for unextended documents.  I wouldn't 
underestimate the power of user requirements.  If users can convince a 
vendor to support ODF, then they can convince a vendor to support a 
specific conformance class of ODF. 

But I think that we would end up with most word processors being able to 
read and write both conformance classes, but some having a setting to 
output the core conformance class.  This is similar to the relation 
between PDF and PDF/A.


> This is about the same mess we have with OOXML and strict/transitional
> and Microsoft Office. Office 14 will likely support both strict and
> transitional OOXML, but since backwards compliance is important to
> Microsoft, default behaviour will propably be "transitional".
> 

It is a little bit different.  Strict/transitional was about legacy 
features, things that could be defined in detail, but would not be needed 
for a new word processor when writing a new document.  The two ODF 
conformance classes are making a different distinction.


> And finally: a lot of the discussions on the web about this has
> circled about documents not being conformant when being extended (and
> I realize that I might have contributed to this). As far as I
> understand it this is not true. Documents with extensions will indeed
> be conformant - but to the "OpenDocument extended document" and not to
> the core "OpenDocument conformance".
> 

Correct.  I've also read some posts that seem to confuse it further 
suggesting that conformance retroactively changes for ODF 1.0 and ODF 1.1 
documents.  This is not true.  We're only talking about ODF 1.2 documents.

> And a personal fear: Focusing on shrinking ODF to "ODF Core" risks
> making it increasingly difficult to claim that ODF is a "full fledged
> alternative to .DOC and OOXML". I think that would be a wrong path the
> go. ODF /must/ remain a viable alternative to .DOC and OOXML.
> 

If we need to add incremental functionality to ODF, then we should define 
the specific requirement, discuss the use cases, design a schema to match 
it and add that to the standard.  That is how standardization works. 
Having vendors add functionality via uncoordinated, non-interoperable 
extensions doesn't improve the standard. It doesn't improve ODF.  If 
Vendor X adds support for feature Z via extensions, then we can't say that 
ODF supports Z.  We can only say that Vendor X extended ODF to add Z.  I'm 
not saying that is bad, but it is a distinctly different use of ODF, and 
it is reasonable to put that into its own conformance class.

-Rob


> Jesper Lund Stocholm
> www.idippedut.dk
> SC34/WG4 http://www.itscj.ipsj.or.jp/sc34/wg4/
> 
> --