Re: Issues found in Turtle spec

On Mon, Aug 29, 2011 at 12:20 PM, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:
> I just finished implementing RDF 1.1 Turtle [1] from the most recent spec
> [2]. I encountered some minor issues and ambiguities in the spec:
>
> In section 2.1, the spec indicates that "Literals , prefixed names and IRIs
> may also contain escapes to encode surrounding syntax ...", however the
> description in 5.2 indicates that only IRI_REF and the various
> STRING_LITERAL terms are subject to unescaping. This means that an IRI which
> might otherwise be representable using a PNAME cannot if the IRI contains
> any characters that might need escaping. This implementation currently
> abides by this restriction. Presumably, this would affect both PNAME_NS and
> PNAME_LN terminals.

This is the subject of a two current issues (and should have been
marked as such in the specification)
http://www.w3.org/2011/rdf-wg/track/issues/67 and
http://www.w3.org/2011/rdf-wg/track/issues/74

> The empty prefix ':' does not have a default definition.

No prefixes are bound by default.

> In Notation, this
> definition was '<#>' which is specifically not intended to be used in
> Turtle. However, example markup using the empty prefix is common.

If in those examples there is no @prefix : <blah> statement, those
examples are not valid Turtle and should be fixed. (Some of the
examples in the Turtle spec are NOT valid Turtle, all of those SHOULD
be marked as such. Or all should become valid.) Looks like a good test
case to add.

> This
> implementation defines the empty prefix as an alias for the current base IRI
> (either defined using @base, or based on the document's origin).

That is not correct behavior. The : prefix is just like any other
prefix, it's use without a matching @prefix deceleration is an error.


> The EBNF definition of IRI_REF seems malformed,

The IRI_REF is malformed and should match the production from SPARQL
which it no longer does.

> and has no provision for \^,
> as discussed elsewhere in the spec. We presume that [#0000- ] is intended to
> be [#0000-#0020].

While [#0000- ] is valid EBNF it's not exactly readable ;)


> The list example in section 6 uses a list on it's own, without a predicate
> or object, which is not allowed by the grammar (neither is a
> blankNodeProperyList). Either the EBNF should be updated to allow for these
> forms, or the examples should be changed such that ( ... ) and [ ... ] are
> used only in the context of being a subject or object. This implementation
> will generate triples, however an error will be generated if the parser is
> run in validation mode.

It seems likely that this is more of the same errors from above,
examples that are not valid Turtle should likely be removed from the
specification as just noting that they aren't valid doesn't seem to be
enough.

--Gavin

Received on Monday, 29 August 2011 20:04:01 UTC