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: ODF 1.2 Handling of Deprecated Features - Suggested Approach


Dennis,

Just quickly, why would this be a non-normative Appendix?

Do you envision these parts remaining as part of the main presentation 
of ODF 1.2 and then being set forth again in the appendix?

Not that it bothers me but why not simply have a separate document/part 
of deprecated features? And to answer the question I posed to you, yes, 
the deprecated parts would appear in the normative text, since that is 
where we normatively state their deprecation.

+1 to removal at 2.0, which I hope is the next version that we issue.

I rather liked Michaels suggestion that we adopt a train processing 
model so that vendors and others can estimate when new versions will 
appear and plan accordingly. I assume with a roadmap when new features 
are going to appear, etc. I understand they do something quite close to 
that in the semi-conductor industry and I assume it must work as they 
have kept it up for years.

Hope you are having a great weekend!

Patrick

Dennis E. Hamilton wrote:
> Michael,
>
> I notice in the Table-Protected proposal
> (http://wiki.oasis-open.org/office/Table-Protected) and in other
> discussions, there is discussion of deprecating certain features (sometimes
> normative bugs) of ODF 1.0/1.1.
>
> It seems valuable to create a non-normative Appendix to ODF 1.2 parts where
> there are any deprecated elements.  This Appendix could 
>
>  - identify all deprecated features (so they can be found in one place), 
>  - provide a simple rationale/explanation, 
>  - provide a suggestion for how implementations might make transition away
> from the deprecated feature
>  - indicate the earliest that the deprecated feature might be removed from
> ODF (I suggest that should be a 2.0, not a 1.x).  
>
> How's that for an approach?
>
>  - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
> Sent: Friday, December 12, 2008 22:52
> To: 'OpenDocument Mailing List'
> Cc: Michael.Brauer@Sun.COM
> Subject: RE: [office] ODF 1.2 Table-Protected Proposal
>
> Michael,
>
> I have a few observations about the current proposal at
> http://wiki.oasis-open.org/office/Table-Protected (2008-12-10 edit).
>
> I think we need to take this one on very carefully.  We certainly need more
> understanding of the impacts on current implementations and the consequences
> of any selected approach.
>
> [ ... ]
>
> B.7. A third remedy, in this situation, would be to allow either attribute
> naming (with the ODF 1.2 schema providing the choice) and to require that
> when a table:protect is seen to occur, it should be preserved and that
> newly-created table cell protection attributes should be table:protect if
> any of those have occured and table: protected otherwise.  This is a clumsy
> and incomplete approach and it does nothing for saving documents down-level
> (where apparently an implementation should do whatever it has already been
> doing).
>
> B.8 It occured to me that another action would be to deprecate the attribute
> by any spelling, allowing the style:cell-protect to do its magic.  Not that
> pleasant, I'm sure, but serves to indicate there are more alternatives to
> consider and put in the balance.
>
> [ ... ]
>
>
>   

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)



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