[uf-new] Reusing classes names in multiple formats

[Scott Reynen]

On Jun 8, 2007, at 10:01 AM, Brian Suda wrote:

> On 6/8/07, Scott Reynen <scott at makedatamakesense.com> 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