W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > July 2001

Re: N-triples (1.5)

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Thu, 19 Jul 2001 21:07:01 +0100
To: RDF core WG <w3c-rdfcore-wg@w3.org>
cc: Graham Klyne <GK@NineByNine.org>
Message-ID: <29858.995573221@tatooine.ilrt.bris.ac.uk>
>>>Graham Klyne said:
> At 04:38 PM 7/19/01 +0100, Dave Beckett wrote:
> >I've managed to update the document
> >   http://www.w3.org/2001/sw/RDFCore/ntriples/
> >with the notation changes you previously described, and with the
> >issues you have brought up, along with some solutions.
> A nit:  you still have:
>     eoln ::= cr? lf

That's because I only made grammar fixes to match the XML notation -
no change to the syntax.  The change to the version below needs
consensus as a WG document, rather than just a document on my web

> given that (a) email converts to CRLF in transit, and back to local 
> conventions on receipt, (b) HTTP does not touch EOL sequences, (c) systems 
> exist that use CR/LF (PCs), bare LF (Un*x), bare CR (Macs, I believe) then 
> I think any of these may appear, however the document is created.
> Thus (contrary to my earlier comments) I'd suggest:
>     eoln ::= cr lf | cr | lf
> (Aaron:  am I right about the Mac?)

That's one of the suggestions I have already recorded.

Again, that is also where I first started :-) but I got feedback that
suggested I prune it down as much as possible.

I've no strong feelings on changing to this from the current version
apart from having to write more code.

> OK, my vote is for your option 1.

[which is adding the \u, \U and \x python escapes]
> My reasons, FWIW, are:
> (a) to achieve a common representation for any string, and to be possible 
> to create N-triples with a non-UTF-8 tools.  (The common encoded 
> representation isn't so important to me, but the requirement has been 
> expressed...)
> (b) that the higher 32-bit code-points seem very rare, and 4 leading zeros 
> is a lot of overhead for a very occasionally (if ever) required feature.

I also prefer solution 1.

Also implies file format is ASCII - characters 0 to 127 are used.

Received on Thursday, 19 July 2001 16:07:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:02 UTC