> Of Martin McEvoy wrote: > On Fri, 2007-06-15 at 23:10 +0100, Martin McEvoy wrote: > > On Fri, 2007-06-15 at 16:02 -0500, David Janes wrote: > > > On 6/15/07, Manu Sporny <[EMAIL PROTECTED]> wrote: > > > > * Adopted 'audio-title' to specify the title of the recording > > > > > > Sorry to bring up this sore point, but why "audio-title" > over "fn"? > > > I did see your feedback a couple of days ago about the > concepts of > > > "audio-title" being different from "track-title", etc (I can't > > > remember the exact terms, but you get the point). > However, it seems > > > to me that "fn" could be used to represent each of these > _concepts_, > > > as the "fn" will be appropriately nested within identifying > > > containers. > > > > we never did get to the bottom of this it was just left hanging!
As I understand it that problem is that "fn" for the hAudio would be unable to be differentiated from the "fn" for the hCard of a contributor of the hAudio. uF has no scoping. See this email: http://microformats.org/discuss/mail/microformats-new/2007-June/000555.html As I understand it, if we had: <div class="haudio"> <span class="contributor"> <span class="vcard"> <span class="fn org">Phish</span> </span> </span> <span class="fn">Sneaking Sally Thru The Alley</span> <br/> </div> The two "fn" fields would clobber each other. This is a pretty harsh limit on uF, one that I personally think should/could go away by allowing uF containing other uF to know that the contained uF should be excluded from parsing by the parent. However, in the above example, I believe we have a problem if the order is reversed and the hCard includes the hAudio, because hCard is already defined and has no exclusionary principles. This issue is worth tackling, but solving it before we finish hAudio would bring hAudio to a screeching halt for an indeterminate period of time. > > > (2) > > > A little voice in my head says this is more general than audio... > > > > > > > my little voice tells me baaad things but I guess its not a > subject of > > this list... > > ...ok then it is > > do you think that the title of an audio file is always the > same as the actual file itself? The title is not the name of the file. Audio-info does nothing with regard to the mediafile/audiofile that may or may not be associated with the audio except for, potentially, pointing to the file as "rel-enclosure". > or that audio-title refers to both a download-able file or an > album title, ??? This I don't understand. "audio-title" refers to the name/title or the audio piece referred to by the uF. If that piece is an /entire/ album, then that's what it is. Albums that are groupings of multiple individual audio pieces are out of scope (for the moment). The title of the piece has nothing to do with the filename that might be used. > Im having difficulty again understanding how this is > different than either "fn" or "summary" or "whatever" Martin, I don't know how to reply except to ask you to re-read the thread. "fn" is arguably inaccurate and clobbers "fn" from hCard. "summary" is inaccurate for many audio pieces and clobbers "summary" from hReview. "whatever" is semantically meaningless. "audio-title" is specific, accurate, and has no clobber issues with any existing uF. -j -- Joe Andrieu SwitchBook Software http://www.switchbook.com [EMAIL PROTECTED] +1 (805) 705-8651 _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
