Subject: [Json] JSON data model

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Aug 2013 23:56:09 +0200

Today at the interim, there was some recollection of the enormous pain that ensued in the XML community when they had to define their data model (infoset).  

One of the reasons people like JSON over XML is that there is no such pain.

I have written up the JSON data model below (I allowed about five minutes, please excuse stupid mistakes).  Much of the text is already in 4627, by the way (but I didn't bother to copy it verbatim).  I don't know whether and how we would use that model in 4627bis, but I'd sure like to know if anyone disagrees with the fact that this is the JSON data model (modulo word-smithing).

Grüße, Carsten

A JSON value is one of:
- a special value
- a string
- a number
- a structured value.

A special value is one of true, false, or null.

A string is a sequence of zero or more Unicode characters.

A number is a rational number that can be expressed as a fraction of two integers where the denominator is a power of ten.

A structured value is an array or an object.

An array is an (ordered) sequence of zero or more JSON values.

An object is an unordered collection of zero or more key-value pairs, where a key is a string, a value is a JSON value, and the same key cannot be used more than once in the same collection.  For the purposes of this comparison, two keys are the same if they are the same sequence of Unicode characters.

---

From: Stephan Beal <[email-masked]>
Date: Thu, 22 Aug 2013 00:00:43 +0200

On Wed, Aug 21, 2013 at 11:56 PM, Carsten Bormann <[email-masked]> wrote:

> An object is an unordered collection of zero or more key-value pairs,
> where a key is a string, a value is a JSON value, and the same key cannot
> be used more than once in the same collection.  For the purposes of this
> comparison, two keys are the same if they are the same sequence of Unicode
> characters.
>

Amen!

Ship it!

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal

---

From: Nico Williams <[email-masked]>
Date: Wed, 21 Aug 2013 17:43:39 -0500

Last I checked the consensus was not that we could say "MUST NOT" have
dup keys.  Now, your data model text doesn't say that -- it's just a
data model, right?  So it's agreeable on that score (ditto strings and
numbers).  This can't cause subsequent agreement on such a
requirement, so what do we get from this data model?  Likely answer:
stop the rot.

Nits:

 - if we're going to speak of structured values vs. not, then let's
call them scalars and structured
   (ideally we could use common terminology, but I hesitate to pick
one; if I were to suggest ASN.1's "constructed" instead of
"structured" I'd get tomatoes thrown my way)

 - booleans are not special, IMO; they are booleans, so call them that

 - that leaves null as the only special value

 - do we want to speak of a type system?  some programming languages
have null as a type, of which null is the only possible value, which
speaks to null not being special

 - i.e., there are no special values, even null is not that special :)

Or if there's a reason that null, true, and false are special, we
should state it.

Nico
--

---

From: Tim Bray <[email-masked]>
Date: Wed, 21 Aug 2013 16:09:17 -0700

I don’t understand what value would be added by having this in the RFC.
JSON has already been terrifically successful, and the interoperability
nits we know about have nothing to do with model-level misunderstandings.

There are a bunch of different data models I could use for {"a": 1, "b":
false}  and picking any one of them feels like it’s potentially deceiving.

  -T

On Wed, Aug 21, 2013 at 2:56 PM, Carsten Bormann <[email-masked]> wrote:

> Today at the interim, there was some recollection of the enormous pain
> that ensued in the XML community when they had to define their data model
> (infoset).
>
> I have written up the JSON data model below (I allowed about five minutes,
> please excuse stupid mistakes).  Much of the text is already in 4627, by
> the way (but I didn't bother to copy it verbatim).  I don't know whether
> and how we would use that model in 4627bis, but I'd sure like to know if
> anyone disagrees with the fact that this is the JSON data model (modulo
> word-smithing).
>
> Grüße, Carsten
>
> A JSON value is one of:
> - a special value
> - a string
> - a number
> - a structured value.
>
> A number is a rational number that can be expressed as a fraction of two
> integers where the denominator is a power of ten.
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Aug 2013 01:37:38 +0200

> it's just a
> data model, right?

No, I'm making the strong claim that this is *the* JSON data model.
I'm writing this up because I'd like to meet any people who make a serious claim that this is not so.

(Of course, there is an unlimited number of isomorphic data models where things are called in different ways or grouped in different ways, whatever.  Consider this claim to be about the class of isomorphic data models.)

What is allowed to be interchanged (by an imaginary protocol police?), and whether there is a unique mapping into this data model (or any defined mapping at all) for everything that is allowed to be interchanged, is a second question that I have not addressed.  Ideally, a data format should have the property that all representations have such a unique mapping.  I think we have already agreed that JSON, as deployed, is not ideal.

A third question is whether the data model is faithfully implemented by every implementation.  The discussion about numbers should have made clear that almost all implementations map JSON numbers into whatever local approximation is convenient, and range limits (but not loss of precision) are already explicitly called out in section 4.  All implementations also have size limits and other quantities creating a subset of the data model that can be represented.  More interestingly, a number of processes can be implemented on JSON texts that do not need to make use of the data model (pretty-printing is the trivial example, although that also can involve some cleanup that does require maintaining the data model; and some implementations convert JSON texts from an internal UTF-16 representation to UTF-8 before interchange) or that adapt the data model in some way (streaming processors do not reify even an approximation of the data model).

And so on, and so on.  The data model isn't everything.  But if I understand Larry correctly, I agree with him that it is worthwhile to identify it and to define things in relation to it.

Grüße, Carsten

---

From: John Cowan <[email-masked]>
Date: Wed, 21 Aug 2013 20:42:24 -0400

> No, I'm making the strong claim that this is *the* JSON data model.

Well, in my implementation, the model of objects is a Lisp a-list
of the form ((jso) (<key> . <val>) (<key> . <val> ) ...), so tant pis.

-- 
Deshil Holles eamus.  Deshil Holles eamus.  Deshil Holles eamus.
Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!
  --Joyce, Ulysses, "Oxen of the Sun"       [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Wed, 21 Aug 2013 22:00:01 -0500

Yeah, this isn't going to happen either.  What can I say but "give it
up, accept the rough consensus (and running code)".

---

From: Larry Masinter <[email-masked]>
Date: Fri, 23 Aug 2013 12:34:33 -0700

I think just that it is useful to have an abstract data model which can be used to explain interoperability issues. I don't think it needs to be normative.
=================

Interoperability issues

It is useful to think of JSON at four levels, with well-known transformations between the levels:

stream of bytes <--> stream of Unicode code points <-> data model <-> programming language data

While implementations may not ever instantiate the " data model", most of the interoperability issues are due to weaknesses (incomplete mapping) of the mapping between data model <-> programming language data:

Example 1: some numbers in the data model can't be represented in the programming language (because of precision or range), and some numbers in the programming language data can't be represented in the data model (e.g., NaN, Infinity).

Example 2: The JSON MIME type (stream of bytes) and the "stream of Unicode code points" do not disallow duplicate keys; some programming language implementations also support duplicate keys (e.g., a Lisp a-list representation). But the data model does not support duplicate keys, and duplicate keys will have poor interoperability. 

Example 3: All four levels allow unmatched surrogate pairs of Unicode code points.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Carsten Bormann
> Sent: Thursday, August 22, 2013 1:38 AM
> To: Nico Williams
> Cc: [email-masked]
> Subject: Re: [Json] JSON data model
> 
> > it's just a
> > data model, right?
> 
> (Of course, there is an unlimited number of isomorphic data models where
> things are called in different ways or grouped in different ways, whatever.
> Consider this claim to be about the class of isomorphic data models.)
> 
> What is allowed to be interchanged (by an imaginary protocol police?), and
> whether there is a unique mapping into this data model (or any defined
> mapping at all) for everything that is allowed to be interchanged, is a second
> question that I have not addressed.  Ideally, a data format should have the
> property that all representations have such a unique mapping.  I think we have
> already agreed that JSON, as deployed, is not ideal.
> 
> A third question is whether the data model is faithfully implemented by every
> implementation.  The discussion about numbers should have made clear that
> almost all implementations map JSON numbers into whatever local
> approximation is convenient, and range limits (but not loss of precision) are
> already explicitly called out in section 4.  All implementations also have size
> limits and other quantities creating a subset of the data model that can be
> represented.  More interestingly, a number of processes can be implemented
> on JSON texts that do not need to make use of the data model (pretty-printing
> is the trivial example, although that also can involve some cleanup that does
> require maintaining the data model; and some implementations convert JSON
> texts from an internal UTF-16 representation to UTF-8 before interchange) or
> that adapt the data model in some way (streaming processors do not reify
> even an approximation of the data model).
> 
> And so on, and so on.  The data model isn't everything.  But if I understand
> Larry correctly, I agree with him that it is worthwhile to identify it and to define
> things in relation to it.
> 
> Grüße, Carsten
>