[uf-new] hAudio ITEM/TRACK debate resolution

[Brian Suda]

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, 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.
>From the descriptions i am hearing, the property "haudio" is 2
different thing. IMHO it should only be 1, a generic container for
audio.

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

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

The reason you think you NEED class="fn album" is because of your
"short-cuts". 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"

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

But instead haudio is attempting
//haudio == track name
//haudio/fn == track name
//haudio/item/fn == track name
//haudio/album+fn == album name (i don't understand this, it could
just be //haudio//album)

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.

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

--- i think that might have been a mis-communication. I disliked the
property name ALBUM, i am not debating the merit of its existance.

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

--- then this is two different things. With hAtom we solved the atom
ENTRY, then put it in a FEED. If we have solved the atomic RECORDING,
then we are putting it into a COLLECTION (or ALBUM) this is a level
above hAudio. The original examples where making (what i think is a
poor use) of class="item haudio" in a class="haudio", but i see what
you are attempting.

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

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

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

--- i disagree with this idea. Firstly, it is a premature
optimization. Secondly, haudio is no longer a generic container, it is
now a TRACK. Which goes against what you said at the begining of your
email.

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

A subset would be //haudio/SUBSET HERE (item in all the examples)/value

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

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

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

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

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

The above is an haudio which is a generic container. We are now
nesting generic contains inside itself. There is no need. We can drop
the class="item haudio" to simply class="item". Then we are the exact
model as hAtom. hFeed==hAudio, hEntry==item then we can add metadata
about the container (be it album, duration, etc as optional), then it
can have multiple tracks (optional) as items.

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. If you wanted to write JUST an album it would be:

<span class="haudio">
   <span class="album">Best Before 1984</span>
</span>

No optimizations YET.

hAudio is NOT by default a track or an album, it is a container. Then
we do NOT have to do any sort of nesting of itself and complicated
things.

Other than that, nothing changes. It is just cutting out the
short-forms (for now) and making the overall mark-up easier by not
having to nest weird structures inside itself. It also makes haudio a
generic container NOT a track by default. I think haudio should be 1
thing and 1 thing only. How and what we decide that too be impacts the
rest of our choices.

-- brian

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