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

[Ryan King]

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_. 
22n.22_Optimization.

> ...
> 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:// 
microformats.org/wiki/hcard-examples.

> 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
--
Ryan King
ryan at technorati.com