Thanks Colin, this proposal makes some good points. Some comments : For completeness, you should mention the possibility of an API-level implementation[1]. Even if this'll be met with a "patches welcome" and if we need a pragmatic solution in the meantime, supporting MV at the API level has some impressive pros & cons.
You barely broach the subject of how MV and namespaces combine. For example if an object has multiple refs with sources, it should be clear wether an MV tag corresponds to "multiple sources for all the refs" or to "source for the 2nd ref". In suffix syntax, this could be distriinguished by "ref_1=x ref_2=y source_1:ref=a source_2:ref=b" vs "ref_1=x ref_2=y source:ref_1=a source:ref_2=b", even though this is becoming hairy. Concerning ordered vs unordered, I don't think we should define it at this level. Wether a key is treated as ordered or not will depend both on the key and the consumer. For example searching for a POI will always treat the MV as unordered, but displaying it is likely to treat it as ordered (either by displaying an ordered list, or only displaying the first value). Conversely, a carefully ordered list might get interpreted as unordered (Say I want to promote POIs with a particular tag, and always disply that one first if present. Or I've loaded the values in a language structure that doesn't conserve order). A syntax to specify wether a list is ordered or not will typically be ignored by consumers, and will only make the spec messyer. IMHO, producers should write every tag as if it was ordered, and keep in mind that consumers will do their own thing anyway. [1]:http://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
