[Tagging] Wiki Edit War on using/avoiding semicolon lists

[Tod Fitch]

On Jan 23, 2015, at 7:47 AM, Richard Welty wrote:

> On 1/23/15 10:13 AM, jgpacker wrote:
>> I don't understand the insistence in using regexes as some kind of argument against semicolon lists.
>> 
>> A semicolon list is an extremely simple pattern.
>> Such a pattern can be easily parsed even WITHOUT regexes.
>> 
>> Me and other developers in this thread (Imagic, Friedrich, David, Dmitry, Marc) are trying to tell you semicolons are not a problem.
>> 
> +1
> 
> competent languages provide simple mechanisms for splitting
> strings on single characters. sometimes the function is even
> called "split"
> 
> richard

Yes, nearly every scripting language I've used has an easy way to split a string on a character or substring.

Is there is a value string that contains a semi-colon that is part of the actual value rather than a delimiter between values. I can't think of any but since for some key names the value field is free form I suppose it could happen. A semantic solution to that would be to document which keys may have (or maybe a shorter list of exceptions that cannot have) multiple values separated by semi-colons.

However there is the related question of how to deal with things like multiple addresses for one object, the subject of another current thread. In this case you probably don't want to be dealing with:

addr:housenumber=1234;7654
addr:street=Main Street;Elm Avenue

So you will be dealing with something like:

addr:housenumber=1234
addr:street=Main Street
addr:housenumber_1=7654
addr:street_1=Elm Avenue

Coming up with a uniform way of dealing with arrays of values would mean that a simple and consistent solution could be used for both problems.

I don't much care if the syntax of the key is "key:1", "key_1", "key#1" or "key[1]" but I do think that something needs to be picked for sets of keys that have related values. And once you do that the solution could be applied as an alternative to semi-colon delimited values in the case being discussed here.

Having one approach that solves two issues seems better to me than having two solutions. Yes, any robust data consumer software will have to deal with all the existing ways things are done now. But standardizing on way to go forward should help in the future.

Cheers,
Tod Fitch