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 <[EMAIL PROTECTED]> 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 _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
