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

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:

   1. 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.
   2. Does the value match the production for a CURIE?  If so:
         1. Is there a matching in scope prefix mapping?  Yes, then
            expand the CURIE.
         2. No?  Treat it as an absolute URI


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