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

[Dan Connolly]

On Mon, 2007-06-18 at 11:06 -0700, Tantek =?ISO-8859-1?B?xw==?=elik
wrote:
[...]
> 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.

Well, perhaps.

I don't like #1. I don't have much tangible argument against it, but
it puts a burden on me (as a parser implementor) that I'm not convinced
to take on. If other implementors take on that burden and work out
all the details, I'll perhaps reluctantly comply.

On the other hand, I find #2 appealing and I'm inclined to put
effort into it. I think that authors are willing to jump thru
a certain number of hoops if that's what it takes to get the
tools to do what they want, and they'll likely find the mfo
burden acceptable.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/