[OSM-talk] Cross-renderer tag support, now with OSMdoc!

[andrzej zaborowski]

2009/12/19 Steve Bennett <stevagewp at gmail.com>:
> On Sun, Dec 20, 2009 at 12:28 AM, Cartinus <cartinus at xs4all.nl> wrote:
>>
>> What this is also very good for, is pointing out all the "broken" stuff in
>> the
>> default Osmarender rules. Like the values for shop tags under amenity and
>> the
>> values for religion tags under denomination.
>>
>> They are redlinked, not supported by the other things in the list and not
>> used
>> according to OSMdoc.
>
> I think this is a pretty important question, and as others have pointed out,
> shows a failing in Osmarender. IMHO, renderers should *not* support endless
> numbers of deprecated tags, or should only do so in limited circumstances.

Deprecation makes sense in software projects but not so much in OSM
unless we start to approach the database more like a code repository.
There's an unwritten rule that when you deprecate/remove a feature,
it's up to you to correct all the usages in the current repository and
any other repositories you have access to, in the same atomic commit.
If you remove a feature and fail to update the usages, you break the
build (in our terms you break the rendering of some area on the
opposite side of the planet), and that's always a bad thing and you
may lose commit access.  (Same if you don't write an appropriate
comment for your change).

This is even more difficult when you're deprecating a library's api.
You have to make sure that for at least some time the old API works
but the users are shown a deprecation warning (I guess in OSM terms
that could mean sending out messages).  As a minimum you have to
update the examples in your repo.  That's why there's a policy of
first adding as little api as possible, because it's always easy to
add entry points and difficult to remove them.

Cheers