Re: Differences in contact api implementation

On Mon, Feb 7, 2011 at 12:14 PM, Robin Berjon <robin@berjon.com> wrote:

> 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.
>

I second that. We greatly appreciate your feedback, particularly on
low-level implementation matters that we need to tighten up.


>
> > 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 a field is not supported by the underlying address book then that field
is not included in a returned Contact object. It's this way so that a web
app can do something like the following code to figure out what is supported
by the underlying implementation:

for(var i in contact) {
  alert(i + ' is supported in the underlying implementation!');
}

That's doesn't mean that fields not present in the returned callback cannot
be added to the Contact object by the web app, just that it's likely that
the underlying implementation is not going to store these fields correctly.

This is reasonable on the grounds that the specification requests that
implementations support all fields contained within the Contact object (the
spec goes so far as saying that a conforming implementation MUST implement
all Contact fields [1]). The mechanism above becomes particularly useful
when implementations ignore that requirement and/or extensions are added to
the Contact objects returned [2].



>  - 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.
>

For me that makes sense but currently the specification states that in the
case that the field is supported and this field does not have any values in
the stored Contact object, that it should be present with a value of NULL. I
can't remember having written anything to contradict that in the past.


> 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).
>

On the one hand I like the uniformity of using 'null' across all supported
attributes that have not been given a value. On the other hand, we might
like to have an exception to this rule for fields that require a sequence
due to the experience's you've encountered in implementation. Right now, the
spec is clear that it should be 'null' rather than an empty sequence though
I'm open to changing that if there's a convincing argument to do so.


>
> Do you have an implementation preference? It seems from what you quote that
> it mostly boils down to small tweaks.
>
>
Right. If you provide your preference then we'll be motoring. An editor
presents the current group thinking and tweaks that depending on how
implementors actually implement stuff :)

Thanks and please fire lots more of these types of issues at us.

- Rich



>  --
> Robin Berjon - http://berjon.com/
>
>
>
>
[1] http://dev.w3.org/2009/dap/contacts/#conformance
[2]
http://dev.w3.org/2009/dap/contacts/#extended-contact-properties-and-parameters