- From: Shane McCarron <shane@aptest.com>
- Date: Sun, 06 Feb 2011 10:11:10 -0600
- To: nathan@webr3.org
- CC: RDFA Working Group <public-rdfa-wg@w3.org>
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