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

Re: JSON-serializable object

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Wed, 16 Nov 2016 09:20:29 -0800
Message-Id: <0A6DC533-60DF-4E0B-B69B-DEA9624E1E45@wirfs-brock.com>
Cc: public-script-coord <public-script-coord@w3.org>
To: Marcos Caceres <marcos@marcosc.com>
This whole “JSON-serializable object” concept seems rather bogus and unhelpful.  There are many reasons why a client might associate JSON.striingify "lossy data” (non-enumerable properties, built-in or object specific private state, own methods with local objects, non-indexable properties on an Array, etc) with objects for local processing purposes while still providing good&complete JSON data for the wire.

Also, because of all the dynamic hooks (toJSON methods, accessor properties, Proxies, etc) there is no way to pre-verify that JSON.stringify won’t throw other than by actually running JSON.stringify and running it multiple times may not yield the same result string.  So, you should giveup on trying to “preflight” any such API arguments and deal with the reality that the ultimate application of JSON.stringify might throw.

In the payment request spec. most (perhaps all) of the uses of “JSON-serializable” data is to transmit JSON encoded data whose actual schema is defined elsewhere. For example, to encode “a payment method specific message used by the merchant to process the transaction and determine successful fund transfer”.  The payment method will have to define the expected message in terms of one or more specific JSON schema (specific object properties, etc.) and the payment processor is going to have to validate that the message conforms to the schema.  A “JSON-serializable object” that does not serialize to one at the expected schema is going to cause the processor to reject the transaction.  So, what value is there for the client side API to validate for “JSON-serializable object” when it can’t validate the actual schema.

So, what should a spec say when its API needs to accommodate open-end JSON-encodable objects?  I suggest tagging such objects as [Stringified] which is defined something like:
[Stringified] This object is subject to serialization using JSON.stringify and the resulting JSON text is used for subsequent processing.  It is the caller’s responsibility to pass an object that will JSON.stringify to a JSON text that is valid for the subsequent processing steps. 
Received on Wednesday, 16 November 2016 17:20:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 November 2016 17:21:00 UTC