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 15:22:35 -0800
Cc: Marcos Caceres <marcos@marcosc.com>, public-script-coord <public-script-coord@w3.org>
Message-Id: <034F29A2-88FA-48D6-8F6A-417A537298B8@wirfs-brock.com>
To: Shane McCarron <shane@spec-ops.io>

> On Nov 16, 2016, at 2:22 PM, Shane McCarron <shane@spec-ops.io> wrote:
> Are there instances where it just makes sense to pass the whole thing as a DOMString?  Inside that is JSON, but who cares?  It is just being passed THROUGH the browser to somewhere else.  The Verifiable Claims Data Model work falls into the category, for example.  So does (potentially) the payment method specific data that is in channeled through the browser payments API.  It should NEVER be inspected by the browser payments API implementation.  The contents are opaque.  Might as well just be a string.

That’s a real interesting approach to consider as it eliminates most of the serialization concerns from the API by making it the responsibility of the caller to do the serialization. It should be easy enough for a caller to wrap a JSON.stringify() around the object it would otherwise pass.  It actually make the API more flexible because it allow other approaches other than  using JSON.stringify to create the string.  For example, there may well be cases where it is easier to use a template string to construct a string containing a specific JSON text then it is to construct an object graph that will serialize  to that same JSON text.  Also, it would permit a client to store or cache pre-serialized JSON texts without having to deserialize on each use. 

Received on Wednesday, 16 November 2016 23:23:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC