I think the use of namespaces would be a good thing. These should not be confused with XML namespaces athough they could look similar and work in much the same way. Tags could have an optional prefix that indicates which scheme they belong to.  For example, the Map Features scheme could be designated as mf, and so tags that are part of that scheme could be entered like this:

<br><br>  mf:highway=secondary<br>  mf:name=High Street<br><br>Or, using the XML schema:<br>  <way id='123'><br>    <tag k='mf:highway' v='secondary'/><br>    <tag k='mf:name' v='High Street'/><br>  </way>

<br><br>It would be valid for a way, segment or node to have tags from more than one namespace so that the same feature can be tagged in multiple different ways.  For example, a mountain road might be a ski piste during the winter.  if there was an OpenPisteMap scheme designated as opm then that road could be tagged like this:

<br><br>  mf:highway=unclassified<br>  mf:name=Rue de Cote de Bette<br>  opm:piste=green<br>  opm:name=Piste de Chard Suisse<br><br>It also occurs to me that it might be reasonable to allow namespaces to have some structure, so that, for example, Map Features can have regional variants.  

mf.us:highway=freeway, mf.de:highway=autobahn.  This would allow local variations while still retaining some grouping of all those schemes that have allegiance to the Map Features church. Ultimately there would need to be a lookup table or registry somewhere of namespace names containing pointers to the definitions of the keys that belong to that namespace.  There would be sever uses for this.  Joe Public needs to be able to find out exactly what mf:abutters=mixed means.  Renderers need to be able to find a set of rules for rendering tags marked up with a particular scheme.  Validators (manual or automatic) would be able to find all the valid possibilities for keys and values of a scheme, and also tags that don't belong to any namespace or belong to an unregistered namespace.

<br><br>Etienne<br><br><br><br><div><span class="gmail_quote">On 6/12/06, <b class="gmail_sendername">Andy Robinson</b> <<a href="mailto:Andy_J_Robinson@blueyonder.co.uk">Andy_J_Robinson@blueyonder.co.uk</a>> wrote:

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The discussions over the last few days about keys and values raised an important point which I don't think has been really looked at before.

<br><br>Currently there is no convention for the format of a key other than what is<br>already in use and that does not necessarily help with the management of<br>tagging (when received from the database) as the database grows. The more

<br>keys that are generated the more complicated the analysis or rendering of<br>those keys will be.<br><br>I think to a large extent we need a coding perspective on this. For those<br>editing data its easy to use whatever convention there is, provided it is

<br>both logical (and by that I also mean easy to understand and relate to for<br>non-coders) as well as sufficiently flexible to enable any extension of use<br>that a user may wish.<br><br>A few ideas were floating around in the previous emails, including the use

<br>of Namspace referencing (which I think is a good idea), although guidance on<br>namespace use between keys and values is required. Personally I would prefer<br>to avoid coding type convention unless that's hidden under the hood of the

<br>editng software. What the user should see (if there is anything to see at<br>all) should be obvious and descriptive.<br><br>I did not put the "value" part of the equation into this discussion as I<br>think that's where the full flexibility should always be, albeit that the

<br>project may wish with time to adopt a default set of values to go with<br>certain default keys.<br><br>Anyway, this hopefully opens up the discussion. Suggest that ideas are noted<br>on the extra "keys" section I just added to:

<br><br><a href="http://wiki.openstreetmap.org/index.php/Key_Value_System">http://wiki.openstreetmap.org/index.php/Key_Value_System</a><br><br>Cheers,<br><br>Andy<br><br>Andy Robinson<br><a href="mailto:Andy_J_Robinson@blueyonder.co.uk">

Andy_J_Robinson@blueyonder.co.uk</a><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>