[odf-discuss] OOXML: The next step

[robert_weir at us.ibm.com]

Well,  the ODF standard will not contain any proprietary extensions.  It 
never has.  This by definition -- anything that the ODF standard defines 
is a standard, not proprietary.

The question IDABC brings up is what an application does, not what a 
standard allows.  Standards, as currently practiced, specify technical 
requirements.  They don't specify licensing or permitted uses or 
compliance testing or patents, etc. 

I see a standard as providing a shared vocabulary for buyers and sellers 
to express their requirements.  Some users, like IDABC will seek 
applications that do not extend ODF.  ODF should provide a way of 
expressing the technical side of that requirement.  Other users will have 
stricter requirements.  Maybe archivists want to express the requirement 
that all fonts be embedded and that no object embedding (OLE) is used, and 
no macros or script is used.  So, something similar to PDF/A.  If so, ODF 
should provide a conformance class to express that technical requirement. 
And so on.  We can do these in the standard itself, or as separate 
profiles.  But I don't think we can express a prohibition against 
proprietary extensions as a technical requirement.

That's my observation at least, based on what I've seen.  But who 
knows.... If ISO C++ could require that implementations document their 
extensions, why can't it require that they provide GPL'ed source code as 
well?  There are all sorts of ways you can push the envelope here.  The 
art is finding a way that will gain acceptance.

Regards,

-Rob

odf-discuss-bounces at opendocumentfellowship.com wrote on 04/08/2008 
11:59:37 AM:

> [response bottom-quoted]

> On Tue, Apr 8, 2008 at 6:12 AM, <robert_weir at us.ibm.com> wrote:
> 
> My concern was with undocumented extensions and undocumented 
> "implementation-defined" behaviors.  My solution was to define 
> conformance in the ODF standard such that a conformant application 
> must be accompanied with definitions of their implementation-defined
> features, as well as definition of their extensions.  Governments, 
> etc., would then require or prefer applications which conform fully 
> to the ODF standard. 
> 
> One difference is that my proposal would be part of the standard, in
> the conformance clause, while yours would be a separate program. 
> 
> Other difference is in the treatment of patent-encumbered 
> extensions.  Your proposal would forbid them.  My proposal would 
> allow them, if they were documented. 

> 
> Hi, Rob, 
> 
> Would you please discuss your proposal in the context of the market 
> requirements identified at the IDABC Open Document  Exchange Formats
> Workshop 2007 that are in bold face below? I am interested in 
> learning whether and/or how ODF v. 1.2 will fulfill these market 
> requirements in light of your proposal and comments in this thread. 
> 
> Results of Workshop 3 - The current ODEF standardisation efforts: 
> Expectations towards industry players
>  <http://ec.europa.eu/idabc/servlets/Doc?id=27865>:

> »main results

> »5 main requirements
> »Openess (sic)
> »ODF as the common denominator
> »No Supersets
> »No Patents
> »ComplianceTesting
> 
> ODEF Workshop Conclusions (Karel De Vriendt ? IDABC, DG Informatics,
> European Commission) <http://ec.europa.eu/idabc/servlets/Doc?id=27875>. 

> No incomplete implementations (able to open all documents conforming
> to the standard), no proprietary extensions;
> 
> Open Document Exchange Formats: Report to the plenary session (Dr. 
> Barbara Held ? IDABC, DG Informatics, European Commission) <http://
> ec.europa.eu/idabc/servlets/Doc?id=27956>
> 
> No incomplete implementations, no proprietary extensions;
> 
> Best regards,
> 
> Paul
> _______________________________________________
> odf-discuss mailing list
> odf-discuss at opendocumentfellowship.com
> http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20080408/69ebf091/attachment.htm