On Jun 8, 2007, at 10:01 AM, Brian Suda wrote:
On 6/8/07, Scott Reynen <[EMAIL PROTECTED]> wrote:
This is the same problem with re-using any class name in multiple
microformats. As mentioned earlier, if we re-use "summary" in haudio
(which I'm not arguing for nor against here), what if we want to
embed haudio inside hreview?
SUMMARY is defined as:
A short summary or subject for the object.
http://microformats.org/wiki/classes
Right. There seem to be two issues here: 1) using the same term to
apply two different meanings and 2) using the same term to apply the
same meaning to two different concepts. Both are an issue with
"title," but the latter is still an issue with "summary" and "entry-
title". If we want to use any of those, we need to work out this
issue, as hAudio is specifically designed to be contained in existing
microformats.
How do we keep the haudio summary from becoming the hreview summary?
--- this is true, but sometime you want it to be both! Microformats
are purposefully simple and MICRO, we are quickly getting to WHAT
IF...
Obviously everything with hAudio is a "what if," as no one is using
it yet. But using hAudio in hReview is one of the most obvious use
cases. It's so obvious that we even considered foregoing hAudio
entirely and just using hReview. So hoping it won't come up strikes
me as foolish. Embedding hAudio in other microformats is a given.
Modularity and micro go hand in hand.
the original intent of microformats is NOT to boil the oceans
I'm not suggesting we shouldn't use existing class names; I'm
suggesting we should think about how that's going to work. Please
don't waste my time reciting microformat principles to me; after two
years, I have them memorized.
More generally, I think we should be defining parsing rules based on
the semantics, rather than vice versa.
--- this is difficult because the semantics are meant to be the same,
it is context that you want to look at, and sometimes you WANT it to
be in both contexts at the same time.
So let's account for that. Here's a simple rule to get the ball
rolling: for properties that should only occur once, only the first
occurrence should be parsed. This would allow us to use "summary" in
hAudio within hReview, with the two values identical if there's only
one, or separate as long as the haudio summary comes after the
hReview summary. And it would work just as well with fn or entry-
title or whatever we choose. So context collision is no longer a
constraint on re-using existing classes (though semantic collision,
of course, still is as it should be).
IF we start to propose that every term be prefixed with hcard-title so
it doesn't collide with media-title then we are no better off than
RDFa and namespacing.
I agree, and I don't believe I anywhere suggested a new hyphenated
class name, so I'm not sure why you're bringing it up.
firstly we should look at all the available properties[1] regardless
of where they are used.
I agree. And then we should figure out how we can actually use those
properties without confusion.
--
Scott Reynen
MakeDataMakeSense.com
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
