- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 7 Feb 2011 12:14:44 +0100
- To: Brian LeRoux <brian.leroux@nitobi.com>
- Cc: public-device-apis <public-device-apis@w3.org>, Rich Tibbett <rich.tibbett@gmail.com>
Hi Brian! On Feb 4, 2011, at 18:55 , Brian LeRoux wrote: > Hi guys, long time. At risk of minor noise pollution I'm forwarding an > email from phonegap ios hacker Becky Gibson about a conflict we're > having in spec interpretation. Thanks a lot for sending in implementation feedback, we need all that you can give no matter how obscure or unpleasant. > Our problem is in find() on contacts. If a contact has a field that > is an array and it is empty should we return null or []? > > The spec isn't particularly clear (or very clear that it should be > null if you read below) though my intuition would say an empty array > is 'the right thing to do'. I agree that the spec isn't very clear, and that it should be clarified. My understanding of the behaviour that we want is this (this is entirely personal, it might not at all be what others had in mind, which is why I'm copying Richard): - if the field is not supported by the underlying address book (say, it doesn't at all allow for the storage of URLs) then the field MUST be present and null; - if the field is supported, but the user hasn't entered any data for it (or requested that that data not be exposed) then the field MUST be present and with an empty array. I'm not sure that that distinction is helpful though, since it's not reflected in non-array fields (we could have null/empty string for some of the others, but we couldn't have null/empty date for the date fields). Do you have an implementation preference? It seems from what you quote that it mostly boils down to small tweaks. -- Robin Berjon - http://berjon.com/
Received on Monday, 7 February 2011 11:15:14 UTC