Spec-Ops Comments on Web Payments Core Messages 1.0

Manu,

Thanks for the reminder email that we should submit comments.  Below are
mine.  I am in general in favor of bringing this document into the family
of Web Payments specifications.  I would hope that over time the
definitions and structures in this document will harmonize with those in
the browser payments api to reduce complexity for future developers.

I do not require these comments to be resolved prior to migration into the
web payments working group.

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.

=========

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

Need github links in the header area

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

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]?

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

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.


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.

PaymentResponse

payment key: “may” should be in caps.

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.


-- 
Shane McCarron
Projects Manager, Spec-Ops