Re: Notification: Role Attribute Editor's Draft available

Ivan Herman wrote:
> Hm. I feel a little bit uneasy here, though I am not sure how to solve this.
>
> Appendix A says:
>
> """
> When @role is included in a markup language that also includes RDFa Core attributes [RDFA-CORE], an RDFa Processor MUST process the role values as follows:
> """
>
> So if, say, HTML5 includes @role and we also have the RDFa attributes in HTML then a conformant RDFa processor MUST implement @role and @id, too. This means that if I am an implementer of RDFa, I am supposed to know and look at a very different recommendation produced by a different group, than the ones published by the RDFa and the HTML WGs. Is this really o.k.? I am not sure. Also, how do I know whether a specific XML file should be processed with the role attribute? Do we rely on the DTD alone?
>   

Well...  if HTML+RDFa wanted to incorporate the requirements of the Role 
Attribute, that specification would need to normatively reference the 
Role Attribute specification.  In that way it is really no different 
than any other normative reference (e.g., URI).

>
>
> Then... o.k., I swallow that and I try to implement this. @role looks like a @rel with a fixed URI and the value is a list of, essentially, URIs. It has no direct counterpart in RDFa, so the processing steps have to be adapted for @role. It also says that the subject is @id. Is the value of @id inherited in the source tree (as you would expect in RDFa) or is the subject setting valid on the element only? 

Err.... why would you think that?  @id has explicit semantics in XML 
(and HTML).  It is not inherited.  The text says if there is an @id then 
use that as the subject (actually, use the base + '#' + that, but 
whatever).  If there is no @id, then create a unique (distinct) bnode.  
The subject is used for this triple.  We are not setting the local 
subject for other RDFa processing.

> Does it means that @id makes the processor to ignore @about, but only for this element? 

No.  @about still works.  We didn't say anything about that. Nothing in 
that very small set of steps should effect the other processing of RDFa.

> Also, what is the relationship with the other RDFa attributes? Eg:
>
> <div typeof="" role="something">....</div>
>
> Do I have to generate two different BNodes (one for typeof and one for role)? 

Yes. @role gets a unique bnode.  @typeof always also creates a bnode.

> Will the second BNode be a subject for the RDFa statements within <div>?
>   

Yes, as per the RDFa Core Processing Instructions.

> There are probably other issues to solve to get it right with the RDFa processing steps.
>
> I wonder whether another approach would not be possible. We used the conceptual model of hGRDDL before, I think: is there way to define a DOM -> DOM transformation that would map the @role attribute into bona fide RDFa structures? If such transformation was possible, then the core RDFa processing steps would remain unchanged... The issue I see is that a transformation of the form
>
> <div @about="XXX" rel="xhv:role" resource="values of the original role attribute">...
>
> does not work because @resource takes one single URI, whereas role seems to take more...
>
> Sigh. I am not sure how to solve all this, I must admit, probably because I know very little of the origins of role. I wonder whether the original goals of role could not be fulfilled by using RDFa directly...

Definitely not.  @role is largely orthogonal to RDFa.  It has a specific 
semantic for the assistive technology community and a11y in general.   
However, in the XHTML2 Working Group the players seemed to feel strongly 
@role should also integrate with the metadata that was being exposed by 
what is now RDFa.  That's the only reason there is any treatment of RDFa 
in the Role draft at all.  I don't think the PFWG has any real concerns 
about this - it is down to us.  In my mind I really want the RDFa 
triples in the same graph because I want it accessible by our RDFa DOM 
API.  It makes it easier for application developers and assistive 
technology manufacturers to embrace the broader RDFa and A11Y at the 
same time.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Thursday, 22 April 2010 14:20:46 UTC