I've been following this and the addrN thread with a mixture of amusement and irritation.
Lots of the arguments come down to how easy it is to parse using some tool or another. Or whether the problem the original poster was trying to address actually exists. With respect objects that have multiple values for a key, the arguments seem to come down to either: 1. key=value1;value2;. . . ,valueN 2. key:value1=yes + key:value2=yes + . . . + key:valueN=yes As a programmer I can parse either set using any number of different methods. I am not against using a ":' in the key string to create name spaces and for grouping related keys. I think that is a very useful construct. But from a purely logical point of view, I'd say the second way misses the concept of "key=value" and is using "key:value" with a noise suffix of "=yes". Typically missing keys should be treated as having a value of either "no" or "unknown". Unless you can show me where key:value1="is something other than yes" then I may suspect you of putting values into the key field of the data. Might I suggest that a convention for keys that may contain multiple values that the ":" delimiter be used in the key but rather than putting arbitrary (data) values after the colon, use an numeric index: key:1=value1 key:2=value2 key:3=value3 . . At present we have approached each case on an ad hoc basis. Sometimes using a number suffix by itself (addr2), sometimes preceded by a underscore (name_1) and sometimes by using a semicolon delimited list in the value field. By setting a simple convention for key with an array of values I think many of these cases could be handled in a simple, easy to remember unified manner. Cheers, Tod Fitch _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
