Re: [VCARDDAV] KIND in draft 15

[Tantek Çelik <[e-mail]>]

On Mon, Dec 20, 2010 at 11:48, Simon Perreault
<[e-mail]> wrote:
> On 2010-12-20 14:16, Tantek Çelik wrote:
>> In my experience those "groups" in such user interfaces, e.g. Apple
>> Address Book, are typically *not* represented as vCard objects
>> themselves, but rather as CATEGORIES on the contacts that are in the
>> groups.
>
> Yes, this is one way that they can be implemented.

This is is how they *are* *interoperably* implemented today.

If you know of any other examples that implement groups differently,
please provide them.

All examples / evidence provided to date shows *one* type of
implementation - group = category on the vcards in the group. Nothing
more.


> But it only allows
> for a group name, nothing more.

Correct.

I just checked Apple Address Book (v5.0.2 on OSX10.6.4) and Gmail
Contacts and both UIs allow for a group name, nothing more.


> Any UA that allows the user to input
> meta-data about a group cannot be implemented with CATEGORIES. And there
> are plenty of such UAs out there.

I claim theoretical.

If there are "plenty of such UAs", please name specific names,
versions, (and preferably URLs). None have been provided so far.



>> No GUI elements - the data point here is the existence of real world
>> *content* (the contacts themselves) that are examples of the data
>> model addition represented by KIND:LIST and KIND:ROBOT.
>
> This highlights some confusion about the "already widely implemented"
> criteria for getting into vCard 4 base.
>
> I originally stated the criteria as "it is needed by a majority of vCard
> implementations". See here:
> http://www.ietf.org/mail-archive/web/vcarddav/current/msg00958.html
> It seemed to make consensus at the time.

I agree with that general principle - thank you for pointing it out -
it will help weed out and simplify the current draft even further.

Bigger question: is there any public documentation by anyone in this
group of existing vCard implementations' features that we can use to
reason about for consideration of new features (or dropping unused
features) ?

If not, I will volunteer to start a wiki page - all this gets lost in email.


> Obviously, current vCard implementations cannot have already implemented
> something that we're planning for vCard 4. But if current
> implementations try to provide a similar feature, either through
> standard or non-standard means, that's enough justification for
> introducing such a feature in base vCard 4.

Agreed. This is reasonable analysis as well.


> The fact that groups are implemented through file-system directories
> with meta-data, or using DAV meta-data, or through CATEGORIES, or even
> in ways that do not involve vCard at all, is enough justification in my
> mind for us to say "this feature is needed by a majority of vCard
> implementations needs to be in the vCard 4 core spec".

Possibly. In this case it may have just been that developers decided
that "groups" merely provide an easier to understand user interface
model on top of the data model of "categories".

I think we can use a bit of Occam's razor here - the simplest
explanation is one that doesn't require any additional features, and
thus that's what we should take.


> However, I don't know of any UA that implements a feature similar to
> KIND:LIST or KIND:ROBOT.

Agreed.

> That's not to say that current UAs cannot
> *store* such addresses, but I don't know of any that lets me flag them
> as such (e.g. by toggling a checkbox).

Agreed. On the contrary, Apple Address Book does have a [ ] Company checkbox.
Per the same reasoning, note that it DOES NOT have a [ ] Group checkbox.


> Obviously that currently wouldn't
> be implemented with the KIND property since it doesn't exist yet, but I
> would be looking for an implementation using non-standard properties or
> whatever else. I don't know of any such implementation.

Neither do I. Hence I agree that these belong in a possible
*extension*, not in the core.



On Mon, Dec 20, 2010 at 12:47, Helge Hess <[e-mail]> wrote:
> On Dec 20, 2010, at 11:16 AM, Tantek Çelik wrote:
>> In my experience those "groups" in such user interfaces, e.g. Apple
>> Address Book, are typically *not* represented as vCard objects
>> themselves, but rather as CATEGORIES on the contacts that are in the
>> groups.
>
> In the case of Apple AB the groups ARE represented as vCard objects. (and also added to CATEGORIES as a secondary).

This is false (as far as can be proven/demonstrated from the user
interface, which is all that we can reasonably argue about).

I just used Apple Address Book (v5.0.2 on OSX10.6.4) to create a new
group, two new contacts, add the contacts to the group, and then
export the group as VCF.

The result was a VCF with the two contacts, with category of the group name.

Nothing more.

No vCard objects representing the groups.


In short:

Both the concrete implementations discussed in this thread so far:
* Apple Address Book
* Google Contacts

agree 100% on how Groups work, and that they only:
* specify group name
* affect the contacts in the group by adding to the CATEGORIES
property of each of the included contacts the name of the group.

And that's it.

None of them have:
* an X-KIND property
* vCard objects in VCF export that represent the groups themselves.


If anything, this evidence points to a suggestion to add informative
language to the draft stating if your vCard application has a notion
of groups, that it should use CATEGORIES on individual vCard objects
to indicate which groups they are in, since that is established
current *interoperable* practice.

Let's document what is already interoperably implemented, instead of
creating a new duplicate mechanism.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5