On Jun 18, 2007, at 3:27 PM, Brian Suda wrote:
On 6/18/07, Tantek Çelik <[EMAIL PROTECTED]> 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
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
