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

The problem that concerns me has to do with the potential ambiguity in the use of namespaces in combination with version numbers when those are only provisional prior to the ratification of an OASIS Standard.  (I would hope they not be very provisional by the time a Candidate Standard Public Review is undertaken, since the specification has to be complete for the review, but even then there could be a reset.  Still, it seems wise to-risk manage this by how provisional features are reported out as considered stable enough to use.)

I can even see the need to deprecate or even completely remove an element name or attribute name (presumably for a new feature but who knows) in order to make a differently-named replacement in the same namespace and ODF version.  I think this matters especially if a Public Review (or even a PAS submission balloting) leads to a breaking change to what is presumably implemented. 

In the case that implementers are encouraged to support provisional features established in a CSD, they need some clean way to migrate in the case a provision is revised and there are products and documents relying on the draft form in the wild.  

I think that the TC needs to consider migration more thoroughly when an existing provision is materially modified (e.g., to be contradictory and/or down-level confusing) in a subsequent version of the OASIS Standard as well.  We might be wise to introduce a newly-named version and deprecate the previous one so that it is absolutely clear what we are doing and how implementations need to prepare for migration and/or down-level soft failure.

There could be provisional intermediate version numbers, of course (e.g., "1.2-bis1", That might be appropriate regardless, although its standing would be weird.  E.g., ODF 1.3 might have to define the provisional numbers sufficient to declaring their deprecation.  Seems a little weird.

Most of all, I think we owe it to the community of OpenDocument adopters to demonstrate care in this regard.

 - Dennis

-----Original Message-----
From: Andreas J. Guelzow [mailto:andreas.guelzow@concordia.ab.ca] 
Sent: Thursday, January 13, 2011 16:42
To: office@lists.oasis-open.org
Subject: Re: [office] Thoughts on ODF-Next

On Thu, 2011-01-13 at 10:52 -0700, robert_weir@us.ibm.com wrote:
> I wonder if the impact of the problem would be reduced if we can turn 
> around standards faster?  In other words, would it be more tolerable if a 
> vendor implements a draft 6 months before the standard is finally approved 
> compared to implementing it 2 years before approval?  I think that is 
> something we have more direct control over.

The problem I have is when a vendor implements a certain feature from a
draft and the specification is found wanting. Obviously there would be
some reluctance to change a specification in a incompatible way to that
implementation. So implementing a feature from a draft can have the
effect of cutting off any improvements to that feature.

Now if the feature were implemented using foreign elements no such
problem would exist and if the spec does not change it would be trivial
to change the element name/namespace to match the approved standard.

Andreas J. Guelzow <andreas.guelzow@concordia.ab.ca>
Concordia University College of Alberta

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:

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