Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)

>> I think doing that would be a bad idea as you end up, in time, w/ certain organizations is-implementing the basic context

> I'm not sure why that follows.

You said make the grounding implicit. When you don't make a grounding explicit, you leave a developer with room to add extra bits in that could be problematic as the system evolves.

That doesn't always follow, but it sometimes does and those "sometimes" cases can cause fairly significant interoperability problems.

For example - do we allow or prevent organizations from putting a (today) non-standard "referenceId" into a payment message? If we don't explicitly ground the context, we definitely allow for that. What happens when a developer adds in something that we don't account for in our "implicit" grounding?

I think many of us who desire the basic message format to be extensible, would want to allow a company to put in a referenceId if it solved a business problem for them (even though the specification does not say that 'referenceId' is a known term). We should, however, make the grounding of that term explicit - how does the ecosystem process 'referenceId'? We should have an answer for that question, and my concern is that an implicit grounding doesn't answer that question.

Now, consider in v2 that we think 'referenceId' is a good idea (without knowing that other applications have started using it). If we go with an implicit grounding, and we launch v2, then all of a sudden we have a problem. Old systems w/ old messages w/ referenceId will now conflict w/ new systems w/ old messages (again, because the grounding is implicit, there is no way to tell an old message from a new message).

---
Reply to this email directly or view it on GitHub:
https://github.com/WICG/paymentrequest/issues/35#issuecomment-169774713