- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Wed, 16 Sep 2015 20:54:40 +0200
- To: Joseph Potvin <jpotvin@opman.ca>
- Cc: "public-webpayments-comments@w3.org" <public-webpayments-comments@w3.org>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CA+eFz_+XbD7-tVgVy7kkvk1+YkqKccOig+2B7sVWWVtU=7Z7wA@mail.gmail.com>
Two personal comments on UBL and XML vs JSON *specifically with regard to the proposed WG*. 1. Invoices, and therefore UBL, are out of scope for what is being dealt with in this WG. They form part of the larger scope of the IG and may be part of the scope of a future WG. At most, I expect that accommodation may be made in the logical message designs to reference the invoice triggered the payment. 2. The WG will likely use JSON as it's preferred message encoding as this is the accepted practice today for W3C recommendations. That is not to say that the logical messages we define could not be encoded in other forms or that informative examples, test cases etc may not be produced using other encodings. *With regard to the work of the IG*, my hope is that, with Kris and Vincent's help, we will vastly improve our understanding of ISO20022 and see where the IG and the ISO20022 RA may work together to close the gap between what is being done in the two groups. This MAY include such things as collaborating to produce a recommendation for JSON encoding ISO20022 messages or some standards for exposing Web APIs that exchange ISO20022 messages. UBL is most likely to come into context when the group takes on the broader scope we have called "commerce" at which time it will likely be an important input to the work. On 16 September 2015 at 18:29, Joseph Potvin <jpotvin@opman.ca> wrote: > Hope the following is useful. I asked UBL TC Co-Chair Ken Holman for his > comments... > > At 2015-09-16 11:20 -0400, you wrote: > > "Ken, Got a suggested reply?" > > > Well, I can make a few observations that you can do with as you like. > > On 2015-09-16 16:49, Adrian Hope-Bailie wrote: > RE: "invoice" is described as *"a document used to request payment"* > [Anders Rundgren <anders.rundgren.net@gmail.com>] I hope that UBL > won't be used for payment requests. UBL was designed for B2B and payment > operations usually only refer to invoice numbers. > > The only seven mandatory items in the UBL Invoice are an identification > string, an issue date, the party responsible to make payment, the party > responsible to receive payment, a legal monetary total, and an item > identification string and an item amount for each item. > > Ref: > http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_Invoice > > This satisfies a legal request for payment in any context, not just B2B or > B2G, and so is not encumbered by any business semantic of "invoice". All > of the other semantics available in UBL are handy for business > applications, but are not necessary to make UBL useful in any situation > where a request for payment is being made. Using the noun "invoice" is a > convenient abbreviation. > > > RE: Aren't you BTW rather planning to use JSON rather than XML, ISO, ASN.1 > etc? > > JSON is used to convey an internal memory structure of information from > one application to another application, obliging both applications to begin > working from the same internal memory structure. > > XML is used to convey information in an arbitrary document format so that > applications can map their internal memory structures to and from the > document format, with the added benefit of the document format being > independently inspected, for example, for auditing purposes. > > JSON is ideal between two applications that have identical memory and > implementation representations, and a tight binding, and foreknowledge of > the order and makeup of every information item. Tight binding is not > convenient for representing optionally-present information. > > XML is ideal between two applications that have independent memory and > implementation representations and a loose binding. Loose binding is > convenient for representing optionally-present information. It is focused > on conveying intent in a way that allows the information to be used in > multiple ways. XML is also self-documenting in the judicious use of labels > for the information items, providing for independent inspection. > > Loose application bindings and self-documenting labels are the better > choices for open standards where participants have varied implementations, > varied platforms and varied contexts of use of the information. > > RE: <https://yourlogicalfallacyis.com/false-cause> > https://yourlogicalfallacyis.com/false-cause > An invoice may be defined as a means to request a payment but that does > not mean that a payment must always be requested by an invoice. > > > True, but if a request for payment is needed and the invoice is an > available and satisfactory document for legal and practical purposes, then > there is nothing that prevents the invoice from being used for this purpose: > https://yourlogicalfallacyis.com/the-fallacy-fallacy > > . . . . . . . Ken > > > Joseph Potvin > Project Coordinator, DataKinetics > Operations Manager | Gestionnaire des opérations > The Opman Company | La compagnie Opman > jpotvin@opman.ca > Mobile: 819-593-5983 > LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423> > > On Wed, Sep 16, 2015 at 10:57 AM, Anders Rundgren < > anders.rundgren.net@gmail.com> wrote: > >> On 2015-09-16 16:49, Adrian Hope-Bailie wrote: >> >>> RE: "invoice" is described as *"a document used to request payment"* >>> >> >> I hope that UBL won't be used for payment requests. >> >> UBL was designed for B2B and payment operations usually only refer to >> invoice numbers. >> Aren't you BTW rather planning to use JSON rather than XML, ISO, ASN.1 >> etc? >> >> Anders >> >> >>> https://yourlogicalfallacyis.com/false-cause >>> >>> An invoice may be defined as a means to request a payment but that does >>> not mean that a payment must always be requested by an invoice. >>> >>> On 16 September 2015 at 16:08, Joseph Potvin <jpotvin@opman.ca <mailto: >>> jpotvin@opman.ca>> wrote: >>> >>> RE: "Is “invoice” synonymous with “authorization request” or is it >>> something different?" >>> >>> >>> This is from the site of UBL Technical Cttee Co-Chair Ken Holman's >>> site, where "invoice" is described as *"a document used to request payment"* >>> >>> http://www.cranesoftwrights.com/resources/Crane-UBL-Skeleton/Crane-UBL-Invoice-2.1.html >>> >>> The specs: http://ubl.xml.org/wiki/ubl-specifications >>> >>> Here are a couple of general views of what UBL contributes to >>> electronic invoicing: >>> http://eeiplatform.com/about/ >>> http://www.faces-online.nl/ubl-breakthrough-electronic-invoicing/ >>> >>> RE: [Dan S.] "I could be splitting a bill and that is my share, I >>> could be giving someone a gift or donation - there is not always an >>> invoice. Furthermore if you want to handle payments pull then there is no >>> invoice, such an authorization to allow a company to debit your account." >>> >>> Call it what you wish in whatever context you like. In UBL, that's >>> all specified in a document called "invoice", across any context. I'm not >>> aware of any better generic document type for this purpose, in any other >>> existing open standard. >>> >>> Joseph Potvin >>> Project Coordinator, DataKinetics >>> Operations Manager | Gestionnaire des opérations >>> The Opman Company | La compagnie Opman >>> jpotvin@opman.ca <mailto:jpotvin@opman.ca> >>> Mobile: 819-593-5983 <tel:819-593-5983> >>> LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423> >>> >>> On Wed, Sep 16, 2015 at 8:49 AM, Matt Howarter < >>> Matthew.Howarter@walmart.com <mailto:Matthew.Howarter@walmart.com>> >>> wrote: >>> >>> Is “invoice” synonymous with “authorization request” or is it >>> something different?____ >>> >>> __ __ >>> >>> *Matt Howarter****Director - Payment Services* >>> Phone: 479.204.9922 <tel:479.204.9922> Fax: 479.277.9796 <tel: >>> 479.277.9796> >>> Matthew.Howarter@wal-mart.com <mailto: >>> Matthew.Howarter@wal-mart.com> >>> Walmart >>> 702 SW 8th St. >>> Bentonville, AR 72716-0100 >>> *Saving people money so they can live better.*____ >>> >>> __ __ >>> >>> *From:*Joseph Potvin [mailto:jpotvin@opman.ca <mailto: >>> jpotvin@opman.ca>] >>> *Sent:* Wednesday, September 16, 2015 5:41 AM >>> *To:* Web Payments IG; Web Payments CG >>> *Subject:* Re: Payment Initiation - platform integration____ >>> >>> __ __ >>> >>> Is there agreement that:____ >>> >>> >>> 1. Payment is always specified and initiated from an invoice?____ >>> >>> 2. UBL 2.1 provides the relevant global standard for an invoice? >>> http://ubl.xml.org/ ____ >>> >>> >>> ____ >>> >>> Joseph Potvin >>> Project Coordinator, DataKinetics >>> Operations Manager | Gestionnaire des opérations >>> The Opman Company | La compagnie Opman >>> jpotvin@opman.ca <mailto:jpotvin@opman.ca> >>> Mobile: 819-593-5983 <tel:819-593-5983>____ >>> >>> LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423 >>> >____ >>> >>> __ __ >>> >>> On Wed, Sep 16, 2015 at 5:45 AM, Adrian Hope-Bailie < >>> adrian@hopebailie.com <mailto:adrian@hopebailie.com>> wrote:____ >>> >>> Looking at the draft spec from Digital Bazaar for the CG and >>> considering both, our language in the charter, and also some of the >>> comments from the charter AC review I wondered what precedent there may be >>> in defining how a browser should process an API call that requires >>> interaction with the platform (host OS).____ >>> >>> The best example I could find is in the Web Notifications PR >>> published earlier this month: >>> http://www.w3.org/TR/2015/PR-notifications-20150910/#displaying-notifications____ >>> >>> I would like to get the groups' (both IG and CG) views on the >>> parallels here between the action "Displaying Notifications" from the Web >>> Notifications recommendation and a potential "Initiating Payments" section >>> we'd put in a recommendation from our WG.____ >>> >>> The pertinent line from the Web Notifications rec is: >>> "Display notification on the device (*e.g. by making the >>> appropriate notification platform API call*)." - emphasis mine.____ >>> >>> While I know not all platforms upon which browser's run today >>> have mature "payment APIs" in the same way that they have relativley mature >>> "notifications APIs" this open-ended approach seems appealing in that it >>> avoids the browser needing to become complex payment processing >>> applications.____ >>> >>> Rather, the messages passed to the navigator.payments API in the >>> browser should simply be passed directly to the platform's payment API >>> (following any security or privacy scrutiny or permissions checks we >>> define). >>> >>> The timing seems right for us to work with the platform vendors >>> (many of whom are also browser vendors that have expressed interest in >>> working on this problem) to define a common vocabulary and logical messages >>> for this flow.____ >>> >>> *Example: >>> * >>> On a mobile platform I see this working similarly to the way >>> Android intents may function. The browser passes the payment initiatiation >>> request to the platform and the user is prompted with the app selection >>> dialogue they are accustomed to for selecting the app they want to use for >>> that action (the same way you select which app to use when sharing a photo >>> for example). ____ >>> >>> __ __ >>> >>> Thoughts?____ >>> >>> __ __ >>> >>> This email and any files transmitted with it are confidential >>> and intended solely for the individual or entity to whom they are >>> addressed. If you have received this email in error destroy it immediately. >>> *** Walmart Confidential *** >>> >>> >>> >>> >> >
Received on Wednesday, 16 September 2015 18:55:10 UTC