[uf-new] hAudio ITEM/TRACK debate resolution

[Manu Sporny]

Brian Suda wrote:
> On 10/21/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
>> - 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.
> 
> --- i agree with these two points

I think we agree on, or can compromise towards, much more than I thought
at the beginning of this conversation. Let me state what hAudio is, just
so that we're clear:

hAudio is used to mark up an audio recording. An audio recording is a
re-playable series of sounds that are made by something.

That is the definition of hAudio, it is not any more specific than that.
What gives hAudio its specificity is the attributes that go inside hAudio.

For example, if nothing goes inside hAudio other than FN, it is the name
of the audio recording:

   <div class="haudio">
      <span class="fn">A Sound Recording</span>
   </div>

If somebody wants to be more specific and mark up an album, they can do
the following (leaving out FN - using your proposal, Brian):

   <div class="haudio">
      <span class="album">An Audio Album</span>
   </div>

If somebody wants to be even more specific and mark up an audio
recording that is a part of an album, they can do this:

   <div class="haudio">
      <span class="fn">A Sound Recording</span> found in
      <span class="album">An Audio Album</span>
   </div>

All three examples above are audio recordings. An album can have
sections, but played from beginning to end, it is still an audio
recording. It should also be noted that we are required to provide at
least the functionality shown above - the examples are very clear on this.

In addition to the above, we are also required to be able to list albums
and tracks. I think the following markup is what you would prefer, right
Brian?

   <div class="haudio">
      <span class="fn">A Sound Recording</span> found in
      <span class="album">An Audio Album</span>
      <div class="item">
         <span class="fn">Track 1</span>
         <abbr class="duration" title="PT2M32S">2:32</abbr>
      </div>
      <div class="item">
         <span class="fn">Track 2</span>
         <abbr class="duration" title="PT3M11S">3:11</abbr>
      </div>
   </div>

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

We should probably stop using "track name" - it seems to be causing
confusion. Use "audio recording" instead. We aren't as specific as a
track using that markup.... all we know is that it is an audio
recording... we don't know if it is an album and we don't know if it is
a track, nor do we know if it is a podcast. We don't know anything other
than it is an audio recording.

> //haudio/fn == track name

We still only know the name of the audio recording, nothing else. It is
definitely not a track at this point.

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

Again, we don't know that it is a track unless ALBUM is also specified
in that structure. Only then can we assume that the audio recording
listed under ITEM is a track. If ALBUM is not specified, it is just a
part of the audio recording. For example:

   <div class="haudio">
      <span class="fn">A Sound Recording</span> -
      <div class="item">
         <span class="fn">A Part</span>
      </div>
      <div class="item">
         <span class="fn">Another Part</span>
      </div>
   </div>

"A Part" and "Another Part" are just two sections (which are audio
recordings) of the audio recording "A Sound Recording".

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

Yes it could. I had proposed that approach during the last two weeks. It
didn't go over well, check the archives... I think Scott had issues with
it. Scott?

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

We would be going against the examples if we were to do that.

>> Why is attempting to do something that no other microformat does a bad
>> thing?
> 
> --- it isn't, but the concept of NESTING isn't new, hAtom does this.
> What is new and bad is nesting the same property inside itself. Which
> is what this whole class='item haudio" is doing.

Why is nesting the same property inside itself a bad thing?

>> It is true that no other Microformat does
>> sections/collections/parts.
> 
> --- i think you proved your point right there, you have 3 distinct
> levels. But in your mark-up you are saying haudio/item+haudio (that is
> NOT three distinct things)

Wait... I proved my point, or I proved your point?! :) I'm so confused.
I didn't mean to imply that sections/collections/parts were three
different levels - they are three different words that mean the same
thing in hAudio. Does it help if I re-state the problem like so:

We are attempting to create two concepts:

* a single, non-descript recording (audio recording)
* a single, descriptive recording with multiple sections/parts (still an
  audio recording, but specifically an album containing tracks)

> "First, let me state that hAudio is about "audio recordings", of which
> tracks and albums are a subset."
> 
> There is no SUBSET here, it is ONLY hAudio.

Hmm... my definition of subset seems to be different than your
definition of subset. There is only hAudio, yes. hAudio is an audio
recording. An album is a type of audio recording. A track is a type of
audio recording. An album with multiple tracks is a type of audio recording.

In other words - we're talking about an audio recording.

> --- fine, but 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. OR always have ITEM so
> haudio stays the generic container and contains SUBSETS of multiple
> other things (namely tracks)

Why do we need this? Why can't the contents of hAudio define the type of
audio recording that it is?

>>> <!-- 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?
> hAudio is about tracks and Albums correct? then if that is metadata
> about an haudio item and it is only a album, right? or is it the fact
> that it is in an ITEM that causes the problem?

ITEM causes the issue. You wouldn't need it - it is superfluous. I
shouldn't have used the word "incorrect", what I meant was
"superfluous". What were you trying to do with the markup above?

>> hAudio by default IS a single audio recording! I think this is your
>> primary misconception... isn't it?
> 
> --- 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:
> <span class="haudio">
>   <span class="fn album">Best Before 1984</span>
>   <span class="contributor">Crass</span>
>   <span class="item haudio">
>      <span class="fn">Hokkaido Dream</span>
>      <abbr class="duration" title="PT3M24S">3:24</abbr>
>   </span>
>   <span class="item haudio">
>      <span class="fn">Tokyo Groove</span>
>      <abbr class="duration" title="PT4M46S">4:46</abbr>
>   </span>
> </span>
> 
> The class="item haudio" is a poor design choice.

Then we can use item... although, I think Scott has something to say
about that. I agree with Scott's take on it.

> hAudio is NOT by default a track or an album, it is a container. 

I disagree. hAudio by default is an audio recording... nothing more.

> Then
> we do NOT have to do any sort of nesting of itself and complicated
> things.

Why is this viewed as complicated, and nesting hCard in hReview not seen
as complicated? See Scott's comments...

-- manu