Subject: [Json] Small ABNF change to do some semantic separation

From: Barry Leiba <[email-masked]>
Date: Sun, 22 Sep 2013 11:16:27 -0400

The repute working group has defined a response object in JSON.[1]  At
first they did it using ABNF.  That means that it (badly) duplicated
the ABNF that's already in 4627, trying to say where "ws" can go,
defining what has to have DQUOTE around it (for which the repute doc
used "%x22"), worrying about when to use value-separator and when to
use name-separator (and sometimes using "," instead, in some
versions), using "{" instead of citing begin-object, and so on.  It
was messy, error-prone, and subject to deviations from JSON ABNF if
that should change.

In the -13 version of the repute document, at my instigation, Murray
changed it to use a definition based on primitives from JSON -- not
ABNF primitives, but JSON primitives, objects and members and arrays,
names and values, strings and ints.  See
draft-ietf-repute-media-type-13, Section 6.2.

I intend, eventually, to write a document suggesting a consistent way
to do this, so others who come to the same place to the same thing in
the same(-ish) way.  The only hassle was that there are some semantic
gaps in the ABNF, which don't affect the grammar per se, but which do
affect how we can refer to the grammar for the semantic elements.  In
particular, "member" is defined as a "string" and a "value", not as a
member name and member value.  And "array" is defined as a set of
"value", losing the semantic distinction between a member value and an
array value.  There's no way to refer to the semantic element that is
the member name, for instance -- the fact that it's syntactically
represented by a "string" is fine, but there's a step missing.

I strongly suggest making a small editorial change to the JSON ABNF,
to separate these semantic entities from their type definitions:

OLD
member = string name-separator value
NEW
member = member-name name-separator member-value
member-name = string
member-value = value
END

OLD
array = begin-array [ value *( value-separator value ) ] end-array
NEW
array = begin-array [ array-value *( value-separator array-value ) ] end-array
array-value = value
END

This doesn't change how JSON is represented in the ABNF, but it allows
us to better use the ABNF to refer to the semantic elements.

Barry

[1] See https://datatracker.ietf.org/doc/draft-ietf-repute-media-type/

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 22 Sep 2013 18:36:23 +0200

On Sep 22, 2013, at 17:16, Barry Leiba <[email-masked]> wrote:

> At
> the ABNF that's already in 4627,

We don't have a good way to specialize ABNF.

Because of this, specializing ABNF should never be done:
-- it is very likely that the attempt at specialization will destroy some equivalence relationship that holds in the encoding standard*);
-- it is quite unlikely that the ABNF actually captures what the specialization is about.

Instead, standards using other standards for their encoding should describe their specialization at the data model level.

(This might give a hint about what might be missing from the encoding standards we have.)

Grüße, Carsten

*) This is not a theoretical concern.
E.g., in RFC 6690 we had to take great pains not to accidentally restrict RFC 5988's link-extension production.  We had that wrong for quite some time.  If we hadn't fixed that, we would almost certainly have interoperability problems between parsers that specifically implement RFC 6690 and those that just use an RFC 5988 parser.
Of course, this is much less likely with JSON, which will be parsed with stock JSON parsers, which just means that the ABNF in repute will need to be ignored for interoperability purposes.

---

From: Tim Bray <[email-masked]>
Date: Sun, 22 Sep 2013 10:26:53 -0700

I completely agree with Barry’s objective here.  I had thought one could
unambiguously refer to all the parts of a JSON text using various
combinations of object, array, string, number, boolean, member, member
name, and member value, e.g. “number array value” and “boolean member value”

But if I'm wrong let’s fix that.  Rather than twiddling the ABNF, though,
we could also just introduce a small “terminology” section.  Let me write
up a couple paras and we’ll see how it looks.

Anyhow, this is pretty clearly safe territory because it doesn’t change the
definition of what JSON is or impose any new requirements on producers and
consumers. -T

On Sun, Sep 22, 2013 at 8:16 AM, Barry Leiba <[email-masked]>wrote:

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Sep 2013 08:55:50 -0700

<no hat>

On Sep 22, 2013, at 10:26 AM, Tim Bray <[email-masked]> wrote:

> I completely agree with Barry’s objective here.  I had thought one could unambiguously refer to all the parts of a JSON text using various combinations of object, array, string, number, boolean, member, member name, and member value, e.g. “number array value” and “boolean member value”
> 
> But if I'm wrong let’s fix that.  Rather than twiddling the ABNF, though, we could also just introduce a small “terminology” section.  Let me write up a couple paras and we’ll see how it looks.

The terminology section seems like a much safer idea than changing the ABNF. Having said that, the "implementation guidance" document that many people have proposed as a later work item would probably be a better place for such a section, and we are not in a rush for that text.

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Sep 2013 11:18:15 -0700

Just noticed that I didn’t do anything on this in the -04 draft.  On the
other hand, this thread is pretty short and doing so might have been
overreach.  Speak up if you care.

On Mon, Sep 23, 2013 at 8:55 AM, Paul Hoffman <[email-masked]> wrote:

> > But if I'm wrong let’s fix that.  Rather than twiddling the ABNF,
> though, we could also just introduce a small “terminology” section.  Let me
> write up a couple paras and we’ll see how it looks.
>
> The terminology section seems like a much safer idea than changing the
> ABNF. Having said that, the "implementation guidance" document that many
> people have proposed as a later work item would probably be a better place
> for such a section, and we are not in a rush for that text.
>
> --Paul Hoffman

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Sep 2013 14:24:26 -0400

> overreach.  Speak up if you care.

I'll just say that I think the ABNF change that I suggested is simple
and not risky... but I won't pursue it further if the WG doesn't want
to do it.  I can write a "representing things in JSON" document more
easily and nicely with such a change, but I can do it without that
change also, so I'm not waving my arms wildly and screaming.

Barry

>> > combinations of object, array, string, number, boolean, member, member name,
>> > and member value, e.g. “number array value” and “boolean member value”
>> >

---

From: John Cowan <[email-masked]>
Date: Thu, 26 Sep 2013 14:25:00 -0400

> overreach.  Speak up if you care.

+1.  Cool ABNF Rule Names Don't Change.

-- 
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              [email-masked]
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)