[uf-new] hAudio/table incompatibility

Sat Oct 6 04:31:12 PDT 2007

On Sat, 2007-10-06 at 11:49 +0100, Martin McEvoy wrote:
> 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.

Oh And thanks for Quoting me out of context..

http://microformats.org/discuss/mail/microformats-new/2007-October/000958.html

> > 
> > 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?
> 
> 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
> > 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.
> 
> 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 
>   track
>     haudio
> 
> ? 
> 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?
> 
> http://microformats.org/wiki/audio-info-issues
> 
> First I notice that you have dropped the audio-title property?
> 
> http://microformats.org/wiki/audio-info-issues#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?
> 
> http://microformats.org/wiki/audio-album-proposal#hAlbum
> http://microformats.org/wiki/audio-album-proposal#Simple_Album_Example
> 
> 
> > 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 
> 
> http://wiki.digitalbazaar.com/en/HAudio_RDFa
> 
> which you have said yourself is more useful than the Microformat
> Proposal
> 
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0017.html
> 
> Thanks
> 
> Martin
> > 
> > -- manu
> > 
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new at microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new