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

Some responses inline

Ivan Herman wrote:
>
>
> So what is the value of @about="[abc:def]" if there is no prefix definition for 'abc'? I believe our intention was to say that the value is empty, ie, no URI at all. (Maybe I am wrong.) However, my reading of the current text in section 6 is still that this will be interpreted as a URI with value abc:def. Indeed, the whole of section 6 reads like being valid for all curies, regardless whether they are safe or not, and the processing will get to the 'Finally, if there is no in-scope mapping' bullet item, which says that the original value is used as a URI. I see that you have a sentence right after the grammar rules on safe curie-s but, I believe, this is a bit confusing...
>   


Well...  in section 7.4.2 right at the top, we say "If the value /is/ 
surrounded by square brackets, then the content within the brackets is 
always evaluated according to the rules in CURIE Syntax Definition 
<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#s_curies> 
- and if that content is not a CURIE, then the content /must/ be 
ignored."  I agree that this gets inconsistent with section 6 because I 
was trying to be too clever.  I am pushing this into the section on 
CURIE processing to see if it hangs together better there.

Section 6 really shouldn't talk about what an unmapped CURIE prefix 
means.  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.

>   
>
> I think my problem (and maybe that is true for the previous section, too) comes from the fact that the processing of URIorCURIE and processing of CURIE is sort of merged in section 6 with that last bullet item. Operationally, I believe what happens is that if there is no in-scope mapping for a CURIE then there is nothing; so the evaluation of the URIorCURIE datatype means (1) first try to use that as a CURIE (2) if that is unsuccessful, then comes the URI bit. Ie, maybe that bullet item should not be in section 6, and in section 7.4 (using your new numbering) there should be a somewhat more formal step description that makes things clear. I must say that the fact that this section is a mix of examples and of processing step specification makes it a bit difficult read for my mind:-(
>   

Yes, I think this makes sense (see above).  I have made some changes.


>
>   
>>> - I saw in 6.4.3. that the notion of safe terms was also introduced. I am not sure what that means and why it is useful; terms are used with attributes like @rel and @rev, where we did not have any notion of safe curie before, why having these safe terms now? It is certainly not defined anywhere what it means...
>>>  
>>>       
>> It is only introduced for consistency.  'next' is a TERM, and historically we permitted 'next' and '[next]'.  Since a TERM is just a special form of CURIE, and since we permit CURIEs in brackets, we need to permit TERMs in brackets too.  I don't think they should really be used or anything, but if we did not permit them then it would be inconsistent and a parser might have to do funny things to evaluate a CURIE.
>>     
>
> Hm. Is it correct that in your new formulation 'TERM is just a special form of CURIE'? Term processing is not covered by section 6 (nor should it be), and the fact that we have now TERMorURIorCURIE makes it very separate. Ie, I just do not see any role of the '[term]' syntax whatsoever; can't we simply get rid of it?
>   

Maybe.  I feel like if we are permitting [foo:bar] we should also permit 
[bar] in the default vocabulary.  If we don't, then people who *want* to 
use the smart curie syntax to be absolutely unambiguous about their 
intent will only be able to use it sometimes.


>   
>>> - (Editorial) I would really like to rearrange the text so that section 6.4.3 is closer to section 8. These two sections form some sort of a unit insofar as how attribute values are mapped on URI-s. As an implementer I had to scroll up and down the text to find these two, which is a bit disagreeable...
>>>  
>>>       
>> I appreciate that...  One option is to just move section 8 to a (new) section 6, sliding everything else down.  That would flow better and would still keep the CURIE spec as an independent section.  Keeping it independent is very important for our use of CURIEs in other places.  I hade done this in the work-in-progress version.  Let me know if you think it helps.  (Note that this will mess up diff marking I imagine).
>>     
>
> Yes, I think it is better but I wonder whether we can go one step further. Section 6 is still both a syntax definition _and_ a set of processing steps to define a mapping from CURIE-s to URIs. I do not have a problem with that, but I may prefer a structure which says:
>
> section 6: mapping URIs
> section 6.1 CURIE Syntax Definition and processing (current section 6)
> section 6.2 Processing steps for the URIorCURIE datatype
> section 6.3 Term syntax and processing steps for the TERMorURIorCURIE
>
> thereby getting these three in one bundle to cover what is logically our ways of creating URIs in RDFa...
>   

I will see if there is something I can do that still addresses the 
requirement of having a stand alone section that can be used by other 
specifications (like the Role Attribute).