[uf-new] hAudio/table incompatibility

Martin McEvoy martin at weborganics.co.uk
Sat Oct 6 03:49:43 PDT 2007

On Fri, 2007-10-05 at 16:08 -0400, Manu Sporny wrote:
> 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?
> > 
> > 
> > <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?

all the general hAudio proposal....

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

It is an ambiguity when you couple it with another instance of hAudio 
, it shouldn't I cause such confusions I don't think. TRACK should be
clearly defined as a child element of hAudio for it to contain hAudio
seems confusing an unnecessary:


hAudio inside hAudio ?...  

> 2. Why we should introduce a new property called TRACK-TITLE.

You Have proposed 

recording, album, track, podcast,  position and  description

5 new properties ONE reused from hAlbum *Track* the rest !!! 

You decided from the Issues page I Hope?


First I notice that you have dropped the audio-title property?


Only YOU made a vote for changing the current propsal which clearly
means to me that only you had an issue with this?
 +1 : use RECORDING and ALBUM ManuSporny 18:20, 27 Sep 2007 (PDT)

My Proposal Suggests We Keep it I voted Against changing it 
-1 : don't change audio-title Martin McEvoy 15:48, 14 Aug 2007 (GMT)

David Janes voted also on this issue
+1 for using FN, no clear difference between two so why invent another
David Janes 14 August 2007

I would take that as a vote against or changing it entirely

My view would be from the *Three* votes we had that this was really a
*NON ISSUE* but you changed it any way to reflect your views?
> 3. Why we should require CONTRIBUTOR to be marked up via a VCARD.

It Doesn't Just a recomendation as per the hAudio Spec.

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

In your view It Isn't..

In my View IT IS
You re used the already discovered meaning of hAlbum I Presume?


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

I propose You change the hAudio Proposal back to the 0.6 version UNTILL
these ISSUES have been resolved YOU cant Just change the proposal to
reflect your personal views..

Manu you didnt even notify the list that you were making these changes
untill AFTER the changes were made.

Frankly I resent the way you are seeming to bully this community into
fiting into hAudio RDFa agenda 


which you have said yourself is more useful than the Microformat



> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new at microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

More information about the microformats-new mailing list