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

On May 17, 2010, at 17:11 , Shane McCarron wrote:

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

Indeed, I remember this discussion. I guess the problem is that the current spec is, spec-wise, clear and clean. If we want to avoid relative URI-s in other cases, it makes the spec more confusing I am afraid...

Ivan



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


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