<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On Jun 8, 2007, at 4:26 PM, Joe Andrieu wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV>Actually, this is a perfect example why hidden data is problematic. I actually think the outright prohibition on it is too strict,</DIV><DIV>but as a general rule, it tends to cause problems.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>There's not really an outright prohibition on the title attribute. We use it in the abbr design pattern, for example:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><A href="http://microformats.org/wiki/abbr-design-pattern">http://microformats.org/wiki/abbr-design-pattern</A></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>But there is a knee-jerk reaction against it because we want to maximize the visibility of content, because that's where microformats are really unique, in using already human-visible content as machine data. The more we make it invisible, the more we might as well be using RDF, which is not to say that RDF is always bad, just that a diversity of options is good, so we should emphasize what makes microformats unique, e.g. visible data.</DIV><BR><BLOCKQUOTE type="cite"><DIV>I've always been puzzled by the anti-namespace and non-scoping arguments.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>For me, they boil down to what I said above: emphasize what makes microformats different (e.g. lack of namespaces) from other formats to give publishers the most alternatives.</DIV><BR><BLOCKQUOTE type="cite"><DIV>The world is probably too rich to suitably represent good</DIV><DIV>names without one or the other approach. If "audio-title" or "audiotitle" violates namespace principles here, then I think we are</DIV><DIV>seriously hitting one of the scaling problems of uF.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>In many ways, we are, and that's okay (in my view, of course -- others certainly disagree). RDF can scale while microformats ease the learning curve to a more data-rich web. But we also have profile URIs available to accomplish much of what namespaces accomplish, and we're not really taking advantage of those now:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><A href="http://microformats.org/wiki/profile-uris">http://microformats.org/wiki/profile-uris</A></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I doubt we'll ever focus heavily on profile URIs until someone else develops a popular alternative use of class names that conflicts with microformats, just because this is a community founded around solving the most obvious problems first, and that's what it will take to make disambiguation an obvious problem.</DIV><BR><BLOCKQUOTE type="cite"><DIV>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</DIV><DIV>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?</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>In some ways scalability and ease-of-use are mutually exclusive, and microformats are in the ease-of-use camp. In this case, it's easier to assume a given class name always means the same thing, so that's what microformats let publishers do. When publishers run into a situation where they absolutely need namespaces, then they can always move to RDF. But if microformats were to become more like RDF, then understanding namespaces would become a prerequisite to publishing machine-readable data on the web, which would result in fewer publishers doing so. I would use a metaphor of microformats as training wheels for web-based data publishing. When publishers start to get tired of the training wheels, they can take them off their own bike and start using RDF. But banishing training wheels in general is not helpful to other beginners. And right now the web is full of data-publishing beginners.</DIV><BR><BLOCKQUOTE type="cite"><DIV>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</DIV><DIV>hint of something in the water. Virtually all media have titles. In fact, the working schema for hCitation also has this problem[1].</DIV><DIV><BR></DIV><DIV>[1] <A href="http://microformats.org/wiki/citation-brainstorming">http://microformats.org/wiki/citation-brainstorming</A> </DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Right, so ideally we would choose a term specific enough to have a clear meaning in the context of hAudio, but general enough to also be usable in future microformats. And looking to previous microformats is a good way to find such a term, because if it works in both another microformat and hAudio, it probably has a good balance of specificity and re-usability.</DIV><BR><BLOCKQUOTE type="cite"><DIV>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</DIV><DIV>for it?</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Joe already seems to know the answer to this question, but for those new to this issue, consider this:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><div class="haudio"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN><span class="title">Purple Haze</span> by</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN><span class="hcard"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN><span class="fn">Jimi Hendrix</span>, <span class="title">musical legend</span></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN></span></DIV><DIV></div></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The problem comes when trying to determine the title of this hAudio. How do we know if it's "Purple Haze" or "musical legend"? We could tell parsers to ignore hCards, but that requires parsers to be aware of not only the microformat they're parsing, but also any other microformat that might include the same property names, some of which may not exist until after the parser is written. I don't believe this is an impossible problem to solve, but as Brian said, it is a difficult problem. When faced with the option of solving this difficult problem or choosing a different name and moving on, I expect most people interested in hAudio will opt to just choose a different name. Repeat that over every microformat, and you get where we are now.</DIV><BR><BLOCKQUOTE type="cite"><DIV>I believe the answer is that because existing parsers would have to be constantly updated to handle new uFs contained therein. In</DIV><DIV>other words, hCard parsers would have to be re-written to handle contained hAudios. Am I following that argument correctly?</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Pretty much. With "title," there's also an argument that we should neither use the same term to mean different things nor change the meaning of terms in already-published microformats. I expect even slightly expanding the meaning of a term in a microformat published as widely as hCard would be an uphill battle.</DIV><BR><BLOCKQUOTE type="cite"><DIV>If so, I don't quite understand the problem because hCard's don't contain hAudio. Or can they? </DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>They could. My hCard is here:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><A href="http://typewriting.org/about/scott/">http://typewriting.org/about/scott/</A></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If you look at the source of that page, you'll see the hCard covers almost the entire page, because my name is at the top and my birthday is at the bottom. If I wanted to list my favorite song on that page, as I've previously done, I couldn't do it in hAudio without risking the song title would become my job title, as long as there are no rules to prevent that. This is still an edge case, but it's an edge case that grows exponentially every time we re-use an existing class name in a new microformat.</DIV><BR><BLOCKQUOTE type="cite"><DIV>Is there some way to embed arbitrary content into an hCard and have it actually be logically or semantically /embedded/ in the</DIV><DIV>hCard? I know you can do it presentationally so it displays the data. But does the hCard data model have a place for arbitrary</DIV><DIV>embedded content? If so, couldn't the parser simply ignore the children of that field when parsing for "title"?</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Notes, maybe. Ideally someone would be able to include an hAudio inside the node of an hCard without influencing the hCard at all. Also, it would be nice if there were a general solution that worked on any microformat embedded in any other. That's generally where this seems to be headed:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><A href="http://microformats.org/wiki/mfo">http://microformats.org/wiki/mfo</A></DIV></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The idea there seems to be that the included hAudio could have the "mfo" class added, e.g. class="haudio mfo" and that would indicate to any hCard parsers that they should ignore that section the surrounding hCard. The same would work for embedding hAudio in hReview if we decided to re-use summary, or with embedding hAudio in hAtom if we re-used entry-title. But there are several issues with that idea, and I haven't seen much interest in discussing it further.</DIV><BR><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>--</DIV><DIV>Scott Reynen</DIV><DIV>MakeDataMakeSense.com</DIV></SPAN></SPAN><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>