[uf-discuss] Fwd: Removing the FN magic in the vCard microdata vocabulary

[Philip Jägenstedt]

Hi microformateers,

Please see the below forwarded question about removing the guessing of  
names when exporting vCard. Since Hixie wants the microdata vCard  
vocab/extraction to be compatible with microformats, I'm taking it to the  
source...

In short, I think that guessing the names will create problems for  
Vietnamese names (family-name given-name given-name), Chinese names (姓名  
without space), transcribed Chinese names (family-name given-name) and  
probably the Japanese and Korean names, for the same reasons.

Are there compatibility issues with not outputting an N line at all? If  
there is, would there be any issues with simply outputting N:;;;; ?

The current algorithm is used on http://foolip.org/microdatajs/live/ for  
reference.

-- 
Philip Jägenstedt
Core Developer
Opera Software

------- Forwarded message -------
From: "Tantek Celik" <tantek at cs.stanford.edu>
To: "Ian Hickson" <ian at hixie.ch>, "Philip Jägenstedt"  
<philipj at opera.com>, "Tantek Çelik" <tantek at cs.stanford.edu>, "Jeremy  
Keith" <jeremy at adactio.com>
Cc: "whatwg at whatwg.org List" <whatwg at whatwg.org>
Subject: Re: Removing the FN magic in the vCard microdata vocabulary (Was:  
[whatwg]Microdata feedback)
Date: Fri, 29 Jan 2010 18:08:33 +0100

There have been several issues filed specifically regarding 'n' and 'fn'
optimizations in hCard, in particular the i18n problem that is mentioned
in this thread, and resolved with errata updates to these algorithms.

This particular issue is documented on the hcard-issues-resolved page on
the microformats wiki page.

If there are further problems regarding these property optimizations, I'm
certainly open to seeing (and would like to see) them raised+documented so
that we can fix them in hCard. (There shouldn't be any divergence, and
frankly I'd prefer that vcard microdata simply reference hCard but I
realize that is waiting on hCard 1.0.1).

As I'm editing hCard 1.0.1 now and making changes to address issues just
like this - now is a very good time to give this feedback.

Please either send them to microformats-discuss at microformats.org or feel
free to add them directly to the hCard issues wiki page (preferable):

http://microformats.org/wiki/hcard-issues

And we can follow-up there.

Thanks,

Tantek



------Original Message------
From: Ian Hickson
To: Philip Jägenstedt
To: Tantek Çelik
To: Jeremy Keith
Cc: whatwg at whatwg.org List
Subject: Removing the FN magic in the vCard microdata vocabulary (Was:
[whatwg]Microdata feedback)
Sent: Jan 29, 2010 01:04

On Thu, 21 Jan 2010, Philip Jägenstedt wrote:
> On Mon, 18 Jan 2010 16:24:46 +0100, Jeremy Keith <jeremy at adactio.com>
> wrote:
> > Hixie wrote:
> > > > Finally on vCard, the final part of the extraction algorithm goes
> > > > to great trouble to guess what is the family name and what is the
> > > > given name. This guess will be broken for transliterated east
> > > > Asian names (CJKV that I know of, maybe others too). Just saying.
> > > > Also, why is it important to explicitly add N:;;;; for
> > > > organizations?
> > >
> > > This is intended to be compatible with Microformats vCard, which has
> > > these weird rules. If you think we should remove them, please at
> > > least first speak to Tantek and see why he thinks.
> >
> > The fn optimisation pattern isn't intended to catch 100% of cases,
> > just the situation "Firstname Lastname" or "Firstname Middlename
> > Lastname". So if you just use fn (formatted name) and don't use n
> > (name), the name will be extracted/guessed using the optimisation
> > pattern.
> >
> > In cases where the pattern doesn't work (e.g. "Anne van Kesteren", or
> > east Asian names) you can still explicitly specify the family name and
> > given name, over-riding the fn optimisation pattern. If you do this,
> > you need to explicitly state this is the name (n) as well as the
> > formatted name (fn).
>
> This is going to break badly whenever a template uses vCard microdata
> and its author either doesn't know the family name and given name
> (because the data was never collected) or doesn't even consider that the
> vcard conversion does this funny guesswork. If a social network site or
> similar does this, then Anne van Kesteren and Zhang Min (fictional name)
> will have their names messed up with no way of fixing it. At least I
> haven't seen a site which asks users to both fill in their full name and
> each component, which is what you need to get this right.
>
> > Similarly, for organisations, you don't have to explicitly set n
> > (name) if you apply both fn (formatted name) and org (organisation
> > name) to a string. This time, the optimisation pattern assumes that
> > the fn is the name of the organisation.
> >
> > Technically, the n property is *always* required but if you use either
> > of those two optimisation patterns, the n is inferred from fn.
>
> If this is just a technical problem with some software requiring N to be
> present, would it be OK to just output an empty N like for
> organizations?

That's a good question... As I mentioned above, the rule is here to be
compatible with Microformats. I'd be happy to remove it, but I'd like
confirmation from the Microformats community that it's ok for us to
diverge in this way from their vocabulary, and to find out if they have
any experience regarding how much of a problem generating a blank N in the
output when it's missing would be. Tantek, Jeremy, any opinions?