Re: Deprecation of X

On 8 April 2011 19:24, Sandro Hawke <sandro@w3.org> wrote:
> 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.

Apologies, I had to leave the house thirty seconds before I started
writing that paragraph, so it ended a little abruptly.

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

Well RDF is somewhat special data in that regard. Data that contains
'http://purl.org/dc/1.0/Contributor' might be unfashionable, since it
spells the property name with an uppercase C and uses even 1.0 rather
than 1.1 version of the old DC namespace, and not the more recently
favoured /terms/ version. But having 'software to process it' isn't
quite the same thing as 'software to process [some custom file
format]'. Anyone anytime can compose a SPARQL query, or a Gremlin path
expression, or an N3 rule, ... or whatever that matches that property.
The main consideration is 'who else is using it?" rather than 'can I
download software for it'. If there is a lot of rdf:Alt data out
there, used in some idiomatic way, that gives it some continued
momentum even if most consumption is done by mapping and translation
and filtering rather than custom support.

But the main point I want to make was simpler.

We're designing data structures that is supposed to last years,
ideally decades, and still have a natural, logical reading as making
simple statements about the world.  In the context of this general
approach, the word 'deprecate' casts a kind of threatening shadow,
because it comes more from the software world where things (a) have
shorter lives (b) deprecation strongly suggests eventual removal.

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

Yes, exactly. I find the concept of 'deprecated' implicitly raises the
threat/risk of removal, and since total removing something from an RDF
vocab strikes me as generally a bit antisocial (like pretending you've
never said something), I'm a bit uncomfortable with 'deprecated'.
Won't make a huge fuss, but that's my take.

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

I like 'archaic' but it might be a quite quirky for a W3C thing, but
something carrying that general intent I think would be a better fit.

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

Yeah, we have all the space in the world to explain the full
situation, on a per-construct basis.

Probably the main distinction to make here is between vocabulary terms
as features, vs. pieces of the RDF/XML grammar as features. The latter
is much more in the classic software world.

Would be nice in 2011+ if the URIs for
http://www.w3.org/1999/02/22-rdf-synax-ns and nearby were a bit more
human-friendly (RDFa? conneg?) and were around 2 clicks away from a
community wiki...

cheers,

Dan

>     -- Sandro
>
>
>

Received on Monday, 11 April 2011 13:23:28 UTC