Re: Deprecation of X

See below.

Le 08/04/2011 19:24, Sandro Hawke a écrit :
> 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.

Nothing in RDF can prevent anyone from using a valid URI as the name of 
a class. If rdf:Alt (resp Bag, Seq) was removed from the spec, it would 
hardly have any impact because rdf:Alt carries very little semantics. 
Tools can perfectly continue to support rdf:Alt in some way or others 
because tools can have specific treatments for specific URIs (e.g., 
foaf:knows) and still be qualified as conformant.

>
> 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.

+1

IMO, there is absolutely no problem deprecating containers and 
reification in that way.
-- 
Antoine Zimmermann
Researcher at:
Laboratoire d'InfoRmatique en Image et Systèmes d'information
Database Group
7 Avenue Jean Capelle
69621 Villeurbanne Cedex
France
Tel: +33(0)4 72 43 61 74 - Fax: +33(0)4 72 43 87 13
Lecturer at:
Institut National des Sciences Appliquées de Lyon
20 Avenue Albert Einstein
69621 Villeurbanne Cedex
France
antoine.zimmermann@insa-lyon.fr
http://zimmer.aprilfoolsreview.com/

Received on Monday, 11 April 2011 12:12:52 UTC