W3C home > Mailing lists > Public > public-rdf-wg@w3.org > June 2012

Fwd: Re: [json-ld.org] RDF WG Review: Andy Seaborne (#135)

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Mon, 25 Jun 2012 20:57:15 +0100
Message-ID: <4FE8C29B.6010304@epimorphics.com>
To: RDF-WG <public-rdf-wg@w3.org>
This comment is being discussed outside the WG space but as it relates
to how JSON-LD is defined (or not), I think the WG may have an opinion.

I hope you don't mind me forwarding a publicly accessible comment to the WG.


I agree EBNF is not the right approach.

I think it is possible to define JSON-LD in one place, formally, rather 
than the current describe/prose (e.g turtle mapping syntax to triples). 
  Both are valuable.


On 25/06/12 20:16, Manu Sporny wrote:
> We had discussed this before, right?
> http://json-ld.org/minutes/2012-05-22/#topic-2
> Remember, JSON-LD prescribes best practices and tries really hard to
> not say that something is "illegal". We tend to recover from things
> that we know we can recover from... and EBNF is usually used to throw
> "Syntax Errors" + stop processing, and do other "full-halt" responses
> to invalid input.
> I don't agree that EBNF is the right approach for a formal definition
> of JSON-LD without being very careful with the language. We don't
> want to give the impression that JSON-LD will throw an error if the
> EBNF is not matched perfectly... as in many cases, the value is
> ignored if the EBNF is not matched. There are other rules that we may
> not be able to express in EBNF... things like conditional branching
> based on what's in the @context. We should discuss this off-line
> first to make sure we're on the same page and then raise it again on
> the call if necessary.
> There is a very good reason why we didn't use EBNF to describe what
> is "allowed" in JSON-LD and went with prose instead.
> --- Reply to this email directly or view it on GitHub:
> https://github.com/json-ld/json-ld.org/issues/135#issuecomment-6556889
Received on Monday, 25 June 2012 19:57:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:18 UTC