Two proposals - (A) - basically required, and optionally (B) as well.
Also question for Martin - any guesses as to *when* IRI will get to RFC?
Proposal A) Propose that RDF concepts is changed to prohibit control
characters in RDF URI References
The proposal is illustrated by this textual change to:
6.4 RDF URI References
http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
Replace:
[[
A URI reference within an RDF graph (an RDF URI reference) is a Unicode string
[UNICODE] that would produce a valid URI ...
]]
with
[[
A URI reference within an RDF graph (an RDF URI reference) is a Unicode string
[UNICODE] that
+ does not contain any control characters ( #x00 - #x1F, #x7F-#x9F)
+ and would produce a valid URI ...
]]
Proposal B) Propose that concepts is changed to informatively permit
implementations to issue a warning for the use of RDF URI references not
conforming to any draft of IRI
The proposal is illustrated by this textual change to:
6.4 RDF URI References
http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref
Add a new note (informative) immediatly after the current note about XML
Namespaces 1.1, as follows:
[[
Note: this section anticipates an RFC on Internationalized Resource
Identifiers. Implementations may issue warnings concerning the use
of RDF URI References that do not conform with [IRI draft] or its
successors.
]]
(We could possibly delete the XML Namespaces 1.1 note, as well - my preference
is not)
====
(A) was simply a mistake. No version of IRIs or proto-IRIs has allowed control
characters - e.g. XLink text prohibitis them because they are prohbitied in
XML 1.0, and hence do not need to be explicitly prohibited.
Since RDF concepts does not assume an XML context, we need to be explicit.
(B) is trying to steer between various problems and concerns:
As far as I understand
- the RDF Core WG does not want to guess the future
- hence conforming with previous proto-IRI text is our preference
- the RDF Core WG cannot normatively depend on a draft.
- the RDF Core WG does not see it as its role to draft new text concerning
generic I18N issues, but wishes to take best practice from elsewhere
yet
- we have user feedback agreeing with the feedback to the I18N group that
specifically allowing spaces is unwise.
- we wish to minimize the transition cost of adopting IRI when it is an RFC
Jeremy