Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27)


(To clarify first: my goal on this thread is to focus on the JSON/JSON-LD question, not the details of the request message.)

You wrote:
> The Web Payments API uses messages that look like JSON to the average Web developer (but are 
> in-fact, JSON-LD - nothing is "undefined behavior" and the rules for extensibility are clear).

I would rather it be: "The Web Payments API uses JSON. For some processors, it turns out it is also JSON-LD and those processors can consume it as such. But for conforming implementations of the API, it only needs to be known as JSON."

>    The spec does not require the browser to interpret the Web Payments API messages as JSON-LD 
> (the behavior is hard-coded for the pieces that the browser has to process). This means that browsers 
> can treat the bits of the JSON-LD that they use as plain 'ol JSON.

Yes, that sounds consistent with my note above.

> If a JSON-LD Context is not defined, one must be assumed 
> (the Web Payments Version 1.0 JSON-LD Context).

I don't think I agree with that because it requires something of processors
related to JSON-LD. How about this instead:

 - The Web API spec defines the meaning of the terms that are used.
 - "Custom data" is designated as such explicitly; there is a well-defined way to designate "this is
    data for applications and must be left unchanged by conforming processors."
 - Everything else triggers an error. We need to look more closely at error handling in the sensitive
   case of payments.

Then, if the custom data includes context and the application knows how to consume JSON-LD,
then a conforming processor of JSON-LD will do the right thing.


Reply to this email directly or view it on GitHub:

Received on Tuesday, 2 February 2016 18:58:09 UTC