Re: TERMorCURIEorAbsURIs definition problem

I agree that this is an editorial error and agree with Nathan's 
suggested reference fix.  However, I feel like we should explain 'valid 
IRI' somewhere locally so it is clear a 'valid IRI' must be absolute.

On 2/5/2011 5:40 PM, Nathan wrote:
> Hi Shane, all,
>
> Currently TERMorCURIEorAbsURI is used by:
>   @datatype
>   @property
>   @rel
>   @rev
>   @typeof
>
> The text in CURIE and URI Processing [1] currently reads:
>
> TERMorCURIEorAbsURI
>   If the value is an NCName, then it is evaluated as a term according 
> to General Use of Terms in Attributes. Note that this step may mean 
> that the value is to be ignored.
>   If the value is a valid CURIE, then the resulting URI is used.
>   If the value is an absolute URI, that value is used.
>   Otherwise, the value is ignored.
>
> Now, "absolute URI" is defined as:
>
>   scheme ":" hier-part [ "?" query ]
>   scheme ":" ihier-part [ "?" iquery ] // IRI
>
> So currently, by that text no URI with a fragment is allowed as the 
> value of the five attributes aforementioned.
>
> I'm quite sure this is just editorial and due to the definitions in an 
> old URI RFC (rfc2396), but for current URI and IRI specs we'll be 
> needing "valid URI" or "valid IRI"
>
>   IRI   = scheme ":" ihier-part [ "?" iquery ] [ "#" ifragment ]
>
> which includes the fragment :)
>
> Suggest the text is changed from:
>
>   "If the value is an absolute URI, that value is used."
>
> To:
>
>   "If the value is a valid URI, that value is used."
>
> Which will clear this up.
>
> As an aside, might also be good if the first line read "If the value 
> is a term, then it is evaluated as a term acco.." rather than NCName, 
> we have term defined in the spec and it's definition is NCName any way.
>
> [1] http://www.w3.org/TR/rdfa-core/#s_curieprocessing
>
> Best,
>
> Nathan

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Sunday, 6 February 2011 16:11:48 UTC