Re: This time I mean it

I have reviewed this document (http://www.w3.org/2001/08/rdf-test/), and I 
think it's fine for publication as a working draft.  I have the following 
editorial comments that might be considered for some future revision:


Section 1.1:, final sentence, suggest:

"... if such test cases are donated to the W3C, it may add them to the 
overall set of test cases."


Section 2.3:

(I've not reviewed the actual test cases cited.)

I would suggest that test cases with .rdf and .nt files each be presented 
in a single row of the table, e.g.

   Issue          Test case          Status
   -----          ---------          ------
   amp-in-url     test001.rdf, .nt   Approved

etc.

The "Approved" column content seems like redundant text.  Maybe using the 
date of approval as the anchor text?  (This would make it easier to locate 
the appropriate message(s) in offline email archives.)


Section 3.1, 1st para, final sentence.

I find the reference to [RDFMT] does not read very clearly.  I suggest:

"The meaning of these terms is defined in the model theory [RDFMT] being 
developed as part of the RDF Core WG activity."


Section 3.3:

I have been in discussion with some I18N folks about the issue of 
representation on non-ASCII URI characters in CC/PP.  Based on those 
discussions (which are almost but not quite finalized) I offer something 
the following:

[[[
RFC 2396 [URI], section 2.1, discusses the use of non-ASCII characters in 
URIs, and notes in particular that a URI may be represented as an original 
character sequence or as a URI character sequence.

N-triples uses only US-ASCII characters, so the representation of URI 
values in N-triples should be as a URI character sequence.  This is 
obtained from an original character sequence value expressed using Unicode 
characters by applying the rules defined in [Charmod] section Character 
Encoding in URI References.  That is, disallowed characters are represented 
in UTF-8 and
then encoded using the %HH format, where HH is the byte value expressed using
hexadecimal notation.
]]]

If N-triples is changed to use UTF-8 encoding, then (following XML, see 
http://www.w3.org/XML/xml-V10-2e-errata#E26) it may be preferred to defer 
transforming the URIs to use just US-ASCII.  (This approach is also 
indicated for XML schema datatype 'anyURI'.)  The second paragraph might 
then be changed to:

[[[
N-triples uses UTF-8 character encoding, so the representation of URI 
values in N-triples should be as an original character sequence expressed 
by Unicode characters, coded using UTF-8.  When the URI is required in the 
form of a URI character sequence (e.g. for retrieving a resource referenced 
by the URI), it is transformed by applying the rules defined in [Charmod] 
section Character Encoding in URI References.  That is, disallowed 
characters are represented in UTF-8 and then encoded using the %HH format, 
where HH is the byte value expressed using hexadecimal notation.
]]]


Section 3.4:

The example is un-printable:  the NT text is too wide to fit on a page.

Actually, this is a general problem I have with N-triples as defined:  the 
insistence that each statement be on a single line makes the test case text 
hard to read (and hence hard to review).  I think the extra effort required 
for a machine implementation to read an N-triple statement that splits over 
2 or 3 lines would be trivial compared with the added difficulty the single 
line form creates for human readers.  I would like to see additional line 
breaks permitted between the URIs; e.g.

triple ::= subject (ws* eoln)? ws+ predicate (ws* eoln)? ws+ object ws* '.' ws*


References:

Include reference to RFC 2396 as [URI] ?


#g
--


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
------------------------------------------------------------

Received on Friday, 9 November 2001 07:49:44 UTC