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

@dlongley, 

> I strongly recommend against trying to stuff everything we haven't thought of into a box marked "custom". There are a lot of things we haven't thought of. Instead, let's specify what we have thought of and leave the rest alone.

I have a specific goal in mind: tell the processor to leave some data untouched, so that a processor does not treat it as an error. I am not trying to "stuff everything we haven't thought of in a box." I only am thinking of one scenario we should consider. (Again, "custom" may not be the right approach; I am looking for help to understand whether this is a pattern.)

> Furthermore, I think we should be specific about a best practice for extending: i.e. let's specify an extension mechanism that is machine-readable, has decentralized, self-discoverable semantics, has a syntax that already works as regular JSON, and is a W3C Recommendation: JSON-LD. 

It is one thing to say "You must use JSON-LD for extensions" and another to say "Please consider using JSON-LD if you want integration into the world of linked data." 

> We can be clear about how people ought to interpret messages as JSON-LD -- should they be interested in using this mechanism. If they aren't, that's fine too.

If the content is JSON-LD and can be recognized as such, conforming processors of the data will do the right thing. That is not something the Web API spec needs to say (at least I have not been convinced yet we need to say it since the data seems to be self-describing by virtue of the presence of @context). 

> I realize this work is phased and we're trying to keep things narrowly scoped. That doesn't mean we shouldn't be clear about how to extend things so we can get to the future we want in later phases and beyond. 

I believe we should not today tell people there is only one way to extend the data. We should take pains so that we don't prevent people from trying different approaches. In the future we may find that further standardization on a particular approach will further interop. I do not support choosing a specific extension mechanism (other what what you get from plain JSON) without more experience.

> For example, I'm imagining a future where people could publish payment request messages (or "offers") on websites using JSON-LD. Then search engines could consume this machine-readable data (Google is already doing this with JSON-LD). Then people could search for what they're looking for and click it -- which would drop that message right into the Browser API and they could complete their purchase.

It seems to me that a Web API spec requiring conformance to JSON would do the right thing (provided the payment app knows how to handle the data you feed it). Am I mistaken?

> They could similarly drop that same message into an app that uses the HTTP API and send it where it needs to go. Or into some other API. The point is that you can use the same message across many APIs and you can get these messages in a variety of different ways.

As I've mentioned elsewhere on threads, I share the goal of avoiding divergence between the JS and HTTP APIs. I do not consider it a requirement that the APIs use the same data (and there may be good reasons not to, such different security requirements in different ecosystems). But I agree it would be good to avoid unnecessary divergence. 

> I think it's important that we provide some guidance on how this can be done -- even if that's an extremely minimal amount of guidance during Phase I, i.e. there's a "default" context for people who want to use messages as JSON-LD.

Perhaps that's an idea worth discussing more broadly:

 * The Web API spec requires JSON (not JSON-LD) but does not prohibit the data from being JSON-LD. (Let's assume for now that can be done.)
 * The WPWG publishes a companion spec that says "If you want to use JSON-LD, here's how you do it."
 
Ian



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