[uf-discuss] Comments from IBM/Lotus rep about Microformats

[David Janes]

On 12/9/06, Brian Suda <brian.suda at gmail.com> wrote:
> On 12/9/06, David Janes <davidjanes at blogmatrix.com> wrote:
> > My recent thinking has been that the following rules may work:
> >
> > An "outer" microformat should
> > - never look for attributes inside nested microformats (particularly
> > hCard, hCalendar, hAtom and xFolk)
>
> --- i would also disagree with this because  then you creating
> dependancies across ALL microformats, now and forever. If i create a
> VALID hCard 1.0 parser... in 2 years when hFooBar hits the web, my
> VALID 1.0 parser is no longer valid - other microformats could
> obsolete existing standards. Microformats are meant as building blocks
> and they should be able to be using independantly and together...
> otherwise everytime someone marked-up an hCalendar with an hCard for
> the venue, your hCalendar location would be empty. It's not a bug,
> it's a feature.

How would someone marking up a hCalendar with a hCard make the
location empty under those rules? The hCard is part of the hCalendar,
both as part of the spec [1] and implicitly because it's there.

Ignoring the fact that it's part of the spec, my point still holds:
the _attributes_ of the hCard associate with the hCard and the hCard
as a _whole_ then is associated with the hCalendar.

Now, to understand your hFooBar example, consider two possibities:
hFooBar is embedded inside of (say) hCalendar, or hCalendar is used
inside of hFooBar.

If hFooBar is written to reuse class names from hCalendar, your 1.0
parser is going to be confused (interpret the microformat incorrectly)
in the embedded case _no matter what_. In the enclosing case (i.e.
hFooBar encloses hCalendar), it makes no difference because your 1.0
parser does not see hFooBar. If hFooBar does not reuse class names,
the your 1.0 parser is fine in both cases.

Regards, etc...

[1] http://microformats.org/wiki/hcalendar#More_Semantic_Equivalents