[uf-new] An argument against 'fn' in hAudio

[Scott Reynen]

On May 8, 2007, at 2:20 PM, Manu Sporny wrote:

> Brian Suda wrote:
>>> None of this applies to hAudio - and we don't want Microformat
>>> implementors confusing how to use 'fn' in hAudio and how to use  
>>> 'fn' in
>>> hCard.
>>
>> --- these are two very different things. This is a non-issue. hCard
>> parsers do onething, and you can defined Media parsers to do  
>> something
>> completely different. FN is just a semantic value not defining  
>> parsing
>> instructions, that is up to the format.
>
> You almost had me convinced until you said this. It seems very strange
> to me that something that is supposed to be 'semantically  
> equivalent' is
> parsed in very different ways between two Microformats.
>
> If things are semantically equivalent, why aren't they parsed in the
> exact same way?

<span class="fn">Some Name</span> is parsed the same in any  
microformat.  But names of people are more complex than names of  
songs, so they have additional parsing rules to account for the  
additional markup options.  That doesn't change the meaning of <span  
class="fn">Some Name</span> at all.

> To illustrate the implications of calling two things the same thing  
> when
> they are different:
>
> Here's a duck, it quacks and floats on water. Here's another duck, it
> whinnies and gallops on land.

Ducks and horses are two different things, but we use the same term,  
"animal," to refer to both.  FN is a similarly generic term.

> If two things have to be parsed in different ways, how can they be
> semantically equivalent?

The meaning is determined by the markup, not the parsing.

> I would have no problem with using 'fn' if it didn't have all of the
> parsing cruft from hCard.

It doesn't.

> If something is parsed differently, isn't it
> intrinsically different?

No.  Every browser parsers a given HTML document differently, but the  
HTML document still means the same thing.

--
Scott Reynen
MakeDataMakeSense.com