[OSM-talk] keys

[Immanuel Scholz]

Hi,


> ...
> XML namespaces...
> an optional prefix...
> <tag k='mf:highway'> v='secondary'/>...
> tags from more than one namespace...
> mountain road might be a ski piste during the winter...
> opm:piste=green...
> allow namespaces to have some structure...
> mf.us:highway=freeway, mf.de:highway=autobahn...
> lookup table or registry...
> unregistered namespace...

I know, you all will hate me for this comment, but: At first read I
thought you are sarcastic.

Well, I think your idea is to complex to bother with. Sometimes I even
think the original idea of not having "keys" and "values" thing but
letting the user enter some keywords without any structure (flickr) might
be better.



But: Some of your ideas were thought before ;-). To have a "registry",
where some metainformation about the data is stored was part of the
key/value design from beginning. The idea was that keywords can have
keywords and so clients are able to read out these keywords and interprete
them by themself.  Together with a special keyword which is
per-user-defined, this is a simple yet powerful enough scheme to handle
"registries". Alternatives for keys can be handled as well (value to the
key "alternative" of another key)..

The absolutly best thing about the "keys have keys"-stuff is: People who
don't like the complexity can just ignore it.


The namespace idea came up before by just specifying "foo/bar/baz" as
keyword. Alternative values were suggested to be used as
"value1,value2,value3" once before some month ago. However, I don't like
this ideas much.


So do we REALLY need alternative, namespaced, hierarchy ordered, registry
stored key-lists? The fastest, most robust and most performant
implementation of a feature would be to just sacrifice the feature and
live without it.

Ciao, Imi