[uf-discuss] hCard improvement - more implied "n" handling

[Drew McLellan]

On 11 Jul 2006, at 05:30, Tantek Çelik wrote:

> So the simple proposal is:
>
> If the implied "n" optimization (one or two words) doesn't apply
> and there is no "n" property, then treat the "fn" element as if it  
> is "fn n"
> and look for explicit "n" subproperties inside the "fn" element.

Sounds sensible to me.
My only concern is that the more rules we add to make things easy,  
the more rules each publisher has to learn.

An example of this is the existing implied-n, which makes it easier  
to publish a simple name, but requires the publisher to learn the  
five acceptable name formats. I'm not sure if that's surface-level  
simplicity. Would genuine simplicity require n at all times?

> Brian informs me that this is quite easy to implement, and I think  
> it will
> make the common n subproperty cases much easier to author correctly by
> default.
>
> Any objections to making this change?
>
> Scott, Drew, Assaf - any idea how hard this will be to implement in  
> your
> parsers?

There's only one way to find out .. and the short answer is it's hard  
to implement for me. Not for finding the values, but for presenting  
them in a predictable way to the next piece of software up the chain.

Saying that the sub properties of n are now permissible values for fn  
if n is not present, means that I need to jump through hoops to make  
that transparent in what I present back. But .. hard as in a couple- 
of-hours hard, not as in days. I have a build of this working, which  
I'm re-running through the hCard tests as we speak.

drew.