Re: Notification: Role Attribute Editor's Draft available

Comments inline

Toby Inkster wrote:
> On Wed, 21 Apr 2010 12:31:19 -0500
> Shane McCarron <shane@aptest.com> wrote:
>
>   
>> Please review this document, in particular Appendix A, so that you 
>> understand what we are trying to do and that you agree with the 
>> direction I am taking that spec in.
>>     
>
> Firstly, given:
>
> 	<div id="quux" role="foo:bar">
>
> It currently generates:
>
> 	<#quux> xhv:role foo:bar .
>
> Another possibility would be:
>
> 	<> foo:bar <#quux> .
>
> Is there any reason you've chosen the former over the latter? Was the
> latter considered and dismissed for any particular reason?
>   
Yes, I/we considered both.  @role is a special attribute with specific 
semantics.  We want to ensure that the triples that arise from it 
clearly indicate that a node has a specific role.  I envision using this 
in conjunction with the RDFa API to help identify areas of the document 
with certain well known roles (e.g. the ARIA roles).

> Secondly, as @role uses CURIEs, does role use @prefix? The previous
> drafts relied on @xmlns only. If @role is still restricted to using
> @xmlns, then an RDFa processor would need to keep track of two
> different sets of CURIE prefix definitions.
>   

Role relies upon RDFa Core for the CURIE definition.  So it uses 
whatever RDFa Core says it should.  Sorry - that was glib.  Yes, it 
relies upon @prefix.  And everything else that comes along with RDFa 
Core when it is used in that context.  In a non-RDFa markup language, I 
suppose it is possible that there are only TERMs and URIs and there are 
no CURIEs per se.  That would be fine for the associated assistive 
technologies that are going to look at the value of @role to help people 
find parts of the page.

> Lastly, the draft says "an RDFa Processor MUST process the role values
> as follows". This could be interpreted in two different ways:
>
> 	1. If an RDFa processor chooses to process @role, then
> 	the following is the way it MUST do it; or
>
> 	2. RDFa processors MUST process @role, and this is how
> 	they MUST do it.
>
> If the latter, I'd object to this document published outside the RDFa
> WG making normative assertions about RDFa processing.
>   

Well...  You are correct that this spec can't make statements about RDFa 
Core processors.  That section should make it clear that, when a markup 
language incorporates the Role Attribute Spec and the RDFa Core spec 
into the same language, an RDFa Processor needs to process @role in the 
manner defined.  So, I guess that's your number 2 above sort of.  FWIW I 
have added an issue about incorporating @role into XHTML+RDFa because I 
think we should...  so in my mind an RDFa Processor that swallows 
XHTML+RDFa 1.1 MUST process @role as described in the Role Attribute 
specification.

Having said all that, I agree that it is uncomfortable to have an 
external requirement like this.  However, the RDFa Working Group isn't 
chartered to do @role.  The good news is that I don't think the PFWG 
really cares about this aspect of the spec.  We care about it, and I am 
the editor, Mark and Manu have been advising me, and we can all 
influence this to get it right.  So I am not too worried about this spec.

I am worried about the precedent it sets though.  That another spec can 
impose requirements like this.  There are likely precedents, although I 
can't think of one right this second.

Suggestions?


> I ought to have a working implementation of this pretty soon.
>
>   
Cool!  I haven't even thought about implementing it yet.

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