Proposal, allow Colon in a Term

Hi All,

I'd like to propose a change to the specification, the change is simply 
to specify "term" as being a "Name" rather than NCName, this would allow 
the use of colons in terms.

Note: this will only be possible / compatible if the definition of CURIE 
is changed as per my proposal on ISSUE-83 [1]

The only changes which would need to be made to the specification would be:

Under "7.4 CURIE and URI Processing" change the relevant text to:

[[
TERMorCURIEorAbsURI
If the value is a valid CURIE, then the resulting URI is used.
If the value is a term, 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 URI, that value is used.
Otherwise, the value is ignored.
]]
(rules 1 and 2 have been swapped)


Under "7.4.3 General Use of Terms in Attributes" change the definition 
of term to:
[[
    term     ::=  Name
]]

This simple change will open the door to many different uses of RDFa, 
will give authors an alternative design pattern for having profile like 
functionality (one without any dereferencing involved, where the correct 
triples are always generated and with non of the negative side effects 
of profiles), and allow those who wish to treat strings such as 
"foo:bar" as simple lexical tokens without any "prefix based 
indirection" should they wish (and non of the negative effects of prefixes).

At the same time, nothing would change for anybody else who didn't want 
to utilize this functionality, it's entirely compatible with the current 
draft of RDFa Core and all examples, it's even compatible with default 
profile as described, general use of profiles, terms etc etc.

ps: this would partially address many of the concerns received from 
members of the HTML WG, allowing people to still use "foo:bar" style 
tokens without any of the indirection, and my own concerns about 
profiles, gives us all an alternative, and an opt-out of functionality 
we don't want, whilst not limiting RDFa or getting rid of any existing 
functionality.

[1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0035.html

Best,

Nathan

Received on Monday, 7 February 2011 01:04:18 UTC