Subject: [Json] Possible next work for the WG

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Oct 2013 19:51:50 -0700

Greetings again. While our AD ponders the 4627bis document (probably on its way to IETF Last Call), the Working Group can start to think about what it wants to do next, if anything. The chairs have heard of at least four topics that the WG might or might not want to add to its charter:

- I-JSON (a profile of JSON with some interoperability issues nailed down)

- Best practices document for JSON implementers and folks who use JSON in protocols

- Canonicalization rules so that two JSON texts can be compared for equality

- Requirements for JSON schema (which will be needed before the WG considers working on an actual schema)

The chairs request general comments on these or additional topics for the WG. If there is interest, we will re-open the topics on separate threads, and then put together a proposal for rechartering. If people really want this WG to shut down after 4627bis is done without doing additional work, that is a valid view as well. 

Note that we have also heard requests for non-compatible additions to the JSON syntax, particularly for comments and byte-oriented data. If the WG wanted to adopt this work, we would probably need to talk with our ADs and the IAB because that might be better handled by Ecma in a possible revsion to ECMA-404.

--Matt Miller and Paul Hoffman

---

From: John Cowan <[email-masked]>
Date: Wed, 16 Oct 2013 12:54:06 -0400

> - Best practices document for JSON implementers and folks who use JSON

I think these are both worthy ideas, though perhaps they can be merged.

> - Canonicalization rules so that two JSON texts can be compared for equality

I think we should explore this, but it's going to be tricky.

> considers working on an actual schema)

As reinvented wheels are often hexagonal, I think if we are going to
do this we should adopt draft-zyp-json-schema-04 as a base document
for further work.  This has now expired, but is still available at
<https://raw.github.com/fge/json-schema-validator/master/misc/specs/draft-zyp-json-schema-04.txt>.

I note that this draft proposes "application/schema+json" as the media
type for JSON schemas.  That leads me to believe we should make "*/*+json"
official, parallel to "*/*+xml" per RFC 3023.  I'll post on that separately.

-- 
John Cowan      [email-masked]        http://www.ccil.org/~cowan
        Is it not written, "That which is written, is written"?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Oct 2013 10:13:54 -0700

<no hat>

On Oct 16, 2013, at 9:54 AM, John Cowan <[email-masked]> wrote:

> for further work.  

That draft is a specific schema proposal, not a set of requirements. If the WG first agrees on a set of non-ocean-boiling requirements, proposals to meet them will naturally follow. This would not be reinventing: it would be designing from requirements instead of the other way around.

--Paul Hoffman

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 16 Oct 2013 19:19:59 +0200

On Wednesday, October 16, 2013 6:54 PM, John Cowan
> I think these are both worthy ideas, though perhaps they can be merged.

Completely agree

> I think we should explore this, but it's going to be tricky.

+0

> <https://raw.github.com/fge/json-schema-
> validator/master/misc/specs/draft-zyp-json-schema-04.txt>.

I don't think we should start work on this without someone (better yet, a
group of people) actively pushing for it. Just look at the history of JSON
Schema..

> official, parallel to "*/*+xml" per RFC 3023.  I'll post on that

That has already been done in RFC6839

--
Markus Lanthaler
@markuslanthaler

---

From: Barry Leiba <[email-masked]>
Date: Wed, 16 Oct 2013 13:21:27 -0400

> Greetings again. While our AD ponders the 4627bis document
> (probably on its way to IETF Last Call), the Working Group can
> start to think about what it wants to do next, if anything. The
> chairs have heard of at least four topics that the WG might or
> might not want to add to its charter:
...
> - Best practices document for JSON implementers and folks who

As I've mentioned, I'd like to do a document about guidelines for
defining JSON objects in other documents/protocols, to make sure that
we use JSON primitives for those definitions, and don't try to
duplicate JSON grammar in ABNF.  See Section 6.2 of
draft-ietf-repute-media-type-13 (currently in the RFC Editor queue)
for an example, and look at Section 6.1.1 of version -12 of that
document for the ABNF version of how I think it should NOT be done.

Such a document could be on its own, or it could be part of the best
practices document Paul mentioned.

Barry

---

From: Tim Bray <[email-masked]>
Date: Wed, 16 Oct 2013 10:24:13 -0700

> - I-JSON (a profile of JSON with some interoperability issues nailed down)

This, frankly, is the only real reason I’ve invested work in this group and
agreed to edit the -bis.  I want something that people who really rely on
getting clean JSON can point to and say “do this” and not have to write any
extra rules.

- Best practices document for JSON implementers and folks who use JSON in
> protocols

Nothing wrong with the idea, but I think that if we do the -bis and then
I-JSON, it’d be superfluous.

> - Canonicalization rules so that two JSON texts can be compared for

History would seem to show that this requires substantial effort and has
very modest pay-off. Also, there are lots of success stories around
digitally-signed JSON already in deployment, which seems to weaken one of
the use-cases for canonicalization.  I’d argue for passing on it.

> considers working on an actual schema)

I would argue against this because designing schema languages is a crushing
amount of work and easy to get wrong.  Also, in the domain I care about
(RESTful protocol payloads) the benefit seems small.  There is a certain
amount of code you could remove, I suppose, of the form

if json['person']['id-num'] == nil
  // reject transaction with an error message about how the id-num is
required
end

but pushing the Sysiphean schema-language-design rock up the hill feels
like hitting a beetle with a boulder.

>
> The chairs request general comments on these or additional topics for the
> WG. If there is interest, we will re-open the topics on separate threads,
> and then put together a proposal for rechartering. If people really want
> this WG to shut down after 4627bis is done without doing additional work,
> that is a valid view as well.
>
> Note that we have also heard requests for non-compatible additions to the
> JSON syntax, particularly for comments and byte-oriented data. If the WG
> wanted to adopt this work, we would probably need to talk with our ADs and
> the IAB because that might be better handled by Ecma in a possible revsion
> to ECMA-404.
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Tim Bray <[email-masked]>
Date: Wed, 16 Oct 2013 10:25:19 -0700

+1 to Barry. This would be super-useful, independent of whether we do
I-JSON or not.

---

From: John Cowan <[email-masked]>
Date: Wed, 16 Oct 2013 13:28:31 -0400

Paul Hoffman scripsit:

> Greetings again. While our AD ponders the 4627bis document (probably on
> its way to IETF Last Call), the Working Group can start to think about
> what it wants to do next, if anything. The chairs have heard of at least
> four topics that the WG might or might not want to add to its charter:

application/json fragment identifiers should be added to this list.
There seems to be a fairly mature proposal along the lines of the XPointer
"element" scheme.  Some people don't like it because you can't tell by
examining a fragment id what type of JSON value it references.  By the
same token, however, you can't tell by examining a URI pointing to a
JSON document what JSON type it references either.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
The whole of Gaul is quartered into three halves.
        --Julius Caesar

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 16 Oct 2013 13:41:04 -0400

Hi Barry,

> document for the ABNF version of how I think it should NOT be done.

Yes! And also please look at 
<http://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03#section-5> 
which makes use of 
<http://tools.ietf.org/html/draft-newton-json-content-rules-01> as another 
way to describe the "format" of a JSON document.

-- 
Cyrus Daboo

---

From: Jacob Davies <[email-masked]>
Date: Wed, 16 Oct 2013 10:52:42 -0700

> I think we should explore this, but it's going to be tricky.

Very tricky if we stick to the idea that JSON is only a text format and
does not describe an abstract data model. Who is to say whether 4.5 and
4.500 were supposed to be equivalent? 0 or -0? Or whether the ordering of
keys in an object matters? (It matters to me that the order is preserved
but not that it is included in equality comparisons, but that's just me.)

> <
https://raw.github.com/fge/json-schema-validator/master/misc/specs/draft-zyp-json-schema-04.txt
>.

How to phrase this: I would be curious how much actual use is made of JSON
Schema or any other formal schema system for JSON. If there are people here
who've found them useful, I think it would be interesting to discuss what
kinds of uses they made of them.

I don't know the history of JSON Schema but the specific link you point to
is pretty obscure (i.e. provide no actual starting point for using it). An
older draft seems to be a bit clearer:
http://tools.ietf.org/html/draft-zyp-json-schema-03

I find the syntax overly verbose and not very idiomatic - e.g. requiring:

   "name":{"type":"string"},

instead of just "name" : "string", and requiring an intermediate
"properties" element when defining objects, but those could be fixed.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Oct 2013 08:53:11 -0700

<no hat>

On Oct 16, 2013, at 10:24 AM, Tim Bray <[email-masked]> wrote:

> This, frankly, is the only real reason I’ve invested work in this group and agreed to edit the -bis.  I want something that people who really rely on getting clean JSON can point to and say “do this” and not have to write any extra rules.
> 
> Nothing wrong with the idea, but I think that if we do the -bis and then I-JSON, it’d be superfluous. 

Maybe combining the two parts in that bullet point (for JSON implementers, for JSON use in protocols) was a bad idea. The latter has nothing to do with what was in the earlier discussion of I-JSON.

If the WG proceeds with I-JSON, do people have a feeling about what might go into a best practices document for implementers that isn't in I-JSON?

--Paul Hoffman

---

From: R S <[email-masked]>
Date: Thu, 17 Oct 2013 19:30:07 -0700

There's already an RFC for that. <http://tools.ietf.org/html/rfc6901>

- Rob