[uf-new] [hAudio] fn _or_ album

[Martin McEvoy]

On Sat, 2007-11-03 at 22:54 -0600, Scott Reynen wrote:
> On Nov 3, 2007, at 10:14 PM, Martin McEvoy wrote:
> 
> > You were a solid supporter of using "audio-title" and helped make the
> > decision NOT to use FN
> 
> That's not true.  I think you have the order of events confused.
> 
> > "...We can't both re-use property names and ignore
> > the context of those property names.  My dog's FN is not my FN, and
> > if the only way for me to make that clear is to use class="pet-name"
> > instead of FN, that's what will happen."
> >
> > http://microformats.org/discuss/mail/microformats-new/2007-June/000581.html
> >
> > ?
> >
> > What changed your mind ?, this was the statement that made us  
> > support the use of "audio-title"
> 
> Nothing changed my mind.  I was not at all arguing against FN there,  
> rather for the awareness of context that is necessary to use FN with  
> embedded microformats.  And I was arguing for that *after* FN was  
> already discarded, because I thought it was unfortunate we had  
> discarded FN rather than solving the context problem.

Right, the thought at the time was that "fn" was being delivered out of
context, so it was better to use "audio-title" which was at the time the
only other proposition we had.

This sounds like I am evangelizing the use of "audio-title", I am not
however, I like the use of FN but I am concerned that it is being
delivered incorrectly and out of context. 

we are adopting the use of "fn" directly from hCard which on its own as
hAudio uses it (outside of a hCard and not within an Item), Is a first
case usage scenario, which basicly means that we are re-using "fn" in a
different context as previously defined in hCard and
http://www.ietf.org/rfc/rfc2426.txt.

Truthfully Scott more discussion was needed about the adoption of "fn
album" before any such changes were made, Its such an important element
within hAudio that it has to be clear in what this means. I WAS going to
start supporting that we create a new Very Much needed Microformat in
the absence of a "title" microformat, 

class="subject" 

which would have made hAudio look like this:

<div class="haudio">
   <span class="item"
   <span class="fn">Start Wearing Purple</span>
   </span> by 
   <span class="contributor">Gogol Bordello</span>
   found on
   <span class="subject">Underdog World Strike</span>
</div>

original example 
http://microformats.org/wiki/audio-info-proposal#Song_and_Album_Example

I think It may have been better to set the subject of an hAudio object
other than try to set a type by using "fn album" which is not setting
the hAudio type at all, just setting the type of "fn" within the hAudio
object.

Any way we will have to see what happens maybe more feedback from the
wiki, will help lay to rest the problems that exist by using the "fn
album" formula.

Thanks

Martin
> 
> Right now the necessary context is explicitly written into hAudio ITEM  
> ("The element must be processed opaquely").  It still doesn't exist in  
> other microformats, but the general consensus (arrived at on the -dev  
> list despite my protest that it's more than a parsing issue) was that  
> we shouldn't address this until it becomes a more widespread (and thus  
> better documented) problem.  Maybe it will never become a bigger  
> problem, or maybe hAudio will force the issue.  Either way, I'm for  
> solving this problem with more explicit context rather than inventing  
> new synonymous class names (e.g. audio-title) as a means of working  
> around it.
> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new at microformats.org
> http://microformats.org/mailman/listinfo/microformats-new