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._______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
