[uf-new] hAudio ITEM/TRACK debate resolution

[Manu Sporny]

Brian, it sounds like you have several misconceptions about hAudio, some
of them are from recent changes that we have discussed on the list, some
of them are from discussions that we have had long ago. I am going
attempt to address the ones that are most poignant and explain why we
are where we are right now.

First, let me state that hAudio is about "audio recordings", of which
tracks and albums are a subset. I think you were under the impression
that hAudio was primarily about Albums and containing tracks. It is not.

While we have borrowed some design elements from hReview and hCard, we
should not get confused between the various Microformats and hAudio. We
should draw parallels to hReview and hCard when it is applicable, but to
say that hAudio is EXACTLY like hReview or hCard is a mistake. It is not.

At this point, we are not discussing what properties should be a part of
the hAudio specification. It seems that everybody is more or less agreed
on what properties should be a part of the specification. We are discussing:

- Naming those properties (specifically, tracks in audio albums)
- The structure of hAudio as a container.

Specifically, we are talking about tracks in albums, and what should
denote the track container in hAudio.

Brian Suda wrote:
> If that is so, then FN is NOT needed.

FN is needed because the examples show that both album and song name are
listed on a page next to each other. Such as when a blogger talks about
a song that is a part of an album. This is done quite often on the
hundreds of music blogs[1] on the 'net. For a specific example of this
happening, check out Scissorkick[2], which usually lists songs and
albums together.

Additionally, ID3v1 and just about every other audio metadata tagging
standard has the ability to specify the album name and the song name. We
have plenty of examples[3] and metadata formats[4] that support this
approach.

> I personally
> don't like ALBUM, because then we get an enumerated list of people's
> pet projects, PODCAST, ALBUM, COLLECTION, etc, but that is another
> discussion.

We have too many examples to ignore ALBUM. We also have too many
examples to ignore FN.

We are not discussing PODCASTs or other pet projects because we don't
have enough data yet. However, the latest proposal would be able to
markup both podcasts and collections.

>> See above.  If you still think it's wrong to use hAudio for both
>> album and track, please explain why you think this should differ from
>> hCard's model.
> 
> because hCard doesn't have class="vcard" for the root and class="vcard
> item" again to specific all the people or orgs that it may contain. I
> think i agree with you, if i understand your model of the assumption
> being a track, with an explicit album name. I don't think i agree with
> having nested types of the same object... a TRACK that has an album,
> but actually then has multiple tracks inside it... to me that isn't
> ideal.

I think there is a disconnect between what was proposed and how you
interpreted it. We are not saying that you can have "a track that has an
album with multiple tracks inside of it" - that is an abuse of the
hAudio spec. Just like somebody specifying a review having to do with 6
items that are completely different from one another.

>> Or #3, we could recognize that when the audio's name is the same as
>> the album's name, the audio is an album, without requiring an
>> explicit statement from publishers.  This solution removes the main
>> problem with both #1 and #2 above: unnecessary declaration of
>> containers or items that may not even exist.

You are assuming that the current proposal requires you to unnecessarily
declare containers. It does not.

> vCard is ever ONLY about 1 object at a time, just like hAudio should
> be about 1 object at a time, (either a track or an album). Attempting
> to squeeze multiple things inside should either be out-of-scope or
> looked at later, we don;t have a format, yet we are attempting
> something no other microformat does.

We are doing this because this structure is inherent in almost every
audio example collected to date. hAudio is about audio recordings, audio
recordings have parts that people specify, be it tracks, sections,
movements, etc. hAudio is not hCard.

We are already at "later" - we have solved the "atomic recording"
problem for hAudio. We are now attempting to solve the "recording with
multiple parts" problem for hAudio.

Why is attempting to do something that no other microformat does a bad
thing? It is true that no other Microformat does
sections/collections/parts. I would argue that is so because no other
Microformat has collections as an inherent part of it's structure...
hAudio does.

>> That's pretty much exactly what everyone's agreed to, except we're
>> using "album" instead of "collection."  If you think this should
>> change, please explain why.
> 
> --- i don't really care what it is called, but if we choose ALBUM,
> then all the podcasters complain, if we choose ALBUM then all the
> people who release it in another format complain... 

Then we will address the problem when people start complaining. We have
more than enough examples to back up creating a collection property
called ALBUM. The same cannot be said for PODCAST, PLAYLIST, or TOPLIST.

The reason we are using ALBUM is because "type" is never specified in
most of the audio info examples collected to date. We needed a way of
specifying the name of an album and the type of an album. The choice in
name came solely from the requirements that the examples dictated.

It might help if we use examples of what we are talking about:

> <!-- This is a TRACK and ONLY a track -->
> <div class="haudio">
>   <span class="fn">Track 123</span>
> </div>

The above could also be written like so:

   <span class="haudio">Track 123</span>

This describes a single audio recording called "Track 123".

> <!-- This is a TRACK with some metadata -->
> <div class="haudio">
>   <span class="item">
>     <span class="fn">Track 123</span>
>     <abbr class="duration" title="PT3M24S">3:24</abbr>
>   </span>
> </div>

The above, while it would parse correctly, is not advised markup. It
should have been written like so:

   <div class="haudio">
      <span class="fn">Track 123</span>
      <abbr class="duration" title="PT3M24S">3:24</abbr>
   </div>

This is a single audio recording called "Track 123" with a duration of 3
minutes and 24 seconds.

> <!-- if haudio is TRACK by default, then there is no need to have
> "item" here, right?-->
> <div class="haudio">
>     <span class="fn">Track 123</span>
>     <abbr class="duration" title="PT3M24S">3:24</abbr>
> </div>

Correct... nobody said that ITEM was required for a single audio recording.

> <!-- But This is also a only TRACK? -->
> <div class="haudio">
>   <span class="item">
>     <span class="fn">Track 123</span>
>   </span>
> </div>

Again, this would parse correctly, but would be incorrect markup and is
not advised. The above is a single audio recording named "Track 123".
The above is like writing:

   <div class="vcard">
      <span class="item">
         <span class="fn">Brian Suda</span>
      </span>
   </div>

The above would parse correctly, but it's just weird and hopefully
nobody would use it in that way.

> <!-- and This too? -->
> <div class="haudio">Track 123</div>

Yes, that is correct.

> <!-- Track with album -->
> <div class="haudio">
>   <span class="fn">Track 123</span>
>   <span class="album">Album 123</span>
> </div>

Yes, correct.

> <!-- hAudio is just an album -->
> <div class="haudio">
>   <span class="album">Album 123</span>
> </div>

Yes, correct.

> <!-- 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.

> <!-- now the part we are debating -->
> <!-- hAudio is an album with lots of tracks -->
> <div class="haudio">
>   <span class="album">Album 123</span>
>   <span class="fn">Track 123</span>
>   <span class="fn">Track 456</span>
>   <span class="fn">Track 789</span>
> </div>

We're not debating this... the markup is clear (although, the multiple
FNs are a bit strange). The above is a single audio recording named
"Track 123" that is found on an album named "Album 123".

> Isn't it easier to just create a root class above haudio? i know that
> was discussed and dropped (that was the whole halbum) but now we have
> created (what i think is a confusing mess) of nesting the same element
> in side itself just to avoid making a root class. Or not assume haudio
> by default is a TRACK, but instead just a container.

hAudio by default IS a single audio recording! I think this is your
primary misconception... isn't it?

Please give markup examples of where you think this falls down. It was
very helpful to see how your mental model of hAudio diverged from mine.

-- manu

[1] http://hypem.com/
[2] http://www.scissorkick.com/
[3] http://microformats.org/wiki/audio-info-examples
[4] http://microformats.org/wiki/audio-info-formats