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

[Joe Andrieu]

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.

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.

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?  

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"?

-j

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe at switchbook.com
+1 (805) 705-8651