Re: Deprecation of X

On Fri, 2011-04-08 at 19:06 +0200, Dan Brickley wrote:
> On 8 April 2011 18:55, Sandro Hawke <sandro@w3.org> wrote:
> > On Fri, 2011-04-08 at 13:27 +0100, Richard Cyganiak wrote:
> >> On 8 Apr 2011, at 12:38, Nathan wrote:
> >> > Rather than strictly deprecating certain features, can we modularize them in to another "extensions" specification, or working note, perhaps together with steps publishers / consumers can take to factor them out?
> >> >
> >> > Else, are we versioning "RDF" such that people can tell, oh this is RDF 1 which supports x,y,z and this is RDF 1.x which does not?
> >>
> >> At the Stanford workshop there was a lot of talk about “weak deprecation”, meaning something like: Conforming implementations MUST still support it, but newly created data SHOULD NOT use it. There is no intention of removing the feature entirely in a future version of the spec.
> >>
> >> Going much further than that probably is not desirable, nor really possible given the constraints set by the charter.
> >
> > When I was writing up these issues, I started to use the term "weakly
> > deprecate", then I stopped and looked up the word "deprecate":
> >
> >        In computer software or authoring programs standards and
> >        documentation, the term deprecation is applied to software
> >        features that are superseded and should be avoided. Although
> >        deprecated features remain in the current version, their use may
> >        raise warning messages recommending alternative practices, and
> >        deprecation may indicate that the feature will be removed in the
> >        future. Features are deprecated—rather than being removed—in
> >        order to provide backward compatibility and give programmers who
> >        have used the feature time to bring their code into compliance
> >        with the new standard.
> >
> >        -- http://en.wikipedia.org/wiki/Deprecation
> >
> > Isn't this exactly what we mean?   We could deprecate rdf:Seq but say we
> > wont remove it for at least 99 more years.
> >
> > For some reason, though, everyone seems to think "deprecate" means
> > "remove".   So maybe we do have to make up some new word.   I'd rather
> > just be clear about them being "deprecated-not-removed".
> 
> So that makes sense for software, and software-related features such
> as "does an RDF/XML parser need to do anything special for reification
> or rdf:Seq vocabs?".
> 
> For *data* (and data should outlive software by years), I find this
> uncomfortable. Properties and classes generally just mean whatever
> they mean. Their use in various patterns passes in and out of fashion,
> but I don't find it quite comparable to software. Documents generally
> aren't maintained the same way...

I can't see the distinction you're making.   

If rdf:Alt is deprecated, it means we suggest you not use it in data you
produce, but of course all software must still support it.  If rdf:Alt
is removed, then software will no longer support it, so you really can't
use it in your data.

I think your argument that data is not maintained suggests we should
probably say that features will NEVER be removed, just deprecated.

But given that most of us misunderstood what deprecated meant in this
context (including myself), I can live with 'archaic' or something else.

In practice, there may be an issue with software cutting corners on
features they know are deprecated/archaic; I think our best option is to
just be clear -- to say we suggest Feature X no longer be used in new
systems, but note that Big Product A and Popular Product B do use it, so
it's important that software still support it.

     -- Sandro

Received on Friday, 8 April 2011 17:24:48 UTC