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

[Sam Roberts]

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.

FN is the *presentation* format of card-owners name, either of N or of
ORG. N and ORG are structured, semantically meaningful information.
They should always be used in preference to FN, FN is for printing on
envelope labels and name cards, it is purely for output.

Its possible to derive FN from N only when creating a card, because the
creator knows their own cultural conventions, but you can't go the other
way, there is no way for the receiver to know the cultural conventions
of the creator of the card:

  FN:<given> <family>

or

  FN:<family> <given>

and certainly can't know the creators personal preferences:

	FN:JD Bock
	N:Bock;John;Donald,Sebastian;;
	NICKNAME:JDS
	ORG:Big Company;Product Development;Microformats and Web Apps

FN is what he wants on his card, how he customarily presents his name.
Its possible he is so widely known as JD that few people would recognize
"John Bock". N really is the name (broken down into identifiable parts),
and notice that ORG: is a multi-valued field, it starts at company, and
then lists organizational sub-units of smaller and smaller scope.  (The
text in the hcard spec seems to suggest ORG only has two levels, perhaps
I misunderstand it, and it wasn't clear to me whether it allowed
multiple middle/"additional" names.)

Also, while Apple is in no way an oracle on good vCard usage (they
actually mix vCard 2.1 and vCard 3.0 encoding in their ver 3.0 cards,
ack), I did a round trip test with:

  FN:blah blah
  N:foo;bar;;;

After input and output, the card was:

  FN:bar foo
  N:foo;bar;;;

They should probably keep my presentation Name and use it, but they
don't. They are more right to do what they do (ignore presentation name
and only preserve the structured name) than to do the opposite.

Maybe for organizations, if the ORG: has a single value and FN has the
same single value, that is a common way to present a company's card, but
even then, ORG is the primary source of the company name, FN should be
treated as readonly presention text.


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.
  
  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.

- 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.
  
  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:

  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".

- Don't treat the author's vCards as normative, or even examples of
  common practice. The examples in the directory info and icalendar
  RFCs are notoriously bad.

- 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.).



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.

Cheers,
Sam