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

Shane,

I have been playing with the implementation on the week end, and I spotted some other issues or questions. Sorry if I missed something again...

- (Probably editorial) Appendix A still includes the datatypes URIorSafeCURIE and URIorSafeCURIEs, though this is not used in the main text any more...

- That being said, the notion of safe CURIE is specified in section 8, but it is not really said what safe curie means in terms of processing. Isn't it correct that the last bullet item in this section ('Finally, if there is no in-scope mapping for prefix, the original value is used as the URI.') is valid _except_ if the CURIE was a safe CURIE?

- Where do we define what the value of @attribute="" is? 

For attributes like @about, where the datatype is URIorCURIE, it is fairly o.k., because the evaluation flows through CURIE processing, gets to the last bullet item in section 8, the normal URI processing kicks in, and this leads to base. 

For an attribute like @rel, processing starts by term processing and, if that is unsuccessful, flows into URIorCURIE. First of all, 6.4.3 does not say explicitly what happens is term is empty but the logical conclusion is that, unless there is no local default vocabulary, the term is ignored. Ignored means to move on to URIorCURIE which will lead to... base.

But that is in contradiction with, eg, our agreement that @typeof="" produces a simple BNode. Instead, it will produce a bnode whose type is the base URI... The value of @datatype="" will also be different than in RDFa1.0

I am not sure what the most elegant way of solving that is. I think it should be said explicitly that if an attribute can accept a term and a URIorCURIE, then an empty attribute value does not produce any URI at all.

- 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...

- (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...

- (Editorial) For the sake of completeness, I think section 6.4.4 should also list @vocab and @profile as accepting only URI-s

Ivan



On Apr 8, 2010, at 19:41 , Shane McCarron wrote:

> As per my action items today, I have updated the RDFa Core spec and pushed a new Editor's Draft.  This is available via our drafts page at http://www.w3.org/2010/02/rdfa/drafts
> 
> I have also done some work on our publishing toolchain, so we are getting diff marks, postscript, and PDF versions of specs automatically now.
> 
> Please take a close look at this document, as I expect it is in the nearly final form for FPWD.
> 
> -- 
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf