[uf-new] hAudio - audio-album and audio-podcast

[Martin McEvoy]

On Mon, 2007-06-04 at 20:42 -0600, Scott Reynen wrote: 
> On Jun 4, 2007, at 6:33 PM, Joe Andrieu wrote:
> 
> > The alternative to the above that I thought you were going for was  
> > something like this:
> >
> > halbum
> > 	playlist/XOXO
> > 		haudio
> > 		haudio
> > 		haudio
> > 		haudio
> 
> That makes sense to me.

How so?

example of the proposed method:

halbum
   haudio [album title,contributor,image-summary, duration, payment]
        xoxo
          track 
               haudio [track 1, duration, sample]
          track
               haudio [track 2, duration, sample]
          track
               haudio [track 3 duration, sample]

what doesn't make sense here? guys.

The only possible argument here would be the over use of haudio in xoxo
as it is not strictly necessary if you nested the playlist in a single
hAudio as each <li> is haudio

example:

halbum
   haudio [album title,contributor,image-summary, duration, payment]
        xoxo
          track 
               [track 1, duration, sample]
          track
               [track 2, duration, sample]
          track
               [track 3 duration, sample]

hmm problem here, what if our album has multiple content types not all
albums are just playable music yes? I don't think we would want to nest
hVideo and hImage inside hAudio would we? 
so Now it becomes useful to define which track is music and which is
video or Images.

example:

halbum
   haudio [album title,contributor,image-summary, duration, payment]
        xoxo
          track 
               hvideo [part 1, duration, sample, aspect, fps]
          track
               haudio [part 2, duration, sample]
          track
               haudio [part 3, duration, sample]
          track
               himage [part 4, size, filetype, compression,etc]

> 
> > But then in your example, you did something like this:
> > halbum
> > 	haudio
> > 	playlist/XOXO
> > 		track
> > 			haudio
> > 		track	
> > 			haudio
> > 		track
> > 			haudio
> >
> > That was definitely confusing.
> 
> I was also confused by that.  I spent a while trying to figure out  
> what exactly class="haudio" would mean in this schema, and it looks  
> like haudio has an incredibly generic meaning along the lines of  
> "information about some type of audio" where both albums and tracks  
> are potential types of audio.  

Err No not exactly haudio doesn't have to be playable audio it is also
be just information about an album

example

halbum
   haudio [album title,contributor,image-summary, duration, payment]

maybe you do have a point though in the context of just an album
description hAudio becomes a little redundant as this is indeed nothing
that is Audio just a description of audio maybe this is better:

halbum
   summary [album title,contributor,image-summary, duration, payment]

this would fit into our schemata much more cleanly, Manu did use
<summary> in his original problem solution statement

http://microformats.org/discuss/mail/microformats-new/2007-June/000458.html


halbum
   summary [album title,contributor,image-summary, duration, payment]
        xoxo
          track 
               hvideo [part 1, duration, sample, aspect, fps, etc]
          track
               haudio [part 2, duration, sample]
          track
               haudio [part 3, duration, sample]
          track
               himage [part 4, size, filetype, compression,etc]


> I think that's far too general to be  
> useful.  The container and item labels should be specific enough to  
> make that unnecessary.  If we can't assume class="halbum" refers to  
> audio, I think it's a poor class name and another name should be  
> chosen that clearly indicates the content relates to audio without  
> any need for additional labels like "haudio."

Not when you take into account that hAlbum may contain Audio Video and Images

I think class-halbum is an excellent class name its simple, meaningful
and it uses terms that people already use.

http://www.xspf.org/orig-xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.8

-Martin-
> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new at microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070605/32d6b804/smime.bin