On 10/20/07, Scott Reynen <[EMAIL PROTECTED]> wrote: > It's not. The model is almost entirely analogous to hCard: > > hAudio is about audio. > The default type of audio is a track. > If the album and fn are the same, it's the non-default type: an album. > > hCard is about contacts. > The default type of contact is an individual. > If the org and fn are the same, it's the non-default type: an > organization.
--- this is ONLY because FN is required in vCard and making FN==ORG in most PIMs set the type of card as a company not a person. I think people are missing that and assuming that class="fn org" is making the FN a TYPE of ORG, hence class="fn album" attempting to cast FN as ALBUM. (the fn and org can be on completely different elements, as long as their values are the same. That is what counts, not the fact that they share the same class="fn org") Sorry i completely missed the emails about saying when an ALBUM came into existance. If that is so, then FN is NOT needed. I personally don't like ALBUM, because then we get an enumerated list of people's pet projects, PODCAST, ALBUM, COLLECTION, etc, but that is another discussion. If we are going to have a class ALBUM then we do NOT need both FN and ALBUM. > See above. If you still think it's wrong to use hAudio for both > album and track, please explain why you think this should differ from > hCard's model. because hCard doesn't have class="vcard" for the root and class="vcard item" again to specific all the people or orgs that it may contain. I think i agree with you, if i understand your model of the assumption being a track, with an explicit album name. I don't think i agree with having nested types of the same object... a TRACK that has an album, but actually then has multiple tracks inside it... to me that isn't ideal. > Or #3, we could recognize that when the audio's name is the same as > the album's name, the audio is an album, without requiring an > explicit statement from publishers. This solution removes the main > problem with both #1 and #2 above: unnecessary declaration of > containers or items that may not even exist. --- correct. The default is that we are talking about a TRACK (just like in vCard we are talking about a person), BUT if the FN and ALBUM are the same (just like FN and ORG) the object is an ALBUM/ORG. What falls down is that now you are attempting to shove multiple TRACKS/PEOPLE into the same ALBUM/ORG. You can't do this in vCard, so the analogy gets weird. vCard is ever ONLY about 1 object at a time, just like hAudio should be about 1 object at a time, (either a track or an album). Attempting to squeeze multiple things inside should either be out-of-scope or looked at later, we don;t have a format, yet we are attempting something no other microformat does. > > --- right, ORG would be analigous to option #2 where you explicitly > > list the ALBUM. The downside is that if there are 2 track (like 20 > > people) the (ORG or ALBUM) would have to be repeated 20 times. > > Why? HTML nesting semantics already indicate containers. Similarly, > hAtom doesn't repeat the feed 20 times for 20 entries. --- but hAtom isn't nesting hfeed inside itself, it has 1 root class (hfeed) with multple henteries and each hentry does not contain itself over and over again. We have new properties for different object container. > I think the > basic model is to follow hCard for differentiating between container > type and item type, and follow hAtom for relating containers to items. --- sure, but if we do, then we don't need to re-use the same root-class name of haudio to mean both a track and a generic media container. > That's pretty much exactly what everyone's agreed to, except we're > using "album" instead of "collection." If you think this should > change, please explain why. --- i don't really care what it is called, but if we choose ALBUM, then all the podcasters complain, if we choose ALBUM then all the people who release it in another format complain... just look at the suggestions on the issues list: http://microformats.org/wiki/audio-info-issues#Collection_Names +1 for using ALBUM ManuSporny 09:31, 12 Sep 2007 (PDT) +1 for using PODCAST ManuSporny 09:54, 12 Sep 2007 (PDT) +1 for using TRACK ManuSporny 09:54, 12 Sep 2007 (PDT) +1 for using TRACK Chris Newell 12:21, 25 Sep 2007 (GMT+1) +1 for using CHART Chris Newell 12:21, 25 Sep 2007 (GMT+1) +1 for using PLAYLIST Chris Newell 12:21, 25 Sep 2007 (GMT+1) +1 for using RELEASE Michael Smethurst, 12 Sep 2007 Dublin Core uses COLLECTION: http://dublincore.org/documents/dcmi-type-vocabulary/ we can discuss the exact name later - lets not get hung-up on that. I think we both agree that something unique is needed if we are going to model this similar to hCard. > We've been talking about something more like this: > > <span class="haudio"> > <span class="album fn">Best Before 1984</span> > <span class="contributor">Crass</span> > > <span class="item"> > <span class="fn">Hokkaido Dream</span> > <abbr class="duration" title="PT3M24S">3:24</abbr> > </span> > > <span class="item"> > <span class="fn">Tokyo Groove</span> > <abbr class="duration" title="PT4M46S">4:46</abbr> > </span> > </span> --- that is fine, but i then have a few issues. To me, that is NOT describing a TRACK by default. hAudio is now just a generic container for MEDIA data. with some metadata and items. I gather from the next statement that you NEED to type cast those ITEMS because your assumption that this is by default a track, but it is now wrong because the FN and ALBUM are present, so we are talking about an album, but you still want multiple ITEMS inside this (what was a track) but is now an Album. The root class of haudio on the items to now making it be a track, so we need to re-state that these items are tracks by default hence class="item haudio"... that sounds pretty complicated to me and nothing like hCard or hAtom. > Your proposal does not share this assumption, > and I'm still not sure if that's because you see something wrong with > it, or you just didn't understand it before. If the former, please > explain. If the latter, I hope it's clear now. --- at first i didn't understand it, now that (i think) i do, i like it even less. > hAudio models audio, which includes both tracks and albums. > Similarly, hCard models contacts, which includes both people and > organizations. --- hCard models 1 org or 1 person. hAudio is attempting to model 1 track or 1 album or 1 album with multiple tracks. This last part is my hang-up, both in communication and in mark-up. > It could be, but I think it's simpler to use HTML's existing > containment semantics, as hAtom does. --- probably, but hAtom doesn't reuse hFeed or hentry inside elements of the same type. OK, so it seems that hAudio wants to model 3 different things. The first two seem pretty close to being solved. Just for my own sanity let me rehash it. <!-- This is a TRACK and ONLY a track --> <div class="haudio"> <span class="fn">Track 123</span> </div> <!-- This is a TRACK with some metadata --> <div class="haudio"> <span class="item"> <span class="fn">Track 123</span> <abbr class="duration" title="PT3M24S">3:24</abbr> </span> </div> <!-- if haudio is TRACK by default, then there is no need to have "item" here, right?--> <div class="haudio"> <span class="fn">Track 123</span> <abbr class="duration" title="PT3M24S">3:24</abbr> </div> <!-- But This is also a only TRACK? --> <div class="haudio"> <span class="item"> <span class="fn">Track 123</span> </span> </div> <!-- and This too? --> <div class="haudio">Track 123</div> <!-- Track with album --> <div class="haudio"> <span class="fn">Track 123</span> <span class="album">Album 123</span> </div> <!-- hAudio is just an album --> <div class="haudio"> <span class="album">Album 123</span> </div> <!-- what is this? an album with a duration, or an un-named track in an album with a track duration? --> <div class="haudio"> <span class="item"> <span class="album">Album 123</span> <abbr class="duration" title="PT30M24S">30:24</abbr> </span> </div> <!-- now the part we are debating --> <!-- hAudio is an album with lots of tracks --> <div class="haudio"> <span class="album">Album 123</span> <span class="fn">Track 123</span> <span class="fn">Track 456</span> <span class="fn">Track 789</span> </div> That last example is where things get abit weird depending on what you want to do. now we have 1 container, haudio, that we are attempting to stick multiple ITEMS into. In hAtom, we have a root of hFeed that contains multiple entries. What the current haudio proposal is suggesting to me is that haudio is more like each hentry (normally just a track) but when we want it to contain multiple things then we are going to say hentery now is like hfeed when other hentries are inside it. Isn't it easier to just create a root class above haudio? i know that was discussed and dropped (that was the whole halbum) but now we have created (what i think is a confusing mess) of nesting the same element in side itself just to avoid making a root class. Or not assume haudio by default is a TRACK, but instead just a container. am i missing something or is that what has happened? This last aspect is nothing like hCard or hAtom. If we are going to say that an hAudio can contain multiple tracks, then (IMHO) BY DEFAULT audio should be an empty container. Just like hFeed is an empty container. These then get multple items put inside them. <div class="hfeed">entry title</div> this isn't assumed to be an entry with a title of "entry title", but that is exactly what is happening with <div class="haudio">track name</div> we have foregone the middle parts that make this an ITEM that can be contained multuple times inside the container. then we run into problems when we need it to represent multiple things. hAtom doesn't have class="item hfeed" (it has hentry instead), which is what class="item haudio" is trying doing to represent tracks. sorry if i missed those discussions, but this just seems wrong to me. If we want 1 haudio object with 1 album and multuple tracks, then it should be designed like hAtom. If we want to talk about a single hAudio object, then we can model it after hCard where it is 1 track or 1 album at a time. -brian -- brian suda http://suda.co.uk _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
