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


"Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 01/13/2011 
11:45:41 AM:
> 
> I concur with Dennis. Suggesting that implementers may use CSD's to
> justify the use of the ODF namespaces for feature will just continue the
> current nightmare of some implementations creating files claiming to be
> ODF1.2 before such a standard has been approved. If an implementor wants
> to use a feature proposed for a new standard it really should use a
> foreign namespace. If in the end that use will match the feature as
> adopted in an ODF standard it would be easy for any implementation
> supporting the feature in ODF also to support that foreign element.
> 

I think the important thing is to have some consistency between what your 
office:version attribute is and what markup your document uses.  If 
version = "1.0" or "1.1" then you shouldn't be using any ODF-namespaced 
enhancements from ODF.

If you set version to "1.2", then I think you want to be conforming to 
some version of the ODF 1.2 draft.  It would be odd not to.  One can 
conform to a WD, or CSD or CS just as one can conform to a standard. 
Conformance is just the relation of the product to the conformance clause. 
 It would be clearer, I think, if we had a consistent way to express a 
fine grained version, such as "1.2 (CSD06)" or even eventually "1.2 
(Errata 01)". 

Remember, OASIS requires that we have conforming implementations before we 
can send a Committee Specification for ballot as an OASIS Standard.  So 
there will always be a period of time when we have implementations of 
not-yet-approved specification. 

In any case, I'd rather have this problem (vendors implementing our drafts 
early) than the opposite problem (vendors being slow to implement our 
published standards). 

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.

Regards,

-Rob



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