[uf-new] hAudio/table incompatibility

[Manu Sporny]

Martin McEvoy wrote:
> On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
>> So this simpler proposal makes perfect sense to me.
> 
> at least someone on the list Is starting to make sense.

Criticize the ideas, not the people, please. :)

> I have been wrestling with the current proposal of hAudio since Manu
> made his announcement [1] And frankly the current proposal is starting
> to make less and less sense to me,  With each different proposal the
> concept of hAudio gets more and more vague. and honestly I dont like it
> at all the way hAudio stands now.
> 
> What happened to keep it Simple, and *Meaningful*?

We are attempting to keep it simple... remember, if we don't have ALBUM
and TRACK - we have to have the hAlbum Microformat. hAlbum is an order
of magnitude more complicated than what is currently being proposed.

What part of the mark-up isn't "meaningful" to you? Please be very
explicit as I'm having a hard time following what part of the hAudio
specification you don't like. Preface your statements with "This
concerns hAudio ISSUE #N..."

> So let Keep it simple eh?
> 
> PROPOSAL:
> 
> <div class="haudio">
>    <span class="audio-title">Album Title</span>
>    <span class="contributor vcard">[...]Artist[...]</span>
>    <div class="track">1
>         <span class="track-title">Track One</span>
>         [...]
>     </div>
>     <div class="track">2
>          <span class="track-title">Track Two</span>
>        [...]
>     </div>
> </div>
> 
> Notice no need to Reiterate hAudio over and over again, hAudio only=20
> needs to be declared *ONCE* because the entire contents *ARE* hAudio

Please take a bit more time to outline your objection more clearly.
Which one of the hAudio ISSUES is this about?

http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables

I'm guessing that you don't like the fact that you must define both
TRACK and HAUDIO?

The reason that we're doing this is because we might want to re-use
TRACK (or whatever we end up calling it) in hVideo.

Content has sections:

Albums have Tracks
Television Series have Episodes
DVDs have Chapters
Books have Chapters

We could end up re-using TRACK to describe DVDs like so:

<div class="hvideo">
...
   <span class="dvd">The Matrix</span>
...
   <span class="track hvideo">Chapter 27: The Lobby</span>
...
   <span class="track haudio">Chinese Audio Track</span>
...
</div>

If we don't specify hvideo for the video track and haudio for the audio
track, how would the parser determine the difference? We would have
ambiguity, which is one of the reasons all of the other Microformats do
this as well.

If you want to push your proposal above, you will have to make the
following arguments:

1. Why Ambiguity is not an issue for TRACK.
2. Why we should introduce a new property called TRACK-TITLE.
3. Why we should require CONTRIBUTOR to be marked up via a VCARD.

> I feel the more we bloat hAudio with *not* well thought of semantic
> class names such as *Album* (a container class or object not a title)

ALBUM is not a container class, it defines two things:

- the name of an audio album
- the type of the hAudio

The examples require us to have something like this, so is your
opposition to it's name... or the concept that we need something to
denote the name and type of an hAudio?

> and *Podcast* (which is also a container class and not a title) the
> less 

PODCAST will probably not make it in unless somebody other than me
starts supporting it.

Let me point out that we have plenty of podcast examples:

http://microformats.org/wiki/audio-info-examples#Music_Podcasting

I'd like hAudio to be completed sooner than later and if PODCAST is
going to cause push-back, then I'd much rather drop it and move on...
even though we have a number of examples to support putting podcast in
hAudio.

-- manu