- From: Ben Adida <ben@adida.net>
- Date: Fri, 16 Feb 2007 12:26:41 -0500
- To: Steven Pemberton <steven.pemberton@cwi.nl>
- CC: Simone Onofri <simone.onofri@gmail.com>, Ivan Herman <ivan@w3.org>, "Hausenblas, Michael" <michael.hausenblas@joanneum.at>, RDFa <public-rdf-in-xhtml-tf@w3.org>, SWD WG <public-swd-wg@w3.org>
Steven Pemberton wrote: > When we discussed class vs role I said that although using class was a > technically sufficient solution, I thought it unwise because class is > used for different things, and people would complain; better to leave > class for the mess it is and start with a clean sheet. Now someone has > complained (Tim Berners-Lee no less), and *you* are reraising the issue, > not me. I didn't mean to imply that ROLE came out of left field, only to point out that it was discussed and a decision was made. Your reservations were definitely noted at the time, of course. > So we could elect to tweak the solution we have now (although one of the > reasons for using class (microformats uses it) now disappears because > microformats uses class with unprefixed values) or we could reevaluate > the solution to see if it was such a good idea in the first place. I don't think the MF reason goes away. We were never going to be syntactically compatible with MFs, since MF's CLASS changes semantics from one vocabulary to another. The issue here is what authors are used to. If they're used to class="structure", then introducing class="ns:structure" is just a small cognitive step away. > Either way we should be aware of the choices open to us. Sometimes when > you take a wrong turning, it is easier to retrace your steps than hack > through the bush to get where you wanted to go. Before you start hacking > you should at least consider which you think will be quicker in the long > run. Fair enough, but my point is that if we spend a lot of time retracing our steps, then we may end up going around in circles for a while (the analogy gods must be very angry with me now). Here's an important case in point: I want to push out a new Primer ASAP, so that the WG can consider it next week and we can have the latest and greatest syntax out there, including striping. I've addressed all of the comments from Guus and Antoine, and even a bunch of Ivan's comments. If we can't consider this issue closed, then I'm stuck, and we've got another delay in the Primer. Here's why I think we're doing the right thing with capturing only namespaced CLASSes: we have the same issue with REL. What should we do for REL="my-no-namespace-rel"? Same problem. Are we going to introduce a new attribute, when REL does the job so well already? I'm pretty sure we're in agreement that we shouldn't. Even though one sees custom CLASSes far more often than custom RELs, it seems to me the same design principle applies. >From my point of view, the solution that packs the best combination of consistency, respect for existing attributes, respect for existing decisions, and least astonishment, is to keep CLASS as rdf:type, but only consider namespaced values. If you disagree, let me know, and we can fully reopen the issue. -Ben
Received on Friday, 16 February 2007 17:26:53 UTC