Closed adrianhopebailie closed 7 years ago
Firefox and my favorite json pretty printer do not like the json referenced from @msporny comment on w3c/browser-payment-api#132
http://w3c.github.io/webpayments/proposals/core-messages/schemas/PaymentRequest.json
Firefox says: SyntaxError: JSON.parse: bad escaped character at line 29 column 38 of the JSON data http://jsonprettyprint.com/json-pretty-printer.php says: "null"
I have not seen an argument in the discussion in w3c/browser-payment-api#132 that convinced me not to use the standard WebIDL.
Arguments: Counter Argument
@AxelNennker - I think the core argument is that WebIDL is limited.
i.e. There may be cases where somebody wants to define a payment method that has a data model for the payment method specific data that cannot be modeled in WebIDL because they want to use some more flexible extensibility mechanism.
Ultimately the payment method spec is an interface contract between the payment app and the payee system (or that of their PSP) so they it could be defined in whatever way makes them both comfortable.
My feeling is that we should not prescribe that it must be WebIDL.
I propose we close this. So far the answer is "yes".
Ian
Now closing since answer remains "yes, so far"
Migrated from https://github.com/w3c/browser-payment-api/issues/132
I wonder if we need to use WebIDL in the payment method specifications.
This data is supposed to be passed through the user agent with no processing so I think we could simply use a JSON schema definition of some form or just examples and explanations?
WebIDL is over-kill in my opinion and may be a barrier to payments domain experts defining these specifications (which is what we desire).