Unique IDs for the addresses-Element

[Matthias Pfefferle]

Hello,

I want to propose a unique ID for the address-Element. Without a ID it
is very difficult to detect if two addresses are equal (you have to
compare field by field), if one of the addresses is an update of the
other one or if they are completely different.

The 'tag' URI Scheme: http://tools.ietf.org/html/draft-kindberg-tag-uri-07

<addresses>
<id>tag:yiid.com,2009-08-02:1337</id>
<type>home</type>
<streetAddress><![CDATA[742 Evergreen Terrace
Suite 123]]></streetAddress>
<locality>Springfield</locality>
<region>VT</region>
<postalCode>12345</postalCode>
<country>USA</country>
<formatted><![CDATA[742 Evergreen Terrace
Suite 123
Springfield, VT 12345 USA]]></formatted>
</addresses>

Matthias Pfefferle
(http://pfefferle.yiid.com)

[Joseph Smarr]

Matthias-you're certainly welcome to add this field to your implementation as an extension, if you find that useful. I know Yahoo's Contacts API (and maybe others) also try to include a field-level-ID for these sorts of cases, though in practice I think it would be hard to get widespread adoption. Most address books just have text fields for entry after all, and they don't keep records of what was added/edited/deleted on a per-field basis. And even if they did, it's not always clear whether someone replacing say one phone number with another in one address book should be seen as "update all other old instances of that phone number with this new one" or "a new phone number plus getting rid of a different phone number", which might mean different things to different clients based on how many phone numbers they can support at once. And even if you have field-level IDs for syncing changes, you still always have the "first-time merge" problem with a new client where you have no choice but to do smart/fuzzy matching of fields based on their content, so field-level-IDs aren't a panacea even if they're useful in some cases.

So for all these reasons, my advice would be: just start doing it yourself and see how far you can push things, but I don't think leading with a spec change is the pragmatic course of action here.

Thanks, js

[Matthias Pfefferle]

Thanks for your reply Joseph, I will try to add some IDs to our own
PoCo schema and will gather some more experience.

Matthias Pfefferle
(http://pfefferle.yiid.com)

On 23 Sep., 20:43, Joseph Smarr <jsm...@gmail.com> wrote:
> Matthias-you're certainly welcome to add this field to your implementation
> as an extension, if you find that useful. I know Yahoo's Contacts API (and
> maybe others) also try to include a field-level-ID for these sorts of cases,
> though in practice I think it would be hard to get widespread adoption. Most
> address books just have text fields for entry after all, and they don't keep
> records of what was added/edited/deleted on a per-field basis. And even if
> they did, it's not always clear whether someone replacing say one phone
> number with another in one address book should be seen as "update all other
> old instances of that phone number with this new one" or "a new phone number
> plus getting rid of a different phone number", which might mean different
> things to different clients based on how many phone numbers they can support
> at once. And even if you have field-level IDs for syncing changes, you still
> always have the "first-time merge" problem with a new client where you have
> no choice but to do smart/fuzzy matching of fields based on their content,
> so field-level-IDs aren't a panacea even if they're useful in some cases.
>
> So for all these reasons, my advice would be: just start doing it yourself
> and see how far you can push things, but I don't think leading with a spec
> change is the pragmatic course of action here.
>
> Thanks, js
>