<div dir="ltr">(Note: I've been discussing just such a CSS-like rdf format with Ben offlist, inspired directly by Eduard's proposal earlier.)<br><br><div class="gmail_quote">On Fri, Aug 29, 2008 at 1:09 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;"><div class="Ih2E3d">Greg Houston wrote:<br>
</div><div class="Ih2E3d">> My suggestion keeps the metadata code tidy, and more human readable.<br>
> Sprawling out all the different metadata properties just makes a huge<br>
> mess of the markup.<br>
<br>
</div>I understand how it would seem messy the first few times you look at it,<br>
but I'm having trouble seeing how your proposal is any less messy. If<br>
you want a lot of metadata, you've got a lot of markup. "Messy" is<br>
subjective.<br>
<div class="Ih2E3d"><br>
> This sort of mess isn't acceptable to me:<br>
><br>
> <div class="vcard" id="weborganics"<br>
> xmlns:foaf="<a href="http://xmlns.com/foaf/0.1/" target="_blank">http://xmlns.com/foaf/0.1/</a>"<br>
> typeof="foaf:Person"<br>
> about="#weborganics"><br>
> <p><span property="foaf:name" class="fn">Martin McEvoy</span></p><br>
> <p rel="foaf:img"><br>
> <img alt="weborganics" src="<a href="http://weborganics.co.uk/images/me.jpg" target="_blank">http://weborganics.co.uk/images/me.jpg</a>"<br>
> class="photo"/><br>
> </p><br>
> <p>Contact: <a rel="foaf:mbox" title="Email" class="email"<br>
> href="mailto:<a href="mailto:info@weborganics.co.uk">info@weborganics.co.uk</a>">Email</a><br>
> Web: <a rel="foaf:weblog me" class="url"<br>
> href="<a href="http://weborganics.co.uk/index.xhtml" target="_blank">http://weborganics.co.uk/index.xhtml</a>">WebOrganics</a></p><br>
> <div class="geo" id="weblog" rel="foaf:based_near"<br>
> xmlns:geo="<a href="http://www.w3.org/2003/01/geo/wgs84_pos#" target="_blank">http://www.w3.org/2003/01/geo/wgs84_pos#</a>"><br>
> <span typeof="geo:Point" about="#weblog"><br>
> <abbr property="geo:lat" content="53.7552" title="53.7552"<br>
> class="latitude">N 53.7552</abbr>,<br>
> <abbr property="geo:long" content="-2.3675" title="-2.3675"<br>
> class="longitude">W -2.3675</abbr><br>
> </span><br>
> </div><br>
<br>
</div>Which part of this is "messy" and "unacceptable?"<br>
<br>
This particular example is trying to do both microformats and quite a<br>
bit of RDFa. Think of it as an advanced example, which certainly does<br>
complicate things a bit. But other than the whitespace which isn't<br>
conducive to easy reading, what are the problems?</blockquote><div><br>It's... the whole thing. Does that not put you *directly* in mind of the bad old days of presentational html, when every file was fat with useless cruft? CSS pushed all that out of the html. Very often it saves us effort, as we need only say something once in the CSS and it applies to every page we link it into. Even when it doesn't, though, even when we're crafting a single specifically targeted chunk of CSS for one single page on our website, the combination of CSS+HTML makes the entire thing cleaner and more maintainable. Sometimes it actually requires *more* coding, but that code is generally much easier to understand and to edit later. Arguably, it makes it more aesthetically pleasing too.<br>
<br>Exact same thing here. As you say, if we're going to have metadata, we *can't* separate it from the content - it must *be* the content. What we want is merely a way of specifying which content is which metadata. This exemplifies DRY, as you're not repeating the important data - it appears only once in the actual content, so if it's updated there the metadata is also updated for free (being the same thing).<br>
<br>It's just that... syntax! It's horrible! It's ugly! It's bloated! It's useful when you want to present a single copy-paste-able chunk of html for clueless web authors to paste into their blog or facebook account, but us professional authors recoil in horror at such a thing, and with good reason. You *can* pull this stuff out into a separate chunk. We can even follow the useful example of CSS and allow partially-inline coding with a <metadata> tag, or fully separated stuff in another file.<br>
<br>This is *not* separation of content and metadata. It's separation of content and *classification*. We don't need classification inline to reduce data rot, because the data is still in a single, primary location - the content itself. Nor do we need it inline to enable cross-format metadata-faithful transfer - if this ever becomes a convenient reality, it will be performed by rdf-aware user agents anyway, which have already built up an internal RDF graph of the data in the page. They can export in appropriate formats by themselves.<br>
<br>As an added bonus, this kills the entire qname/curie/uri debate completely, as that data is pulled out to the classification format where you don't have to worry about it messing with dom parsing or whatever.<br><br>
I've converted Greg Houston's complex example into my early-draft syntax that I discussed with you off-list, and put it up on my site.[1] In this example the CRDF code is taller (though the metadata will likely be put away in a separate file and just linked in, so that's not an issue) and larger (by 90 bytes), but if you use a single extra point or another vcard on your site, you immediately see savings. What's more, the code is much *cleaner*. It has a bit more elements than I'd prefer to see, but that's a tradeoff you have to make with any categorization scheme because it's difficult to target text directly. The whole thing is much easier to understand now, though, and that's the sort of cognitive savings that are *really* important to an author.<br>
<br>(Note that I'm going off of pure intuition as to how foaf and geo work, so I may have some details wrong. Corrections are invited offlist.)<br><br>[1]: <a href="http://www.xanthir.com/rdfa-vs-crdf.php">http://www.xanthir.com/rdfa-vs-crdf.php</a><br>
<br>~TJ<br></div></div></div>