[uf-new] hAudio issue D2 "title"

Mon Sep 1 17:39:56 PDT 2008

Tantek Celik wrote:
> I agree with you that this is a larger issue impacting existing 
> and new microformats, however, trying to come up with new names
> for the same meaning is not the answer, and will quickly fall apart.

*sigh* - and we were so close to getting hAudio to the draft stage... I
sense another 3 month discussion coming down the pipe, prolonging the
agonizing wait for hAudio to be finalized. Hopefully, I'm wrong.

> 1. any class name starting with an "h" should be treated as a 
>    root microformat which introduces a new scope

So, now we're looking into ditching Microformats mostly scope-less
design? I'm fine with that, but why now - I pointed this issue out a
year ago and there seemed to be push-back on adding more scope to
Microformats parsing algorithm:

http://microformats.org/discuss/mail/microformats-new/2007-June/000582.html

I'll certainly support any effort to add more parsing scope to uFs... we
should have done this a year ago.

> 2. introduce a root microformat classname like "hroot" or "hitem" which 
> introduces a new scope and require its use in addition to any new
> microformat root class name (eg class="hitem haudio") this is essentially 
> the mfo solution but with a friendlier generic root name. Feel free to 
> brainstorm additional friendly generic root names.

I believe that this approach would confuse the same people that find
namespaces scary - they won't understand why they need to provide
"hroot" beside their "haudio". If we're going to do scoping, we should:

1. Depend on the structure of the HTML document to provide that scope -
web developers understand that elements can go inside other elements...
it's an easy concept to grok.
2. Re-use a solution that already exists instead of rolling our own for
this community, if possible.

> 3. same as 2 except don't introduce any other root microformat-specific 
> class names, and use some other mechanism to specify what type/kind
> of microformat the item is. E.g. all new microformats would start
> with class="hitem" and then we come up with another way of "typing" them.

We could re-use RDFa's @typeof attribute - it does exactly that and is
defined in HTML4.01, XHTML1.1 and XHTML2.

We're working on extending RDFa to support just this very use case - it
would be a perfect fit.

> 4 ... ? Additional suggestions?

I suggest that we re-use RDFa's scoping rules since they have already
solved this problem for us. This dove-tails into my suggestion late last
week of working with the RDFa community to solve some of these
long-standing problems since both communities have much to gain from
working together:

http://microformats.org/discuss/mail/microformats-discuss/2008-August/012432.html

I'll post more when we have a more solid proposal together, but what we
have so far would solve the scoping issue for Microformats - opening the
possibility of re-using FN for hAudio. Here's how the markup would look
in practice:

<html>
<body prefix="http://microformats.org/vocab#">
...
<div typeof="haudio">
   <span rel="contributor">
      <div typeof="hcard">
         <span property="fn">Martin Luther King, Jr.</span>
      </div>
   </span>
   <span property="fn">I Have a Dream</span>, a 	
   <span property="type">speech</span> by
</div>

This would generate this Microformat object (JSON-ish encoding):

(haudio)
{
   contributor(hcard) :
   {
      fn : "Martin Luther King, Jr."
   },
   fn : "I Have a Dream",
   type : "speech"
}

We have the parsing rules for this if anybody is interested - it
definitely works, and we'd be happy to undertake a standardization push
for this via the W3C if this community was interested in doing so...

-- manu