On Sep 27, 2006, at 9:48, Granqvist, Hans wrote:
Johannes, just to clarify, are you against allowing
multiple same-name params?
I don't like multi-valued fields, because in my experience, it is a
slippery slope that usually leads somewhere one does not want to end
up. It tends to go like this:
First iteration: we need a phone number, great, let's do:
PhoneNumber: 123-456-7890
Second iteration: but this guy wants to give us an alternate phone
number. Great, we have multi-valued fields, aren't we glad that we
did this, so we simply can say:
PhoneNumber: 123-456-7890, 234-567-8901
Third iteration: but he says that one of them is a daytime phone
number, and the other an evening phone number. Darn! Now we got to
kludge this in, because we have additional data related to one of the
phone numbers that we now have to attach to, somehow, creating this
bunch of happiness:
PhoneNumber: 123-456-7890 (day), 234-567-8901 (evening)
(which requires additional parsing and breaks all previous
implementations)
Or this one:
PhoneNumber: 123-456-7890 (day), 234-567-8901 (evening)
CallingTimes: 9-5 (PhoneNumber[1]), 5-10 (PhoneNumber[2]))
(which requires us to come up with a way of naming one of the values
of the multi-valued field -- which was the reason for the names in
the name-value pair in the first place)
Or other contortions. If one does this a few times, one ends up like
the famous cat-and-the-string picture ... in my experience, it leads
to spaghetti data (like spaghetti code)
In my view, the correct way of representing any of this is as
separate, first-class objects.
Johannes Ernst
NetMesh Inc.
http://netmesh.info/jernst
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
