On Tue, Jan 8, 2013 at 12:17 PM, Markus Lanthaler <markus.lanthaler@gmx.net>wrote: > On Monday, January 07, 2013 7:30 PM, Gregg Kellogg wrote: > > > AFAIK, W3C standard is EBNF, and I did make an attempt at an EBNF > > grammar some time ago, but the consensus of the group was that this > > wasn't too useful. The fact that it's JSON, and pretty much every > > implementation will use a JSON parser and iterate of the resulting > > objects, I still think this is probably not too useful for the purposes > > of implementing a processor. > > Right. That's the reason why I didn't use EBNF. I wouldn't like to include > rules to parse JSON itself, just the grammar on top of JSON but > unfortunately there doesn't exist such a thing yet. > Wouldn't it be relevant to use JSON-Schema [1], then? I've used it in the past and found it quite nice useful... However, it is not a finalized spec and has not evolved in the last two years, so that may be inappropriate for a W3 REC. pa [1] http://json-schema.org/ > > > However, I can see that laying out different node types, and what the > > expected key/value pairs that can be expected. As you note, we do this > > in prose now, but something that is more visual might be easier for > > people to understand. For this purpose, we can probably invent our own > > nomenclature, as long as it's consistent and light-weight. What you > > have below is pretty easy to understand, IMO. > > That's the intent behind it. While you are implementing a JSON-LD > processor, > validator, linter etc. you probably quite often need to check what's > allowed > and what's not. Reading through prose isn't really productive and you risk > missing some details. That's why I tried to come up with something more > formal and condensed. > > > Cheers, > Markus > > > > -- > Markus Lanthaler > @markuslanthaler > > >Received on Wednesday, 9 January 2013 07:33:12 GMT
This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:53 GMT