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

[Ryan King]

On Apr 4, 2006, at 1:35 PM, Sam Roberts wrote:
> You have a description on the wiki of deriving N from FN, which  
> assumes
> things about the format of FN that are culturally specific (first  
> names
> before last, for example), when the very absence of N is a  
> violation of
> the vCard spec.

In hCard, you can always specify the N and its sub properties  
explicitly. However, as a convenience, you can merely specify an FN,  
then imply the N from that, given some very specific conditions.

> It sure looked to me like the spec is describing how to do that which
> shouldn't be done. Maybe saying "we know its a bad idea" would be a  
> good
> idea. I don't see why you have any rules at all.  Have you actually
> found non-conformant vCards in the wild that lack a N?

My point was that we know its a bad idea to do this in general– there  
is one very specific case where the implied-N optimization applies.  
Otherwise, you need to specify the N properties.

>> Actually, we already have compatibility with Apple's Addressbook.app,
>> by using UTF-16.
>
> Good, I am happy to hear you are doing that.
>
> I was concerned you were using the ;CHARSET= workaround described  
> on the
> wiki:
>
>  Apple Address Book
>
>  On both OSX.3 and OSX.4.
>  general comments
>
>      * There are issues with importing UTF-8 vCards. Apple Address  
> Book
> 	 * appears to treat .vcf files in the file system NOT as UTF-8, but
> 	 * rather perhaps Mac Roman?
> 	     o Workaround: Explicitly specify the UTF-8 charset for
> 		vCard properties/fields that have non-ASCII-7 characters.

Well, we use that, too. It works.

>> I believe newer versions of AddressBook have fixed  this bug.
>
> What bug? I didn't describe any bugs. Mangling utf-8 isn't a bug, how
> was AddressBook supposed to know utf-8 is my favorite character set?

Brian's already answered this in another email. AddressBook *did*  
have a bug, which has since been fixed.

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

Actually, hCard has grown on its own. hCard is definitely more  
mature, as it has had more attention given to it.

> You guys do know about the other XML versions of vCard, right?

Yes. And the RDF ones.

>> I'm not sure what you're asking for here.
>
> Take this example from the wiki:
>
> 	<span class="tel">
> 	<span class="type">home</span>:
> 	<span class="value">+1.415.555.1212</span>
> 	</span>
>
> Now remove the example from the spec. How would a reader be able to  
> know
> from the "specification" that "span" elements are to be used in the  
> XML?

Well, that's because <span> isn't required. You can use any  
appropriate element. <span> is used as an example, because it is a  
generic element with little semantic. BTW, this is an FAQ: http:// 
microformats.org/wiki/faq#.3Cdiv.3E_and_.3Cspan.3E_semantics .

> Maybe I missed it, but I don't see a specification, I see a design
> rationale (which is much appreciated, and sorely missing from many
> specs), and I see lots of examples.

Ok, so its not a "spec" in the traditional spec, but it seems to get  
the job done. Where it doesn't get the job done, let's improve it.

>>> - 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.
>
> I did indeed miss that page. It actually makes me more concerned, not
> less.
>
> I'm a huge fan of examples, but they don't replace a spec.
>
> The goal of "simplicity" is met by the spec if it can be used to
> implement. This spec can't be used without the examples, as far as  
> I can
> tell. Its text isn't normative. Theres no way I can see to go through
> those examples and say for each one "this field is transcoded from  
> vCard
> to hCard like this because it said to do ... in the spec".

Well, translating from vCard to hCard is not a use-case we've covered  
(most usage goes the other direction). However, there is a (rough)  
guide to authoring hcards [http://microformats.org/wiki/hcard- 
authoring]. What's more important for interop is how to translate  
from hCard to vCard, which is covered by http://microformats.org/wiki/ 
hcard-parsing.

> Its the opposite, you have to read the examples, and back-derive the
> specification from them because the rules aren't in the spec, as  
> far as
> I can tell.
>
> Specs that rely over-heavily on the examples (the iCalendar RFC in
> particular is bad for this) have the characteristic that when you  
> try to
> do something that you don't have an example for, you guess at how to
> handle it, and peoples guesses tend not to be the same.

But, in our case, since we don't have a static document, those  
attempts can be documented and incorporated into the wiki.

> Specific example, the NOTE field. Its value type is TEXT. TEXT can  
> have
> newlines, they are encoded as the two characters '\', and 'n'.  The
> hcard spec doesn't say how to handle TEXT, doesn't even mention its
> existence, AFAICT, and I can't find an example where \n was used on
> /hcard-examples, so I'm not sure how newlines would get represented in
> hcard.

They get represented as you would in any HTML document. I believe  
http://microformats.org/wiki/hcard-parsing covers some of this ground.

> Anyhow, its my suggestion that the spec would be more useful if it was
> written so the text is normative and the examples serve only as
> illustration, and to help implementors write tests.

Part of the reason the spec is so sparse, is that we want to avoid  
duplicating information from the RFC– duplication leads to errors,  
which we want to avoid as much as reasonably possible.

Also, as a sort-of meta-comment, I, personally would appreciate it if  
comments were phrased as questions or suggestions, not as complaints.  
Your points are valid, but please don't come at this project as if  
we're being negligent.

thanks,
ryan