[uf-new] Microformats parsing,
in general (was: hAudio final draft)
scott at makedatamakesense.com
Mon Jun 18 16:50:11 PDT 2007
On Jun 18, 2007, at 3:27 PM, Brian Suda wrote:
> On 6/18/07, Tantek Çelik <tantek at cs.stanford.edu> wrote:
>> This is likely to be precisely why we may need to solve this
>> problem by
>> continuing the mfo discussion.
> --- Part of the reason the MSO discussion died is because it didn´t
> actually solve anything.
I'm not sure what this means. It seems to solve the problem we've
been discussing, the inability to publish embedded microformats with
shared property names and have them parsed as expected. As a result
of this, hAudio discussion abandoned any re-use of existing property
names. If that's not a problem, then we should change the naming
>> 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
>> cases (to at a minimum avoid wasting time on straw-man arguments).
> --- i do NOT like this alternative because it makes the assumption
> that you WANT the data to be two different things. For instance, if i
> have a URL as a child of hCard. Then the common parsing rules might
> say, when that hCard is a location of an hCalendar ignore the URL, but
> what happens when i WANT that URL to be part of the hCalendar - this
> leads to incorrect assumptions. I would rather let the PUBLISHER be as
> explicit as they want or not, rather than parsers attempt to
> interprent their intents.
Isn't that exactly what the MFO proposal would do?
>> 2. add a new class name to indicate a encapsulation scope (e.g.
>> "mfo") when
>> - = one new class name, only in cases where nesting occurs.
> --- The problem with MSO is something like the following:
> - hCalendar
> -- location (MSO)
> --- hcard
> ---- URL
> the URL is ignored for the hCalendar, but then the LOCATION is blank
> too because MSO says NOT to take any data. So we move the MSO inside
> the hCard
> - hCalendar
> -- location
> --- hcard
> ---- URL (MSO)
> Now you get some data for the location, but now URL is ignored for
> BOTH hCal and hCard.
You seem to be missing the third option:
--- hcard (MFO)
Doesn't this do exactly what the publisher intends, prevent hCalendar
parsers from looking within the hCard, while still allowing hCards
parsers to look within?
> --- each microformat can also defined its parsing rules. For instance,
> hAtom only looks for rel-tag NOT inside an hentry. there is no reason
> that a media format can´t define that an FN can ONLY be taken when it
> is NOT a child of an hCard, but then this limits the way people can
That only works when the included microformat is defined first. If
it's defined second, the outer microformat couldn't possibly have
considered it in its parsing rules (because it didn't exist when they
were determined). I don't currently know the answer to this
question: How can we include a new microformat, say hPet, using FN
inside hCard without unexpected results with hCard parsers? Of
course that's a hypothetical, but without an answer, microformats
like hPet, intended to be embedded, will NEVER re-use FN. Which is
exactly what's happening with hAudio.
> If there are hCards on the page, that is simply people data -
> no matter what it is nested in - i should be able to extract them
> independently of their scope.
And that's fine as long as we make it clear that no one can put
anything new using class="fn" within hCards. If they do, those
hCards will break. We can't both re-use property names and ignore
the context of those property names. My dog's FN is not my FN, and
if the only way for me to make that clear is to use class="pet-name"
instead of FN, that's what will happen.
More information about the microformats-new