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

Re: Spec-Ops Comments on Web Payments Core Messages 1.0

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 7 May 2016 15:49:49 -0400
To: public-payments-wg@w3.org
Message-ID: <572E46DD.5080105@digitalbazaar.com>
On 04/28/2016 09:41 AM, Shane McCarron wrote:
> I do not require these comments to be resolved prior to migration
> into the web payments working group.

Hey Shane, thanks for the thorough review. These are responses to your
comments as I make changes to the document.

> As an aside, I appreciate the data modelling approach that describes
> the model in prose, then shows representations in multiple modelling 
> grammars.  There are A LOT of ways to express a data model.  With my 
> testing hat on, it would be good to have normative definitions for
> (at least) JSON Schema so that messages can be easily evaluated.

I have added an issue for this and added the issue marker into the spec.



> This document should currently be an unofficial draft (specStatus = 
> "unofficial" in ReSpec)

Spec status is now set to Editor's Draft since it's been picked up by
the group.

> Need github links in the header area

Fixed in both specs.



> Global: s/e.g. /e.g., /

Fixed in both specs.



> How to Read this Document
> Move the Data Model hello world stuff into a section 1.1.1 on Data
> Model Approach.  A primer on how data models work and how this
> document approaches them.



> What is [PSD]?

Payment Systems Directive - it's a European initiative and the [PSD] is
meant to signal that the definition came directly from PSD. I don't
think the readers care that it came from PSD, so I've marked it like so
in the markup:

    <!-- Definition from European Payment Services Directive -->

... and condensed the definition.


> Issue 2: I don’t have a problem with it, but move the content of
> this note into section 1.1.1 above.

Removed the issue marker as it duplicated the other content in the section.


> JSON Schema needs a normative or informative reference.



> There are references to the "expressing" sections. I think they
> should be in appendices but I am not married to the idea.

If we are going to make these sections normative, should they be in an

I've added an issue marker:


> AcceptablePaymentMethod
> The paymentMethod / paymentAmount structure should be grouped into a 
> list of items offers…  one object per payment amount.   … in other
> works the acceptablePayment key should be able to take multiple
> items.

This is currently in the spec:

"One or more AcceptablePaymentMethods that the payee will accept as

I'm not certain we should force an array for single items. I realize why
this is beneficial from a developer perspective.

Perhaps the question is "should validation throw an error if the value
of "acceptablePayment" is not an array (even if that array only has one
item in it).

I've added an issue marker:



> PaymentResponse
> payment key: “may” should be in caps.

Fixed in two places. Is that what you wanted?


> Examples
> I would prefer that the content of the examples be inline. I
> appreciate that JSON Schema is a little verbose, and also that
> ReSpec's highlighting doesn't do a good job on JSON Schema.

How do you suggest we do this while not harming the readability of the
document. I remember you saying something about <summary> or <aside> or
something hide-able like that.

I'm out of time for today, but I'm adding an issue marker so we can
continue the discussion there:



-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
JSON-LD Best Practice: Context Caching
Received on Saturday, 7 May 2016 19:52:30 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 7 May 2016 19:52:31 UTC