Re: [RDFa] ISSUE-3 @class and @role for rdf:type

Hi Ben,

I really do appreciate the approach you're taking here. I do
understand the argument that "we've discussed this once so shouldn't
reopen it", but I do think that something different is going on here.
If all that was happening was that we were simply reopening the debate
about @class v. @role then I would agree with you that it's not
exactly great progress. But the way it has been 'reopened' is as
@class v. a new attribute--in other words, as a proposal which some
people regard as a much better solution than the ones that were on
offer at the time we 'informally' closed the issue.

(And given that some people have said "I've been keeping quiet about
this...but I have to say I really don't like the current solution", I
think it is the healthiest approach to debate this.)

Anyway, like you, I hope that @role isn't on the agenda as a candidate
for the rdf:typeness carrier, because that was a really hard
discussion! Hopefully all we need to resolve is (a) stick with @class
or (b) use a brand new attribute that is 'owned' by RDFa.

So the main argument in favour of @class representing rdf:type is
certainly, as you rightly say, that we've been using it for a while
now. You could also argue that it sort of already means rdf:type in a
way, and that people are already using @class 'semantically' in the
web community so there is little chance of confusion.

The main argument against @class being used to represent rdf:type is
that we're overloading an existing attribute that is generally
associated with CSS. I think it's fair to say that this is not totally
disagreeable to everyone, since @class is increasingly used
'semantically', but what does make it less palatable than it might be
is that we get around the overloading by processing prefixed and
non-prefixed values in a different way, which does feel hacky.

Obviously the fact that we're even discussing this at all is
predicated on the assumption that we need a shorthand for rdf:type;
assuming that we do, then the 'against @class' position is probably an
argument 'for @somethingElse'. (But it could of course be an argument
'for having no rdf:type support.)

Speaking for myself, my position is as it was before; I really would
prefer a new attribute because it feels cleaner, and reduces the risk
of problems when we get to last call. But @class is not so bad, and if
people vote for that I can certainly live with it. :)

Regards,

Mark


On 05/07/07, Ben Adida <ben@adida.net> wrote:
>
>
> A followup.
>
> As much as I'm distraught that we can't go with our unofficial
> consensus, I am forced to note that I'm the only one left fighting for
> @class. If anyone else out there on the list wants to speak up, it's now
> or never, because, even if the issue were closed, the current state of
> things would force me to reopen it.
>
> So, unofficial resolution or not, I am reopening this issue for discussion.
>
> My personal take (chair hat off) is that we stick with @class, using
> namespaced values only, mostly because the specifics here don't really
> matter much technically speaking, but the inertia does. I see an
> actively serious problem with using @role, since that has a meaning for
> WAI that is clearly not rdf:type (though it can be xh:role, of course).
> So, if @class loses, then I favor a new attribute altogether. @role
> should have an RDFa meaning, though I don't think it belongs as a core
> RDFa attribute and thus shouldn't really be added until XHTML2, IMO.
>
> -Ben

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Thursday, 5 July 2007 20:00:22 UTC