Proposal talk:Multivalued Keys
Wording
I don't recognise some of your categories: Subscript Syntax / Suffix Syntax / Hierarchy Syntax / Delimiter Syntax
My understanding is:
- key[N] = valueN ~ not Subscript Syntax (?), rather Index syntax
- key_N = valueN ~ not Suffix Syntax (?), rather Subscript syntax
- key:N = valueN ~ Hierarchy Syntax (?), also called Namespace syntax, see Namespace and Category:Namespaces or suffix
- key = value1;value2 ~ Delimiter Syntax, also called Semicolon syntax, see Semi-colon value separator
Good luck with the discussion. Althio (talk) 15:55, 27 January 2016 (UTC)
Pros/cons table
I've drafted this here on the talk page, but feel free to include when it has content.
All of the solutions have positive and negative sides to the them, so this table should be just a descriptive list for each variant. Whether each user considers them to be huge or unimportant, is to some extent a matter of personal judgement, and to some extent irrelevant. None of them are without any downsides, I tried to include all arguments I remember/I've seen especially on the tagging list. This could be sketched in another way too, but I'll leave that for later.
| Subscript syntax | Suffix syntax | Hierarchy syntax | Delimiter syntax | Notes | |
|---|---|---|---|---|---|
| Assuming all existing and future software is changed, mapper has to choose one value over others | no * | no * | no * | no | * "no" if there's [1] or _1 or :1 variant always when [2] or _2 or :2 exists |
| Assuming existing software isn't changed, mapper has to choose one value over others | yes | yes | yes | partial | Partial, because e.g. shop=supermarket;bakery isn't wrong, just not commonly rendered. "Yes" for others, because unaware software only sees the non-indexed key/tag. |
| Consumer can choose one value over others, regardless of "location" | yes | yes | yes | yes | |
| Consumer can "show" all values (e.g. icons), assuming changes in software | yes | yes | yes | yes | example for delimiter syntax at a tagging message |
| Known to have all data by indexing just the "key" | no | no | no | yes | |
| Plain text search of "key" finds the element | no | no | no | yes | Searching free form texts for most/all purposes employs some sort of wildcards for good UX. |
| Editing one tag is sufficient when adding/removing values | no | no | no | yes | Indices of other keys must be validated each time? |
| Editing one tag is sufficient when changing order of values when manually editing tags? | no | no | no | yes | for "no": up to n-1 other keys need to be changed |
| Key indexing can be broken when manually editing tags | yes | yes | yes | no | |
| Manual tag editing separates the values | yes | yes | yes | partial | A possible issue only with longer lists, or values with delimiters? |
| Tag editing UI can show values separately | necessarily | necessarily | necessarily | yes | |
| All current and future "dumb" software retains the order? | yes | yes | yes | yes | Currently, in index-based tags all but the first tag can be invisible/nonexisting. |
| Every value can be of maximum length (255) | yes | yes | yes | no | For delimiter syntax, even with 8 values they can have 31 characters each. |
| Key "part" ordering obvious to all, every time (name:fi:1 or name:1:fi) | random | set | random | N/A | |
| Symbols (delimiter) must be escaped or not used in the value | no | no | no | yes | Hasn't been an issue to date? |
| Symbols must be escaped or not used in the key | unlikely | potential for misinterpretation * | potential for misinterpretation * | no | Example: There could be in use population_2014=242, or hypothetical(?) building:usage:before:2012=office (i.e. not the 2012th value, but pertaining to e.g. a date) |
| Easy interoperability between single and multiple valued keys | partial | partial | partial | partial | Depends on other choices? E.g. (key=x + key[2]=y) vs. (key[1]=x) (only), and on end user use case |
| Incompatible* with some current widely used tagging syntax | e.g. turn:lanes=* | yes | yes | e.g. seamark=* tagging? | examples mentioned on tagging list. *) in the sense that vast changes required, if altered |
IMO there's no point to decide; each modelling context can choose the best variant for that use. Even if toolkits exist for processing/pipelining the updates to some (backend) systems, ad hoc users/use cases have to decipher the data, too. Alv (talk) 19:53, 27 January 2016 (UTC)
Thanks for the excellent work so far. I hope to see some resolution of this thorny issue as a result. I think rendering semicolon separated values will be more difficult than individual keys, whether subscripted or suffixed, for us mkgmap users because of the way such objects are parsed during compilation. I realize this should not be a part of the present discussion but I did want to point it out. Another minor point: The table would be more readily understandable if it used syntax like "Symbols must be escaped or not used" rather than "No symbols need to be escaped or not used". The double-negative at the end makes it confusing, at least to me. AlaskaDave (talk) 02:32, 28 January 2016 (UTC)
- Double negatives on some lines were there because I didn't initially want to use "yes" on red background or vice versa, but then I already added some lines that way, so I've changed that now. Alv (talk) 17:03, 28 January 2016 (UTC)
Examples
I'd like to see some examples. Mine? In UK landuse=farmland is a primary use of some land. It is also 'water catchment' for the collection of drinking water ... for example https://www.nwl.co.uk/your-home/environment/catchment-management.aspx (and yes I'd like to see landuse=water_catchment as a new value ... some areas in Australia are dedicated to water catchment) {Oh ... and thanks for adding this page} Warin61 (talk) 06:09, 28 January 2016 (UTC)