[uf-new] title vs. summary (was: Third attempt at hAudio)

[Martin McEvoy]

On Fri, 2007-06-08 at 15:26 -0700, Joe Andrieu wrote:
> Martin McEvoy wrote:
> > On Fri, 2007-06-08 at 21:57 +0100, Martin McEvoy wrote:
> > > <div class="haudio">
> > > <span class="summary" title="Blonde on Blonde">
> > > Rainy Day Women #12 & 35
> > > </span>
> > > </div>
> > 
> > OOPs caught me copy and pasting.
> > 
> > <div class="haudio">
> > <span class="summary" title="Rainy Day Women #12 & 35">
> > Rainy Day Women #12 & 35
> > </span>
> > </div>
> 
> 
> Actually, this is a perfect example why hidden data is problematic. I actually think the outright prohibition on it is too strict,
> but as a general rule, it tends to cause problems.
> 
> Namely that it is easy for errors to creep in, and to do so in a way that avoids human visual checks that are critical to quality
> control on any data set.  
> 
> This is even worse when you are duplicating data (a problem on its own), because copy & paste & edit will often miss one or the
> other. I've done this many times with HTML for example, where I c&p a template, cycle through and update it to each sections new
> data, but almost inevitably, I miss one edit or another.

you have made a good point duplicating data! and really it doesn't make
much sense does it?

back to this then..

<div class="haudio">
<span class="summary">
Rainy Day Women #12 & 35
</span>
</div>

and 

<div class="haudio">
<dfn>Blonde on Blonde</dfn>
</div>

for a defining instance of hAudio 
I have ommited summary because that too didn't make much sense a
defining term inside a summary? 

> 
> Which is all to say that we should do what we can to avoid approaches that /systematically/ induce these types of human error.
> 
> I've always been puzzled by the anti-namespace and non-scoping arguments.  The world is probably too rich to suitably represent good
> names without one or the other approach. If "audio-title" or "audiotitle" violates namespace principles here, then I think we are
> seriously hitting one of the scaling problems of uF.

we are indeed hitting a brick wall

> 
> Of course, it has been argued that uF isn't supposed to scale and perhaps this is one of those areas where the namespace and scoping
> principles induce a boundary on scale.  If that's really the point we are at, can someone explain why this is a good thing again?
> 
> Because, it is clear to me that "title" is just the tip of the iceburg on this problem, and in fact "audio-title" is really just the
> hint of something in the water. Virtually all media have titles. In fact, the working schema for hCitation also has this problem[1].
> 
> [1] http://microformats.org/wiki/citation-brainstorming 
> 
> 
> So, to clarify how we got to this point, why can't "title" be bound to the semantics of the first parent container to have a rule
> for it?
> 
> I believe the answer is that because existing parsers would have to be constantly updated to handle new uFs contained therein. In
> other words, hCard parsers would have to be re-written to handle contained hAudios. Am I following that argument correctly?  If so,
> I don't quite understand the problem because hCard's don't contain hAudio. Or can they? 

No I don't think they can

>  
> 
> Is there some way to embed arbitrary content into an hCard and have it actually be logically or semantically /embedded/ in the
> hCard? I know you can do it presentationally so it displays the data. But does the hCard data model have a place for arbitrary
> embedded content? If so, couldn't the parser simply ignore the children of that field when parsing for "title"?

now that is a question for someone with a little more understanding than
me.

-Martin-
> 
> -j
> 
> --
> Joe Andrieu
> SwitchBook Software
> http://www.switchbook.com
> joe at switchbook.com
> +1 (805) 705-8651 
> 
-------------- 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/20070609/343ea386/smime.bin