Multiple LOGOs or PHOTOs in hCard/vCard? (was Re: [uf-discuss] Avatar Microformat ?)

[Tantek Ç elik]

Actually, if you read the various property descriptions carefully, you see
that some properties (e.g. FN, N, BDAY), say "the", and others (e.g. PHOTO,
LOGO) say "a" or "an".

IMHO, the use of "the" may indicate a singular property.

Whereas the use of "a" or "an" seems to indicate that you may have more than
one instance of that property for that element.

Brian's right that some properties explicitly allow multivalues delimited by
commas (e.g. NICKNAME, CATEGORIES, etc.), but that doesn't prohibit
multiple instances of a whole property declaration in order to indicate
multiple values.

OTOH, look at the definition for TEL, it says "to specify THE telephone
number ..." (EMPHASIS mine).

Whereas clearly vCards can (and do) represent multiple phone numbers, both
in numerous Address Book clients and in hCards on the Web.

The same with the EMAIL property.

Both of these are illustrated with the example vCards of the spec authors at
the end of RFC 2426 (section 7. Authors' Addresses).

Thus, I believe it is correct to presume that multiple properties/values are
allowed unless *explicitly* forbidden by the format.

Thanks,

Tantek

On 12/28/05 3:24 PM, "David Janes -- BlogMatrix" <davidjanes at blogmatrix.com>
wrote:

> The "Overview" of vcard [1, page 2] says:
> 
>  In addition, traditional paper business card information such
>  as an image of an organizational logo or identify photograph can be
>  included in this person object.
> 
> I'm reading "an" and "can" as saying "0 or 1".
> 
> Regards, etc...
> David
> 
> [1] http://www.ietf.org/rfc/rfc2426.txt
> 
> brian suda wrote:
>> The problem i see in the RFC and hCard for having multiple Images is this:
>> 
>> All properties that allow multiple instances, NICKNAME do so as comma
>> delimited values
>> NICKNAME: bill, billy, Wil
>> 
>> and not as:
>> 
>> NICKNAME: bill
>> NICKNAME: billy
>> NICKNAME: Wil
>> 
>> In the RFC it is normally written at the end of the document as
>> something like:
>> 
>> NICKNAME: (text-value)*,
>> 
>> saying that it can take multiple 'text-values'
>> 
>> LOGO and IMAGE do not have the * operator, so i would interpret this as
>> NOT allowing multiple comma delimated values.
>> 
>> That leaves the question of can it have multiple instance of the same
>> property:
>> 
>> LOGO:....
>> LOGO:....
>> 
>> No other property does this, as my NICKNAME example above shows, so i
>> would not think LOGO, PHOTO to be any different.
>> 
>> So i DON'T think it is possible to have two or more PHOTOs or LOGOs, but
>> i might be missing something.
>> 
>> -brian
>> 
>> Tantek Çelik wrote:
>> 
>>> On 12/28/05 1:13 PM, "Paul Bryson" <paul at msn.com> wrote:
>>> 
>>>  
>>> 
>>>> "Charles Iliya Krempeaux"
>>>> <supercanadian at gmail.com> wrote...
>>>>    
>>>> 
>>>>> I'd agree with this if hCards allowed for multiple PHOTO's or LOGO's.
>>>>> So, from my perspective, the question comes down to: does an hCard
>>>>> support mutiple PHOTO's or LOGO's?  (My understanding so far is that
>>>>> they don't.  But please correct me if I'm wrong.)
>>>>>      
>>>>> 
>>>> I am currently using "logo" to display an avatar.  But I am curious if more
>>>> than one photo/logo is allowed per hCard.
>>>>    
>>>> 
>>> I don't see any wording in RFC 2426 (vCard) that prohibits multiple LOGOs or
>>> PHOTOs, therefore it is reasonable to allow for more than one in hCards as
>>> well.
>>> 
>>> Now, what different clients/applications do with those multiple LOGOs/PHOTOs
>>> is a different matter, but the assumption is that those implementations are
>>> constantly improving.
>>> 
>>> Your markup should reflect the content you are publishing.  The
>>> implementations will adapt to the content out there, especially if you add
>>> your particular content as one of the "Examples in the Wild" in the hCard
>>> specification:
>>> 
>>> http://microformats.org/wiki/hcard#Examples_in_the_wild
>>> 
>>> Thanks,
>>> 
>>> Tantek
>>> 
>>> _______________________________________________
>>> microformats-discuss mailing list
>>> microformats-discuss at microformats.org
>>> http://microformats.org/mailman/listinfo/microformats-discuss
>>> 
>>>  
>>> 
>> 
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss at microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>> 
>> 
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss