On 6/12/06, <b class="gmail_sendername">Immanuel Scholz</b> <<a href="mailto:immanuel.scholz@gmx.de">immanuel.scholz@gmx.de</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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

<br>> opm:piste=green...<br>> allow namespaces to have some structure...<br>> mf.us:highway=freeway, mf.de:highway=autobahn...<br>> lookup table or registry...<br>> unregistered namespace...<br><br>I know, you all will hate me for this comment, but: At first read I

<br>thought you are sarcastic.</blockquote><div><br>Sorry, not intending to be sarcastic at all.  Having re-read, I cannot see what makes you think there is any sarcasm in what I have written...<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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

be better.</blockquote><div> I think the users (us) are finding that the lack of any structure is becoming a bit of a problem.  See previous discussions about UK centric schemes, highway=autobahn, etc.  I think this initiative is not about some complex programming changes but more about the users doing some self-organising using the tools they have already got.  I really like the lack of any *enforced* structure, but I also see that there are benefits to several users sharing a common scheme - that is all that is happening.

</div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">But: Some of your ideas were thought before ;-). </blockquote><div>  Where?

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">To have a "registry",<br>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.  </blockquote><div> Can you give an example? I don't understand what you mean by "keywords can have keywords".

<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Together with a special keyword which is<br>per-user-defined, this is a simple yet powerful enough scheme to handle

<br>"registries". Alternatives for keys can be handled as well (value to the<br>key "alternative" of another key)..<br><br>The absolutly best thing about the "keys have keys"-stuff is: People who

<br>don't like the complexity can just ignore it.<br><br><br>The namespace idea came up before by just specifying "foo/bar/baz" as<br>keyword. </blockquote><div><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Alternative values were suggested to be used as<br>"value1,value2,value3" once before some month ago. However, I don't like<br>this ideas much.</blockquote><div><br>No, it's not a good idea.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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.

</blockquote><div><br>Yes, we do need namespaces (or an equivalent mechanism).  Otherwise clients will misinterprete tags.  Right now any way that has a tag class=secondary will be interpreted by some client as *a secondary road*.  

Someone in a recent thread, proposed a scheme that used a combination of type and class. The example they gave was type=rail, class=secondary to describe a minor railway line.  This is a perfectly good scheme if used in isolation, but any of the current clients that see a way tagged like this will interprete it as a secondary road.  The two schemes are not mutually exclusive.  That is why we do need namespaces or some equivalent mechanism.

<br><br><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Ciao, Imi<br><br><br><br>_______________________________________________

<br>talk mailing list<br><a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

</a><br></blockquote></div><br><br clear="all"><br>