W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > May 2010

Re: On ISSUE-6 (invalid values in @datatypes cause plain literals to be generated)

From: Shane McCarron <shane@aptest.com>
Date: Mon, 17 May 2010 10:11:06 -0500
Message-ID: <4BF15C8A.8090605@aptest.com>
To: Ivan Herman <ivan@w3.org>
CC: Mark Birbeck <mark.birbeck@webbackplane.com>, Toby Inkster <tai@g5n.co.uk>, W3C RDFa WG <public-rdfa-wg@w3.org>
Yes, I agree that the current draft does not say this.  Easily fixed if 
this is something we want to do.  However, if we do, looking at @about, 
for example, it would meant that you couldn't say about="somepage.html" 
- and I think we wanted to permit that.  In fact, I think that was the 
use case.  That and resource="something.jpg".  However, note that in 
both cases those attributes don't take TERMs, so there is less room for 
ambiguity.

On 5/17/2010 9:56 AM, Ivan Herman wrote:
> On May 17, 2010, at 15:53 , Shane McCarron wrote:
>
>    
>> FWIW it was my *intent* that we only permit absolute URIs.  I remember that we debated this, I don't remember when nor why.  However, just from a processing / parsing perspective, I think something evaluating an attribute that takes the type TERMorCURIEorURI would work like this:
>> 	 Does the value match the production for a term?  If so, evaluate it as a TERM (which might mean it gets thrown away) and stop.
>> 	 Does the value match the production for a CURIE?  If so:
>> 		 Is there a matching in scope prefix mapping?  Yes, then expand the CURIE.
>> 		 No?  Treat it as an absolute URI
>>
>>      
> But that is not what the text says, right? (Just checking my own interpretation.) What it says is process it as a URI which includes relative URI-s, too
>
> Ivan
>
>    
>> In other words, in my mental model for this AND in my implementation, a relative URI would never get treated as valid because a relative URI doesn't have a prefix.  Remember, the ONLY reason we added this rule was to accommodate absolute URIs.
>>
>> Regardless, if you all want to try to support relative URIs as well... I guess that's okay, but I agree with others that there is not really a use case I can see and I think it makes processing more difficult, introduces new, interesting, and ugly edge cases, and will make document authoring even more error prone.
>>
>>
>> On 5/17/2010 7:39 AM, Mark Birbeck wrote:
>>      
>>> Hi Toby,
>>>
>>>
>>>
>>>        
>>>> This is precisely the specific problem that should force us to disallow
>>>> relative URIs. If people think they can use relative URIs, they'll use
>>>> things like datatype="foo.html", but that will be interpreted as a
>>>> term, as "." is allowed in NCNames. The rules on when something is
>>>> interpreted as a relative URI reference and when it's interpreted as a
>>>> token would be confusing to authors.
>>>>
>>>>
>>>>          
>>> Well...we actually already have the rule. If it's not a term, and it's
>>> not a CURIE then by definition it's a URI  -- absolute, relative,
>>> whatever.
>>>
>>> I think that's actually quite straightforward.
>>>
>>> Regards,
>>>
>>> Mark
>>>
>>>
>>>        
>> -- 
>> 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
>
>
>
>
>
>    

-- 
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, 17 May 2010 15:12:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:47 UTC