W3C home > Mailing lists > Public > public-payments-wg@w3.org > January 2016

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

From: ianbjacobs <notifications@github.com>
Date: Thu, 07 Jan 2016 10:16:12 -0800
To: WICG/paymentrequest <paymentrequest@noreply.github.com>
Cc: webpayments <public-payments-wg@w3.org>
Message-ID: <WICG/paymentrequest/issues/35/169761035@github.com>

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

> We should make the processing rules explicit,

We would, via the specification of the API.

> We could also say in the spec that in the absence of a context, all Web Payments messages MUST 
> assume a context of "https://w3id.org/payments/v1". This is, of course, a compromise and I hope the 
> group wouldn't make this the recommendation for developers.

I understand that approach, but in the end, it amounts to providing two pieces of information (a URL and a short string that's separate from it). It seems simpler that when you want to extend beyond the specificaiton, you provide just a single URL. It is possible that you could get back some data by deferencing that URL, but that would be behavior specific to that extension.

> This would be a disaster if a term ever changed it's range (allowable values) or semantic meaning 
> (and we have examples of where that has happened in the past).

I agree we should work hard not to create compatibility for a published short string. My suggestion is that when we need to break compatibility we mint a new short label.

> You can't have a message that is sent from a system and be consumed by two 
> applications w/o having ONE clear mechanism for interpreting that message.

Where versioning is needed, it should be done at the level of the whole API. I don't think the messages themselves have meaning outside of SOME API (and we are likely to define more than one of them).

> The key here is that we have some formal definition with provable correctness vs.
> "just a list of words that a bunch of yahoos in a WG have slapped together and put in a human 
> readable document online". :)

I agree we both want that. I am proposing that the WG publish that list via the specification, and it is via the API that one identifies the specification. (I am assuming the API identifies its origin specification.)


Reply to this email directly or view it on GitHub:
Received on Thursday, 7 January 2016 18:16:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:13 UTC