Re: JSON-serializable object

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.

On Wed, Nov 16, 2016 at 12:20 PM, Allen Wirfs-Brock <allen@wirfs-brock.com>
wrote:

> 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.
>
>


-- 
Shane McCarron
Projects Manager, Spec-Ops