[uf-new] hAudio ITEM/TRACK debate resolution

[Scott Reynen]

On Oct 21, 2007, at 10:54 AM, Brian Suda wrote:

> --- i agree with these two points, but what i disagree with this the
> design of this "container" so far i have heard it called a container
> about tracks and albums and i have heard it called "track" by default.

You may have heard that, but I believe no one said it.  I said hAudio  
is considered a track by default, but I did not say that hAudio  
*containers* are tracks by default.  hAudio containers are by  
definition not tracks, they're not the default, and anything specific  
to tracks does not apply to them.  But most of hAudio is not specific  
to tracks, it's generally applicable to all audio.

> --- (we have lost the original HTML example in all the replies) If we
> are using a unique property for the string that is the ALBUM name
> class="album" then it is redundany to have BOTH class="fn album"

FN does *not* mean album name.  It means *audio* name.  Whether or  
not that's the same as the album name determines whether or not we're  
talking about an album.  To paraphrase directly from the hCard spec:

If the "FN" and "ALBUM" properties have the exact same value  
(typically because they are set on the same element, e.g. class="fn  
album"), then the hAudio represents audio information for an album,  
and should be treated as such.

> FN
> should be used for 1 or the other for the name of the string, be it
> the string for the album name, or the string for the track name. Since
> tracks seems to me more common, class="fn" for track names... and
> class="albums" for album names, not class="fn" for tracks and
> class="fn album" for album names.

This would be a redefinition of either FN or HAUDIO.  Per the wiki  
[1], FN is "The name of the object."  The object here is hAudio,  
which means *audio*, not track, and not album.

> The reason you think you NEED class="fn album" is because of your
> "short-cuts".

False.  It's because the *meaning* of FN and ALBUM are not the same.   
They may at times refer to the same content, but that doesn't make  
them mean the same thing any more than FN and ORG mean the same thing  
merely because they often co-exist.

> If you have ONLY one way to represent the hAudio
> structure (which you don't there are several) then you do not need
> class="album"

Real world examples demonstrate multiple ways of representing audio.

> //haudio/fn == album name
> //haudio/item/fn == track name

That only works if we redefine HAUDIO to mean *album*.

> But instead haudio is attempting
> //haudio == track name

False.  HAUDIO means *audio*, not track.  You're treating a proposed  
syntax optimization as a new semantic structure, which is a mistake  
of yours, not a fault of the model.

> //haudio/fn == track name

False.  HAUDIO means *audio*, not track, so FN here means "audio  
name."  Calling that a "track name" may work in imprecise discussion,  
but we should be more precise here.

> //haudio/album+fn == album name (i don't understand this, it could
> just be //haudio//album)

False.  ALBUM means "album title."  FN (in HAUDIO) means "audio  
title."  That those two may in some cases overlap does not give them  
the sort of shared meaning you've suggested here, which would be  
completely at odds with the semantics of HTML's class attribute.

> But for now, if we impose a SINGLE structure to mark-up haudio (which
> i think is best, it helps adoption, examples and explaining) then we
> don't even need ALBUM.

The real world examples suggest otherwise.

> --- then this is two different things. With hAtom we solved the atom
> ENTRY, then put it in a FEED.

That made sense in hAtom.  It does not make sense here, because  
unlike feeds, audio has the same structure as both container or  
contained.  The publishing examples make this clear, and I think it  
would help if you looked more at those and questioned a few of your  
assumptions where they contradict the examples.

> If we have solved the atomic RECORDING,
> then we are putting it into a COLLECTION (or ALBUM) this is a level
> above hAudio.

False.  A collection of audio recordings is itself an audio  
recording.  This is the implied schema derived from the examples.   
You appear to be imposing your own assumed schema on this without  
regard to the examples.  That's not how the microformats process works.

> the concept of NESTING isn't new, hAtom does this.
> What is new and bad is nesting the same property inside itself.

False.  Again, hCard does that.  That doesn't make sense in general,  
but it *does* make sense for audio.  You've only criticized it in  
contexts that have nothing to do with audio, and are thus irrelevant  
to the proposal.  Do you disagree with the specific assertion that  
audio is made up of smaller segments of audio?

>  if this is the ATOMIC structure for a Audio Object, then
> we need a class ABOVE haudio to contain multiple hAudios, much the
> same way hEntry is contained within an hFeed.

Correct.  But it turns out this container is itself audio, so we can  
re-use hAudio here.  It seems to me you've assumed based on your  
previous experience in other unrelated contexts that a container  
could *never* be the same type as the contained items.  I believe  
this assumption is false, specifically in the context of audio, and I  
challenge you to back up your assumption with some sort of rationale  
rather than just repeatedly stating it as if it were fact.

>>> <!-- what is this? an album with a duration, or an un-named track in
>>> an album with a track duration? -->
>>> <div class="haudio">
>>>   <span class="item">
>>>     <span class="album">Album 123</span>
>>>     <abbr class="duration" title="PT30M24S">30:24</abbr>
>>>   </span>
>>> </div>
>>
>> That is incorrect markup. The parser would identify that as an album
>> called "Album 123" with a duration of 30 minutes and 24 seconds.
>
> --- how is that incorrect? what if that is exactly what i wanted?

If you don't even know what it means, how could it possibly be  
exactly what you wanted?  It is not the microformats process to start  
with markup and then try to figure out what it means.  We start with  
publishing examples, and figure out how to structure them most easily  
for publishers.

> hAudio is about tracks and Albums correct?

False.  hAudio is about audio.

> --- no, i agree completely that hAudio is a SINGLE audio recording. My
> issue is mainly with your original example which no longer models
> hAudio as a SINGLE audio recording:
>
> Album with two tracks, more detailed:

That an album is not a single audio recording is your *opinion*, not  
a fact.  The examples have suggested this opinion is wrong.

> Which brings us back to the my more verbose default TRACK of:
> <span class="haudio">
>     <span class="item">
>         <span class="fn">Hokkaido Dream</span>
>     </span>
> </span>
> This (for now until we discuss optimizations) is how you would need to
> write JUST a track.

For now we're using a schema that everyone agreed to before you  
entered the discussion.  You're welcome to try to question that  
schema and explain why you think a different schema would be better,  
based on real world examples.  But you can't just declare a different  
schema.  That's not how the microformats process works.

--
Scott Reynen
MakeDataMakeSense.com