JSON Serialization (was Re: ES4 draft: Name)

# Kris Zyp (18 years ago)

Is there any proposal for how to handle JSON serialization now that we are using Name keyed properties? I know we've discussed this before, but I can't remember where we left off, or if JSON serialization is even still in ES4. The big issue with JSON serialization was how to handle Names with different namespaces, that might have identical identifiers. And related is the question of whether open namespaces have any bearing on serialization (might be a mitigation for collisions). Thanks, Kris

Is there any proposal for how to handle JSON serialization now that we are 
using Name keyed properties? I know we've discussed this before, but I can't 
remember where we left off, or if JSON serialization is even still in ES4. 
The big issue with JSON serialization was how to handle Names with different 
namespaces, that might have identical identifiers. And related is the 
question of whether open namespaces have any bearing on serialization (might 
be a mitigation for collisions).
Thanks,
Kris

# Brendan Eich (18 years ago)

On Mar 20, 2008, at 8:43 PM, Kris Zyp wrote:

Is there any proposal for how to handle JSON serialization now that
we are using Name keyed properties? I know we've discussed this before,
but I can't remember where we left off, or if JSON serialization is even still
in ES4.

JSON was removed because the thinking about best API form factor
shifted toward

json.org/json2.js

That is poised to make a come-back per our last discussion of it at
an Ecma TC39 meeting, but it hasn't reappeared yet.

However, as Doug pointed out, JSON is a language-independent standard,

www.ietf.org/rfc/rfc4627.txt

It has no option for namespace-qualified property names. It also has
no non-finite values with manifest names, or other things JS has. It
differs in Unicode details too, subtly. The point is that JSON need
not grow namespaces just because JS does in ES4.

The big issue with JSON serialization was how to handle Names with
different namespaces, that might have identical identifiers. And related is the question of whether open namespaces have any bearing on
serialization (might be a mitigation for collisions).

When serializing, it's important to isolate and sanitize the object
graph to be serialized. For one thing, it should be a tree. And then
the other restrictions mentioned above come into play. So since JSON
lacks namespaces, you should not be serializing namespace-qualified
property names. And since the current thinking on enumeration by for- in constructs makes all names except those in the compatibility
"noNS" empty namespace DontEnum, there's no need to filter for-in
results.

On Mar 20, 2008, at 8:43 PM, Kris Zyp wrote:

> Is there any proposal for how to handle JSON serialization now that  
> we are
> using Name keyed properties? I know we've discussed this before,  
> but I can't
> remember where we left off, or if JSON serialization is even still  
> in ES4.

JSON was removed because the thinking about best API form factor  
shifted toward

http://json.org/json2.js

That is poised to make a come-back per our last discussion of it at  
an Ecma TC39 meeting, but it hasn't reappeared yet.

However, as Doug pointed out, JSON is a language-independent standard,

http://www.ietf.org/rfc/rfc4627.txt

It has no option for namespace-qualified property names. It also has  
no non-finite values with manifest names, or other things JS has. It  
differs in Unicode details too, subtly. The point is that JSON need  
not grow namespaces just because JS does in ES4.

> The big issue with JSON serialization was how to handle Names with  
> different
> namespaces, that might have identical identifiers. And related is the
> question of whether open namespaces have any bearing on  
> serialization (might
> be a mitigation for collisions).

When serializing, it's important to isolate and sanitize the object  
graph to be serialized. For one thing, it should be a tree. And then  
the other restrictions mentioned above come into play. So since JSON  
lacks namespaces, you should not be serializing namespace-qualified  
property names. And since the current thinking on enumeration by for- 
in constructs makes all names except those in the compatibility  
"noNS" empty namespace DontEnum, there's no need to filter for-in  
results.

/be