Re: Issues found in Turtle spec

Thanks for the quick follow up! I'll get an update out straight away with issues addressed

On Aug 29, 2011, at 1:03 PM, "Gavin Carothers" <gavin@topquadrant.com> wrote:

> 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

No change for me yet, I guess. Hopefully, you'll have an update to the Turtle test suite (or just a new suite)which exercises the corner cases.

>> 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.

By examples, I meant those that are often sent around informally, which used to parse. It seems reasonable that this usage pattern might still be used, but if there are compelling reasons not to, I understand.

I'll remove that bit of logic.

>> 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 ;)

Well, given the rather week spec for EBNF, it's hard to tell if it's valid. Perhaps you could expand on it's interpretation.

>> 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.

FWIW, I don't find ( ... ) very useful, but, e.g., '[ a <node> ] .' can be useful. I'd suggest adding a production to support it.

> --Gavin

Thanks again for the great work in formalizing Turtle.

Gregg

Received on Monday, 29 August 2011 21:13:08 UTC