[uf-discuss] Some hcard feedback from a vCard implementor

Ryan King ryan at technorati.com
Tue Apr 4 11:38:36 PDT 2006

Hi Sam, welcome to the list!

On Apr 4, 2006, at 10:25 AM, Sam Roberts wrote:

> Hi, I'm the author of Vpim (http://vpim.rubyforge.org), an
> implementation (in progress) of vCard and iCalendar encoding/decoding
> for ruby. Some comments on the hcard specification.
> I notice hcard is trying to deduce semantic information from FN,  
> but I'd
> like to convince you this is a Bad Idea.

Don't bother, we already now its a bad idea. The "Implied N  
optimization" only applies in certain cases. In other cases, you can  
specify the N fields. See http://microformats.org/wiki/hcard#Implied_. 

> ...
> Couple other thoughts:
> - You don't mention internationalization. Its a weakness in vCard. I'd
>   suggest that you specify hcard as being in unicode, with utf-8  
> without
>   a BOM as the preferred encoding.

There's no need to specify an encoding for hcard, that problem is  
deferred to the (x)html layer. Per the parsing document (http:// 
microformats.org/wiki/hcard-parsing), those encodings should be honored.

>   A note on what I've noticed about AddressBook. It sounds like you
>   already noticed that Apple mangles utf-8 on import (I haven't tried
>   utf-8 with a BOM, though). If interop with Apple is something you're
>   looking for, then you need to be either ASCII (or maybe some ancient
>   Mac character set), or else UCS-2. They started adding a BOM to the
>   start of their exported UCS-2 in the last year or so. Putting one in
>   is probably a good idea. I wouldn't try to embed character sets  
> inside
>   the card using parameters, not likely to be very portable.

Actually, we already have compatibility with Apple's Addressbook.app,  
by using UTF-16. I believe newer versions of AddressBook have fixed  
this bug.

> - The spec reads like a bunch of simple examples, not a spec,  
> though the
>   discussion of design principles is nice. hcalendar is even more
>   lacking, its just a cut-n-paste of hcard, with lots of information
>   removed! You won't get good interop without a more detailed spec
>   and great examples.

Hmm, I could consider the simplicity a feature. If there are areas of  
the spec that need more detail, please point them out, but I'm not a  
fan of complexity for its own sake.

>   Maybe I'm just not up on XHTML and the semantic web and the  
> structure
>   of the XML would be clear to me if I was, but I don't see any  
> general
>   process for converting vCard fields into XML. What I'd be looking  
> for
>   to add hcard as an output format for vCard is something like:

Are you looking to convert vCards into generic XML or into hCards?

>   vCard --
>     name[;pname=[pvalue[,pvalue]*]]*:value
>    ==>
>    hcard --
> 	<blah class="NAME">
> 	  <span type="pname">pvalue</span>
> 	  value
> 	</blah>
>    Followed by the short list of special rules/"optimizations".

I'm not sure what you're asking for here.

> ...
> - Don't make their mistake. Please put at least two examples in your
>   spec: an organization, and an individual. And make them COMPLICATED.
>   Two photos, a bunch of different kinds of addresses, real names
>   (middle names, suffixes, etc.).

I like have the spec simple, we have other space for examples: http:// 

> Final thought - from a programmers point of view, the inconsistency of
> human names and titles may be annoying (who needs multiple last names,
> really?), but thats how people are. Better to embrace something close
> to human conventions from the start than to try and get away with an
> overly simplified model, I think.

Um, actually, I think we are embracing human conventions. If there  
are places where we appear to not being doing so, please speak up.

Ryan King
ryan at technorati.com

More information about the microformats-discuss mailing list