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

Hi all!

Ben, thanks for the reopening. With the approval of further debate I
feel less hesitance to write this. I will however accept any decision
to close down debate and call for immediate vote (and if for "@class
or nothing" I'd vote for @class). That said, this is my take:


1. For the record, I am also opposed to using @role, for a reason I
have not seen emphasized (I may have missed it). While it *may* be
that the meaning of @role/xh:role is the same as rdf:type, I find it
more probable that it is at most a more specific property, with a
range narrower than rdf:type.

But the issue for me is that the usage of @role, as far as I can
interpret it, is to define a relation to a resource *with the subject
being the element itself*. If this is the case, @role is out.

This because '<div role="foaf:Person">' would mean that this actual
div element is a foaf:Person. Unlikely and undesirable. Sure,
sometimes the document substance itself is the subject, but as I know
it that means using @xml:id (or *perhaps* xpointer fragment urls..).

So regardless of xh:role meaning and range, its domain seems to be
that of XHTML elements. (Or is my attempt at precision flawed?)


2. I feel, like others have similarly expressed, that @class is
perhaps a too semantically loose and oft-used attribute. Having it
carry precise semantic information may thus be if not unwholesome then
at least precarious.

I could live with it due to its "de-facto-ness", from having been in
the draft examples and elsewhere (and I must confess I really liked it
when I first saw it). But if at all possible, I too would prefer a new
attribute.

One practical reason is that @class seems today to be about attaching
information about the element itself (akin to how I interpret @role
above). It may not be entirely clear, but considering a designer
aiming to state some stuff about a div containing a name and phone
number, '<div class="person">' is perhaps best interpreted as "this
element is a person data container".

So in the case of:

    <div about="#jane" class="person" yet_another_attribute="foaf:Person">

to me @yet_another_attribute is less likely to be messed with when
fiddling with the markup to make a coherent whole for presentation
(the main purpose of XHTML after all). The mere case of accidentally
wiping the entire @class value seems more probable than unawaringly
wiping @yet_another_attribute. (This is yet another thing making
microformats brittle in my eyes.)

Furthermore, isn't the case with (example fleshed out):

    <span class="fn vcard:fn">Jane Doe</span>

and

    <span class="fn" yet_another_attribute="vcard:fn">Jane Doe</span>

that in RDFa it should be:

    <span class="fn" property="vcard:fn">Jane Doe</span>

? ;) And "rdf:type"-ing literals isn't good at all, right? Using
@class for rdf:type may cause interpretation problems here..


3. Regarding a new attribute. Not remembering all suggestions, I
suggest "@instanceof" - not the least since the rdfs:comment of
rdf:type states "The subject is an instance of a class". Meshed
example:

    <div about="#jane" class="person" instanceof="foaf:Person">
        <span class="fn" property="vcard:fn">Jane Doe</span>
    </div>


4. I have thought about allowing *both* @class and a new attribute..
There may be some symmetry to the @href/@resource proposal in that.
But I admit suggesting both is a shot from the hip, and I feel some
qualms when doing it.


To summarize:

* +1 for having an rdf:type shorthand attribute
* -1 against @role, partly because of it's implied domain (I take this
is informally closed anyway)
* I have concerns about using @class, for reasons of imprecise domain
and need for value filtering
* I thus prefer a new attribute


Humbly yours,
Niklas



On 7/5/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
>
> 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 22:34:52 UTC