<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Aug 29, 2008 at 2:33 PM, Ben Adida <span dir="ltr"><<a href="mailto:ben@adida.net">ben@adida.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I'm going to keep my answer somewhat brief because Manu and I have<br>
privately discussed wrapping up this thread so we don't take up too much<br>
of people's time. I'll focus on simple points.<br>
<div class="Ih2E3d"><br>
> (Note: I've been discussing just such a CSS-like rdf format with Ben<br>
> offlist, inspired directly by Eduard's proposal earlier.)<br>
<br>
</div>I think this idea is interesting, but I don't think it can be made to<br>
work until we get the basic RDFa stuff actually working inline.<br>
<br>
The comparison to CSS is not quite right: with this new proposal, you<br>
have to first map your HTML to local semantic concepts, then map those<br>
local concepts to global semantic concepts. That's quite a bit more<br>
complicated for the average user, and it's not the same at all as the<br>
separation of presentation that is the huge CSS win.<br>
<br>
There is some benefit for folks who are presenting a lot of content in a<br>
consistent way.... in other words folks who already have some kind of<br>
templating engine and who can easily do RDFa in the first place.<br>
<br>
For folks who have ad-hoc HTML, this is more complicated.<br>
<br>
So, like I said, interesting, but I think only a small benefit for large<br>
publishers, and a significant downside for small publishers. All in all,<br>
for Creative Commons, for example, this is not as good.<br>
<font color="#888888"><br>
-Ben</font></blockquote><div><br>Hmm. It *sounds* like you're arguing that for small authors crdf (or some similar external meta categorization) is too complex, and for large authors it's unnecessary because they have templating engines to insert the rdfa for them.<br>
<br>Is this approximately your intended message? If so, then how do you square this with the plain-to-see usefulness and heavy adoption of CSS? Small authors appreciate the clean aesthetics and easy edittability it gives to their hand-crafted code, and large authors appreciate the reduction in page weight from it's declare-once-use-everywhere nature. Of course, once upon a time small authors didn't understand CSS, and templating engines can chug out table-based layouts as easily as anything else. I'm sure this exact argument was used against CSS at the time as well.<br>
<br>I also feel the comparison to CSS is quite exact - with CSS you have to first map your html to semantic categories, and then map those categories to presentional settings. All crdf changes is that you're mapping the semantic categories to external metadata categories. There's a hidden benefit that relatively often you'll be able to reuse the semantic categories for both purposes.<br>
<br>Again, I see the benefit of an inline metadata solution, the same as I see the benefit of inline @style. I just think that it's something that many of us authors will reject almost automatically in our own coding for the same reasons that we reject inline @style and use <style> blocks or external css instead.<br>
<br>You want rdf in html5. Fine, that's great, many of us are open to discussion on this. I'm just trying to get you to realize that there are *very good reasons* to reject RDFa initially and only let it in as an alternate metadata syntax for edge cases like non-savvy authors needing metadata, or machine production of metadata. The web authoring community has cleaned house in our pages in many ways. We've moved style data to external CSS and moved behavior data to external JS. Why is it so hard to believe that we don't want to repeat that process with meta data, and would rather start with it outside?<br>
<br>~TJ<br></div></div></div>