- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 17 Jun 2016 22:52:52 -0400
- To: public-payments-wg@w3.org
Hi Kris, Apologies for the long delay in responding, we were waiting for the Browser API to settle before working on the core messages and HTTP API again. Responses to your request for changes below: On 05/03/2016 01:25 PM, KETELS Kris wrote: > *Core Message Components* > > The relation between the different core message components is > missing. A UML alike data model would contain more and clearer > information? Yes, that's true. I've tried to mock up what this would look like for a Payment Instruction. Let me know what you think: https://w3c.github.io/webpayments-core-messages/#paymentinstruction Commit is here: https://github.com/w3c/webpayments-core-messages/commit/32fd5118eacb3de85d389834b5b075f9de37a63d > I would suggest for this document specify the entire resource(s) and > the applicable methods on the resource(s)? Doing that would duplicate a lot of information. For example, we'd end up repeating the same text for paymentAmount in the PaymentInstruction and the PaymentResponse sections. Repetitive text in W3C specifications is typically frowned upon. Since these are technical specs, duplicated text means that if there is a bug you have to fix it in more than one place and, as a result, specifications are prone to building up more errors over time. What I've done instead is put the core messages at the top of the document with the components below. The hope is that this will lead to a more complete understanding faster. https://github.com/w3c/webpayments-core-messages/commit/32fd5118eacb3de85d389834b5b075f9de37a63d > Core component FinancialAmount No negative amounts exist in ISO > 20022. Whether the amount is to be debited or credited, depends on > the context, not on the sign. Fixed. Removed support for negative amounts. https://github.com/w3c/webpayments-core-messages/commit/3934ff42ebc8db5b7f082092f4d6697de7e84078 > Fractional part is 5 digits max. TotalDigits is 18. Since this specification is about data model, we shouldn't put arbitrary restrictions on values unless it makes sense to do it at the data model layer. The restriction that you are talking about sounds like implementation details leaking into the data model. The right place to put that restriction would be in the application layer (for example, when converting one of these messages into an ISO20022 message. What was the rationale for limiting this value in ISO20022? > In ISO 20022, there is the possibility to use a active currency code > list(i.e. the currency has not been revoked/replaced...) We don't currently have a use case for active vs. inactive currency codes for Web Payments, so I hesitate to add it until we do. > *Core Messages* > > How about specifying these calls using the http calls get, post etc… > > /AcceptablePaymentMethod/ > > Why not call this PaymentTerms or PaymentMethodTerms? i.e. remove > Acceptable (no bearing) and add Terms (as this is what it seems to > cover). > > Then we can have e.g. get PaymentMethod; post PaymentMethod etc...? Changed to "PaymentTerms": https://github.com/w3c/webpayments-core-messages/commit/f9003edcf783c4aa3643ffaeea26bd0d648c2f3f I think HTTP GET'ing and POST'ing PaymentInstructions makes sense. I'm not so sure doing that with PaymentTerms makes sense. Am I missing what you were asking for? > /PaymentRequest/// > > This could be the PaymentInstruction resource? Done. https://github.com/w3c/webpayments-core-messages/commit/c66f5d24f14f9668b9916b1ef15a59cf6b232d76 -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Web Browser API Incubation Anti-Pattern http://manu.sporny.org/2016/browser-api-incubation-antipattern/
Received on Saturday, 18 June 2016 02:53:18 UTC