Re: Canonical N-Triples

On 06/12/13 15:21, David Wood wrote:
> Hi Andy and all,
>
> Andy correctly identified a problem in the N-Triples spec.  The
> “canonical“ form of N-Triples is defined, but never used for
> anything.  David Booth suggested that implementors be "encouraged" to
> parse at least that form, but that is impossible to do as long as the
> encouragement would need to be added to the normative Conformance
> section.
>
> Andy has moved the canonical N-Triples form to a separate section [1]
> in the latest editors draft.  I think we can and should make the case
> that this is a purely editorial tweak for the purpose of saying
> something informative about canonical N-Triples.
>
> However, there are still at least two problems:
>
> 1.  The canonical N-Triples form is not really used anywhere.  It is
> mentioned briefly in the Conformance section [2].
>
> 2.  It is unclear why we are mentioning canonical N-Triples at all.
>
> I propose that Section 4 (A Canonical form of N-Triples) be marked as
> informative,

OK - just following through on that - it needs change to at least scope 
the RFC-MUST language to the section only.

Will it need removing from "conformance" (which is normative)?

> and implementors be encouraged to support at least the
> canonical form in that section.

on output because ...

>  We might want to go farther by
> stating that users can presume that a compliant parser will support
> at least the canonical form.

... a compliant parser will have to support the whole language.  This 
not much of a burden for N-triples.

1/ The implementation report is for language parsers.

2/ If we have parsers of just the CNT subset layout, we need to put in 
the infrastructure for a profile/different language, i.e. have conneg 
for canonical n-triples (CNT).

It becomes a different language, which needs it's own content type 
differentiator, if some parsers don't accept the grammar-defined form.

We are out of time (even if it's a good idea which I'm not convinced it 
is because feeding proper NT through perl can be used to create CNT).

[*]

> That approach seems to address both of the problems identified,
> although it does push the boundary of editorial changes.
>
> Does anyone disagree?  Do the staff members have comments or
> suggestions?
>
> Regards, Dave -- http://about.me/david_wood
>
> [1]
> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/n-triples.html#canonical-ntriples
>
>
[2] 
https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/n-triples.html#conformance
>

[*] In the spirit of open disclosure there is a teensy-weensy area that 
making it too well defined might need consideration.

Control codes below 0x20 except \n and \r are raw in strings, not \u. 
That may be an issue, it may not.  It is not nice IMO.

But we are out of time to change it and as a dump format, its not necessary.

Received on Friday, 6 December 2013 19:07:12 UTC