RE: [office] Re: ODF 1.2 Handling of Deprecated Features - Suggested Approach

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Patrick,

I believe the only meaningful statement that is normative is to say that
such-and-such is deprecated.  I would expect that to appear pretty much as
it is currently done, in the normative body of the specification.

The reason I say non-normative appendix is that it provides explanatory
information (that is, what's the rationale for deprecation) which is never
normative, nor would be suggestions to implementers about how to transition,
as far as I can tell.  I don't think there is any normative statement that
can be made, since a deprecated feature is still a feature, in my
experience.  Also, I don't think there is anything normative about a
declaration about the earliest version at which which the provision might go
from deprecated to not allowed.  It is a warning that it isn't gone yet, but
that one should migrate away from using it before the provision may
disappear.  (It is the "not before" that implementers should be able to
count on.)

The appendix is valuable for implementers and users of earlier versions of
the standard to know exactly what is deprecated (cross-referenced to the
normative place where the provision is discussed in the normative text,
usually with more attention on its replacement, if any). 

Does that help?  Maybe we should do an example?  (E.g., the table:protect
situation?)

 - Dennis

PS: It snowed in Seattle overnight and it has been a mess (although there is
not much accumulation).  Seattle is very hilly, the temperature is below
freezing, and we are generally unprepared.  Nothing like what the Northeast
experienced in the past few days, but moderately incapacitating.  -- We
couldn't get our Quest out of our garage and up the short hill of our side
street today, so I showed Vicki how to watch movies on Hulu.com and she is
having a "snow day."

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
http://lists.oasis-open.org/archives/office/200812/msg00122.html
Sent: Sunday, December 14, 2008 16:54
To: dennis.hamilton@acm.org
Cc: ODF TC List; Michael Brauer; Rob Weir
Subject: [office] 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:
http://lists.oasis-open.org/archives/office/200812/msg00121.html
> 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
[ ... ]