[uf-new] hAudio ITEM/TRACK debate resolution

[Brian Suda]

We are replying to alot at once, so lets break it up, and get down to
only the sticking points.

On 10/21/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> 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.

--- ok, i can agree with this as an idea, and i think we can move to a
better way to mark this up. Below looks more like what i had in mind.

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

--- so far i agree. I think part of the issue was that //haudio/fn is
JUST a string to represent the string not a track title. I can agree
with that. I think the two examples above make sense to me. I would
also press for requiring ATLEAST an FN or ALBUM, not <span
class="haudio">A string</span>. We can discuss this in a later
itteration as an optimization.

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

--- yes, that is fine. FN could be your display-name in something like
Operator, but Album is the name of the title of the album. If you
WANTED these could be the same class="fn album", but to me that
doesn't make any semantic compound. Just that the display name happens
to be the same string as the album.

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

--- i agree with the previous. I don't think there is much arguments
there. The tricky  (IMHO) things happens when we start "nesting".

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

--- correct. To me this makes the most sense. Each "track" has
individual metadata bound by class="item", things outside of that are
assumed to be part of the audio object in general. So far this isn't
really nesting. If we look at hAtom, you can have rel-tag inside a
entry but also a feed, that really isn't nesting, just the ability to
have properies inside and outside of the item.

But as i understand, the ITEM could recursively be more audio-objects.

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

--- i agree, i have been under the assumption that it would have been
a TRACK name, but you are right it should be re-defined as just a
"string" that describes the audio object, which is optional.

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

--- ok, i can agree with this. So we do NOT know this is a TRACK, just
an audio object with a title of some sorts?

Once we all get on the same page here, we can discuss the rest of the message.

-brian

-- 
brian suda
http://suda.co.uk