- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Wed, 16 Sep 2015 15:19:53 -0400
- To: "public-webpayments-comments@w3.org" <public-webpayments-comments@w3.org>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKcXiSpZ1S1CfiO9tz1W0AwuemjEZ1tpu4oo67BLXNEnkJ_+FQ@mail.gmail.com>
IF the subject line of this thread is "payment initiation"; AND IF "invoice" is described in the UBL (an OASIS & ISO standard) as "a document used to request payment"; THEN invoices and UBL as addressed in that established standard are relevant. RE: "The WG will likely use JSON as it's preferred message encoding" No problem. Perhaps keep in mind: https://en.wikipedia.org/wiki/Multichannel_retailing 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 2:54 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote: > 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 19:20:43 UTC