W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2016

JSON-serializable object

From: Marcos Caceres <marcos@marcosc.com>
Date: Tue, 15 Nov 2016 22:17:04 -0800
Message-ID: <CAAci2aBdFbuQUWFOQpEtwuRwaGiN7Hnt=q7DP5MFWE1qWo-+hw@mail.gmail.com>
To: public-script-coord <public-script-coord@w3.org>
The Web Payment spec has the following concept defined [1]:

> The term JSON-serializable object used in this specification means an object that can be serialized to a string using JSON.stringify and later deserialized back to an object using JSON.parse with no loss of data.

See [2] for example in prose.

However, it doesn't define how a UA actually would check the above...
apart from basically calling:

```JS
try {
   JSON.parse(JSON.stringify(obj));
} catch(err){
   throw new Error("Not a JSON-serializable object");
}
```

The concept of a "JSON-serializable object" seems somewhat related to
structured clones/transferables (kinda, sorta... though of course
clones support some more sophisticated types/interfaces). I'm
wondering if public-script-coord can help (either through WebIDL or
TC39) with creating something more concrete that implementations can
rely on. I'm pretty sure this has been discussed before numerous
times, but I can't recall what conclusion we reached and if this is
already a solved problem.

Kind regards,
Marcos

[1] https://w3c.github.io/browser-payment-api/#dfn-json-serializable-object
[2] For example, "Set the details attribute value of response to a
JSON-serializable object containing the payment method specific
message that will be used by the merchant to process the transaction.
The format of this response will be defined for each payment method."
You can see numerous instances of JSON-serializable object throughout
the spec.
Received on Wednesday, 16 November 2016 06:17:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 November 2016 06:17:39 UTC