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

> 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?

Behavior is undefined. It's the same with explicit grounding and unknown short labels.

> 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.

My suggested extensibility mechanism is a single URI. I don't think we should optimize for identifier length/simplicity in the extension case. So people can extend as needed with a full URI and provide whatever applications need to know at that URI. 

So the implicit grounding is only for WG-approved short strings, and those are defined in the specification referenced by the API.

> How is versioning at the API level done?

I don't have any suggestions here (because I am not an API designer). I would look to see how other APIs manage versioning as I imagine that's not a new problem.

> That we're likely to define more than one API is exactly why 
> the messages have meaning outside of an API. Data has meaning outside of an API.

I chose my phrase poorly and appreciate your reply. So I'll rephrase: 

* I personally don't think it is high-priority design goal that the data be reusable outside of some API that we are designing (whether JS or HTTP). While in the abstract I see the value (1) I don't think we've discussed a concrete use case that is driving this and (2) there is a cost in terms of verbosity and brittleness.
* If we can factor out the message data to make it easier to design our APIs, that seems useful (but not mandatory).

This sounds like a question to put to the group: what is the priority that the message data be designed to be reusable (meaningful, grounded, etc.) outside of the context of some API defined by the group?

Ian

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