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

[Scott Reynen]

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  
principles.

>> 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).
>
> --- 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
>> embedding
>>  - = 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:

- hCalendar
-- location
--- hcard (MFO)
---- URL

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
> publish.

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.

--
Scott Reynen
MakeDataMakeSense.com