W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2007

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

From: Ben Adida <ben@adida.net>
Date: Thu, 05 Jul 2007 10:27:26 -0700
Message-ID: <468D29FE.50004@adida.net>
To: Shane McCarron <shane@aptest.com>
CC: Steven Pemberton <steven.pemberton@cwi.nl>, public-rdf-in-xhtml-tf@w3.org


This rehashes discussions we've had many times. I'm extremely
discouraged that, although we had an agreement on 5/31, we are now
discussing this as if it were a fresh debate. It's not! Steven and Mark
were *on the call* when we made this decision!

Steven said, on 5/31: "we should just finish this quickly with minimal

We need to respect the decisions we've made, or we will have absolutely
no way to wrap up.

There's also no such thing as a "right" or fully consistent answer here.
Everything we've proposed is considered "wrong" by someone. So that
argument doesn't carry much weight with me. We're trying to find the
best compromise of the ideal RDFa if it had been designed into HTML from
the start, and the actual state of things in the real world.

To the details of what you're saying: we don't trample on microformats.
It's trivial to have microformats and RDFa at the same time, since
@class accepts multiple values. What's the difference between:

class="fn vcard:fn"


class="fn" yet_another_attribute="vcard:fn"


And @role is not such a clean solution. Mark has made very strong
arguments as to why @role cannot mean rdf:type, and if it cannot mean
rdf:type, then we have to find yet another attribute for rdf:type.

And Steven has made strong arguments regarding the fact that @class is
*not* owned by CSS.

So, we've come full circle, again. I hope we can start to consider the
inertia of written documents, decisions made, and implementations in
this decision process. This inertia needs to be part of the reasoning,
or we're just throwing away all of the adoption work done so far.


Shane McCarron wrote:
> I have kept quite on this issue, but have been ruminating on it for weeks.
> Steven Pemberton wrote:
>> Let me try and summarise the positions as I see them
>> For class:
>>     Used by microformats in a similar way
>>     HTML Spec allows it
>>     Already there, no new attribute
>>     Implementations already using it
>> Against class:
>>     Special rule for namespaced/non-namespaced values
>>     Confusion/objection by/upset for current class users
>>     Used by microformats in a similar way
> The class attribute does not take QNAMEs as values, it takes CDATA.
> Moreover, CSS2 does not know how to deal with namespace-qualified class
> names at all, so if we introduce this concept we run afoul of the
> community that has, by all accounts, the best claim to the @class space.
> While the similarity with microformats (how I *hate* that term) is both
> good and bad, I do not think that we should attempt to steal the march
> from microformats by co-opting the space they are ad-hoc operating in. 
> We would be much better off working in a separate space and
> demonstrating how much more powerful that other space is.
>> For role:
>>     Clean start, no legacy
>>     No special namespace-prefix rules; can use default namespace rules.
> XHTML is designed to permit the introduction of new attributes.  The
> XHTML working group has already introduced this attribute into the XHTML
> namespace, so it is available for use in this way.
>> Against role:
>>     Potential conflict with WAI use of role needs to be resolved
> I think there is no conflict, but that's from an XHTML / WAI
> perspective.  From an RDF perspective there may be.
> The more I think about this, the more I believe that using @class in an
> XHTML 1.1+RDFa context is just wrong.  Even using it in an HTML4 context
> is wrong.  Having special rules for prefixed vs. non-prefixed values is
> inconsistent with everything else we have done.  @role is a clean
> solution that dovetails nicely with the original intent of the
> attribute.  How it is transformed into RDF (rdf:type vs xh:role) I don't
> understand or care, really.
Received on Thursday, 5 July 2007 17:27:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:23 UTC