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?


Reply to this email directly or view it on GitHub:

Received on Thursday, 7 January 2016 19:18:34 UTC