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] Thoughts on ODF-Next


Michael, thank you for your thoughts on the future process for further
development of the feature set of the OASIS ODF Standard.  I have one
objection.

First, have a happy holiday season with the joyful satisfaction of knowing
that the CD06 Public Review has actually commenced.

In short: I object to any introduction of speculative features by premature
appropriation of the ODF x.y schemas and namespaces without any version
control and without the full application of the standards-development
process.  

 - Dennis

More thoughts:

To suggest to implementers that a CSD that has never seen Public Review is
safe to implement strikes me as ridiculous.  It also creates a distorted
preferential access to the ODF x.y schemas and namespaces that seems
incompatible with any claim to an open-standards process.  

The potential for a versioning disaster in the schemas and namespaces seems
to be an unnecessary risk.  I also think that it subverts what it means to
be "standard" in the open-standards sense as well as the senses used by
Standards Development Organizations that have independent interoperable
implementation as a focus.  I also think that it can lead to unfortunate
baggage because of the inertial affect (and justification) that the CSD has
been implemented, whatever its quality is finally judged to be.  I don't see
how any governmental agency, for example, would write procurement
specifications that named or even tolerated CSD-defined speculative
features.  Certainly no other specification can make normative use of them.

There is an advantage to new features being worked out cooperatively among
implementers as mutually-agreed foreign extensions, extensions that are
handled appropriately in implementations that are unaware of them.  This
does not require ratification in the ODF 1.x namespace(s) and schema(s).
There is advantage to having them on their own "tracks."  With luck, the
results will be sufficiently well-specified and sufficiently desirable that
incorporation into ODF x.y is not difficult.  If the feature model is not
carried over wholesale, the form incorporated in the ODF x.y schemas and
namespaces will be differentiated and the implementations of the extension
can be adjusted in some way (and ideally there is harmonization or we aren't
talking about the same feature modeling at all).

I suggest that something to work on first, perhaps in OIC too, is the
identification of practices for extensions on the ODF 1.2 base that are safe
in the face of eventual incorporation into ODF x.y (and not) and guidance in
how implementations can consistently treat extensions as unrecognized
foreign features so there is a good level of predictability and stability,
even in the presence of extensions (recognized or not).  This is not unlike
guidance for implementations that selectively implement a subset of the
already-standard features too and we could all use consistency in that
regard.


-----Original Message-----
From: Michael Brauer [mailto:michael.brauer@oracle.com] 
Sent: Friday, December 17, 2010 05:03
To: OpenDocument Mailing List
Subject: [office] Thoughts on ODF-Next

[ ... ]

Where are a lot of advantages this model has compared to the one we used
for ODF 1.2:

- Enhancements and new features are available on CSD level in less than
6 months.
- Vendors may implement CSDs instead of extended conforming documents 
with vendor specific extensions. This
-- provides a higher level of interoperability between ODF
implementations that go beyond the last approved OASIS standard
-- provides transparency to users
[ ... ]

Best regards, and best wishes for the holiday season.

Michael

[ ... ] 



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