[uf-new] title vs. summary (was: Third attempt at hAudio)
martin at weborganics.co.uk
Fri Jun 8 16:28:17 PDT 2007
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..
Rainy Day Women #12 & 35
<dfn>Blonde on Blonde</dfn>
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.
>  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
> Joe Andrieu
> SwitchBook Software
> joe at switchbook.com
> +1 (805) 705-8651
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070609/343ea386/smime.bin
More information about the microformats-new