Re: CURIE Processing (Re 2: Updated RDFa Core Editor's Draft available)

Ivan Herman wrote:
>   
>> That's outside of the scope of a CURIE.  My mistake.  I have updated the so that it talks about the syntax with and without a bracket and what that means.  I am still trying to decide if it hangs together.
>>
>>     
>>> @about or @resource. Put it another way, if an attribute's datatype is only URIorCURIE.
>>>   
>>>
>>>       
>> Okay - so you would like resource="" to mean the current document?  I don't mind.  I don't think it is specified in version 1.0.
>>     
>
> In RDFa 1.0 @about and @resource had the same datatype (URIEorSafeCURIE) so I would expect they had the same behaviour. The same for RDFa 1.1...
>   

Wow.   Epiphany.  I did not realize that a SafeCURIE would not work 
where a CURIE was expected in 1.0 (e.g. in @rel).  I think this is the 
core issue here.  I have attempted to harmonize the rules so that 
anywhere we can take a CURIE (or a SafeCURIE), we can take anything.,  
This is a mistake.  Seriously.  The only place this makes sense is on 
@about and @resource, and there only because we want to be backward 
compatible.  I will need to introduce a 'SafeCURIEorCURIEorURI' datatype 
for that case, and unroll the productions in Section 6 so that scurie is 
not incorporated into curie.  Nice catch.
> [snip]
>   
>>     
>
> But what does it mean? Safe CURIE-s were used in the old time for, eg, @about. But, as far as I can see, @about="[next]" is still an ignored URI because the CURIE processing does not talk about things that are reference only. Ie, the '[]' syntax does not bring anything whatsoever for @about; it is even misleading because people might expect that this would indeed be used as a term and it is not the case.
>
> On the other hand for @rel/@rev/etc the effect of '[]' is simply nil. @rel='[term'] and @rel='term' behaves exactly the same way, doesn't it?
>   

Yes.  And it is dumb.  We don't need this any longer with the epiphany 
above.  I will remove it.

>   
>
>
> With all due respect: do we have this requirement? It is certainly not in our charter;-). If other recommendations want to use CURIE-s they can use the specification in RDFa 1.0...
>
> I guess what I want to say is: if the price for this extra requirement is to confuse the readers of the RDFa 1.1 Core spec, then I am not sure we should go along with that.
>   

I appreciate your concern.  As far as I am concerned, this is an 
absolute requirement.  I know that there are a lot of people in this 
working group who were not around before, and don't have the history to 
understand how this came to be.  I could try to write it up, but frankly 
it comes down to this:  We can't tell people to refer to a 
Recommendation that we are superseding.  Since 1.1 Supersedes 1.0, we 
need to keep faith with the consumers of 1.0 as much as possible.  That 
includes consumers that were using only parts of our document.  
Therefore, the CURIE definition needs to remain independent.  It 
*should* be published in its own Recommendation.  It's a personal 
failing that I didn't make that happen in the context of the XHTML2 
Working Group.  Today the political climate would prevent it.  The only 
way we can ensure that CURIEs are useful for all the other places they 
make sense is to have them embedded in our spec and have the definition 
abstract enough that they can be customized by the other potential users.

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

Received on Monday, 12 April 2010 15:22:07 UTC