Re: [w3c/browser-payment-api] Should Payment Method Identifiers and Messages be expressed using a Linked Data Vocabulary? (#45)

We resolved that the API specification will have no dependency on JSON-LD but that data passed to the API should be passed on to payment apps (and visa versa) opaquely such that if it is JSON-LD (and therefor contains members such as `@context` or `@vocabulary` etc) these will not be stripped out.

On the back of that there was discussion around producing a document that provided guidance on extensibility detailing how JSON-LD may be used to acheive this.

I don't believe we are all on the same page yet with regard to the need to produce a JSON-encoded payment request out of the back of the API (to be passed on to payment apps). We need to agree that this is a requirement first before we talk about how we will extend that JSON object. I can see how anyone that doesn't consider that a requirement would be wondering what this question even means with regard to "Messages". (With regard to payment method identifiers there is #10 and #11 which, if resolved will either recommend the use of a Linked-Data dictionary or not)

Right now the only extension point defined for the browser API is the ability to pass custom payment method data into the request. It's possible that a future payment method specification will use JSON-LD as a means of describing the custom data that it uses but to date the only proposals/specs put forward (Basic Card and SEPA) do not. 

I'm not going to close this issue but I don't see the WG making any progress on resolving it at such an abstract level without some concrete proposals that demonstrate exactly what the Linked Data vocabulary options would look like.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/45#issuecomment-211553961

Received on Monday, 18 April 2016 20:07:56 UTC