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

> Can you attempt to characterize what such a message would look like and why it would be superior to just using the existing dogfood that is JSON-LD?

@halindrome We can't define a browser API that simply takes an untyped object as its parameter and then define the schema for that object in JSON-LD. Browser APIs take well-defined objects as parameters. Anything else is a non-starter. So, WebIDL is a bare minimum encoding. What Ian is suggesting is that taking a JSON object that conforms to a WebIDL definition and adding a context and type is a trivial and will produce compliant JSON-LD if the context is defined to align with the WebIDL definition.

@vkuntz :+1:  - as you correctly point out we are defining the technical level (the encoding) because this is the level that will be required for the browser API. I think the group acknowledges that the logical message schema is yet to be finalized but that this issue is a lingering difference between the two proposals so it will help us progress if we can resolve it. (Correct me if I am wrong)

>From the discussion I understand the requirements to be:
* A request (and response) object (a Plain-Old-Javascript-Object) with a well defined schema that is passed to (and returned by) the browser API 
* Easy translation between the POJO object passed to (returned by) the browser API and a JSON-LD encoded message that may be passed outside of the browser's execution environment (example: via an HTTP API)
* A mechanism for developers to extend both the POJO object and it's JSON-LD equivalent to add custom data for their needs (example: payment method specific extensions) without altering the elements of the message schema that are used by the browser internally.

I propose the following:
 1. The group must still agree upon a **logical message schema** (i.e. irrespective of the encoding format) and therefor this proposal relates only to the way the group will express this schema when it publishes it's specifications
 1. The group will define a payment request object and a payment response object using **WebIDL** and developers will pass plain Javascript objects to the API (and expect the same as return values)
 1. The definitions will specify appropriate optional attributes that can be used by developers to carry custom data such as payment method specific data.
 1. The conformance criteria for browsers implementing the API will be to accept and process these request objects appropriately and to return valid response objects that comply with the schemas defined by the group.
 1. Conformant browsers will be expected to ignore and pass on any attributes that are not defined in the specification.
 1. The group may define a JSON-LD context that aligns with the WebIDL definitions such that a POJO object that is compliant with the WebIDL definition will by virtue of that be valid JSON-LD by simply specifying this newly defined context and the appropriate type (payment request or payment response).

*I consider the definition of the JSON-LD context to be tightly tied to the definition of the HTTP API so I expect this to be done later, in conjunction with this work. I'd like to say the group WILL define this JSON-LD context but I don't want to confuse a discussion around encoding formats for the browser API with a discussion around other deliverables*


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/27#issuecomment-178809201