[uf-dev] Re: [uf-new] Microformats parsing, in general (was: hAudio final draft)

[Tantek Ç elik]

On 6/17/07 12:55 PM, "Scott Reynen" <scott at makedatamakesense.com> wrote:

> So we're left choosing
> between two microformat principles that don't work well together in
> practice.  We could get them to work together by continuing that MFO
> discussion, but then we'd be conflicting with yet another principle:
> solve a specific problem.  So which principle do we discard here?

This is likely to be precisely why we may need to solve this problem by
continuing the mfo discussion.

If you look at the current known alternatives:

1. require parsers to update whenever new nestable microformats are
introduced, and precisely define rules for handling known/common nesting
cases (to at a minimum avoid wasting time on straw-man arguments).

2. add a new class name to indicate a encapsulation scope (e.g. "mfo") when
embedding
 - = one new class name, only in cases where nesting occurs.

3. replicate/prefix property class names for each microformat e.g. audio-fn
 - = numerous new class names


It is pretty clear that #3 is the worst from a complexity (most new class
names) that would affect the most people (publishers) point of view.  So we
should seek to avoid #3 since that violates the principles the most.


#2 adds some incremental authoring complexity in some cases.


#1 is something that we can probably still do today since both the number of
microformats is small (a good reason to keep the overall number small), and
the number of parser implementations is small and parser implementers are
both involved in the community and able to update their code quite quickly (
cc'ing microformats-dev accordingly).


Therefore it is reasonable IMHO to:

Pursue #1 in the short term until we have solved #2 in the medium term.

Tantek