[uf-new] hAudio ISSUE #8: hAlbum is redundant
Julian Stahnke
julian at julianstahnke.com
Fri Sep 28 13:20:55 PDT 2007
I like how the format is coming together, but have two questions.
Firstly, when looking at the complete album example markup, I
wondered why haudio needs to be nested in track. Could those two
things maybe be the same element? Like so:
<li class="track haudio">...
instead of having to write <li class="track"><span class="haudio">
which seems slightly bloated to me, especially considering hCalendar
allows for this format with location and hCard (as seen here: http://
microformats.org/wiki/hcalendar-location-hcard-example).
The same could be done for contributer and hCard, do they really need
to be nested or could those two classnames be on the same element?
Secondly, is there any means of marking up *just* an artist? I guess
that might be out of the scope of the haudio microformat, but it
would be quite important to have this possibility. There certainly
are pages out there who only mention an artist without naming any
specific tracks, and the role property of hCard seems not very
suitable for that task as very few people would write—in a blog post,
for example—‘the artist so-and-so’.
I’m sorry if the second thing doesn’t belong in this thread, I’ve
never before used a mailing list. Should I open a separate issue for
this?
—Julian
On 28 Sep 2007, at 8:10pm, Martin McEvoy wrote:
> On Fri, 2007-09-28 at 11:34 -0400, Manu Sporny wrote:
>> Martin McEvoy wrote:
>>> ...listening to
>>> <div class="haudio">
>>> <div class="item">
>>> <span class="media-title">May the Rain</span>
>>> </div>
>>> found on <span class="haudio-title">Paper Tigers</span>
>>> </div>
>>> by...
>>>
>>> *Item* works here as a root class on its own and is used as a
>>> semantic
>>> finger pointing out the interesting or important parts...
>>
>> Sorry Martin, I missed this e-mail for some reason until just now.
>
> No worries:) I had the same problems with one of your posts to the
> list...
>
>> I
>> agree with you in concept, we need /something/ to point out that one
>> haudio is a part of another haudio (containers and items in those
>> containers).
>>
>> We are, however, barred from using 'item' because it was previously
>> defined as this in hReview and we can't change it's definition:
>
> The definition Is perhaps incorrect?
>
> When to take into account that ITEM means something entirely different
> in other cases consider RSS.. millions of feeds synicated all over the
> world in every language all using the same term ITEM
>
> http://cyber.law.harvard.edu/rss/rss.html#hrelementsOfLtitemgt
>
> another example
>
> http://web.resource.org/rss/1.0/modules/audio/
>
> the definition here certainly matches the ITEM definition I am
> proposing
> for hAudio do you think?
>
>>
>> item info. required. fn (url || photo ) | hCard (for person or
>> business)
>> | hCalendar (for event)
>>
>> That means that we cannot put an hAudio in ITEM. Got any other
>> suggestions? The best we've been able to come up with thus far has
>> been
>> TRACK or SECTION.
>>
>>> I am also suggesting parts that can be reused in other media related
>>> uF's, item and media-title.
>
> Just *title* would be great but...we know the story on that one:)
>
>>
>> Again, I agree with you in principle... it's just a matter of word
>> choice. We can re-use TRACK in CDs, albums, and possibly DVDs.
>> However,
>> we can't do that in movies, podcasts, or other container formats.
>> That
>> is why I suggested that we use SECTION instead of TRACK. We can use
>> SECTION in CDs, albums, movies, television episodes, podcasts and
>> other
>> container formats.
>>
>>> hItem technically I would say already exists as a uF on its own
>>> wouldn't
>>> you?
>>
>> Nope, I wouldn't go that far. ITEM does exist, but it already has
>> pre-defined semantics that, while we would like to change,
>> attempting to
>> do so in the past has been disastrous[1].
>
> how about breaking title off from hCard so we can explore title In
> other
> contexts I mean *Title* , and *Item* in the real world has so many
> definitions why hog them up in such a ways that it makes it impossible
> to be used in other uF's ? this seems bad to me!
>
>>
>>>> What about using SECTION instead of TRACK? It could be used in
>>>> hVideo
>>>> and hAudio. SECTION makes sense for albums, podcasts, clips,
>>>> television,
>>>> movies... but doesn't really work for charts or playlists.
>>>
>>> ...how do you summarise section?
>>
>> You could use the proposed DESCRIPTION element, if it is approved
>> and if
>> there is enough evidence for it.
>>
>> http://microformats.org/wiki/audio-info-proposal#Description
>>
>> -- manu
>
> Thanks
>
> Martin_
>
>>
>> [1]http://microformats.org/discuss/mail/microformats-new/2007-June/
>> 000511.html
>> _______________________________________________
>> microformats-new mailing list
>> microformats-new at microformats.org
>> http://microformats.org/mailman/listinfo/microformats-new
>
> _______________________________________________
> microformats-new mailing list
> microformats-new at microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
More information about the microformats-new
mailing list