Re: [ISSUE-9] Re: Web Payments Use Cases 1.0, W3C First Public Working Draft 16 April 2015

Hi Manu,

First, the three or four fixes of line-spacing and one-word errors and 
typo, up to and including line 588, seem like they should be fine.

Then:

On 4/19/15 10:08 AM, Manu Sporny wrote:

>> This sentence is nonsensical -- try making sense of the three 'is'
>> verbs: "General feedback is requested as to whether or not this
>> section is helpful in grounding the payment phases and steps in a
>> real world use case is helpful this early in the document."
>
> You're right, attempted to fix the language. See if you're happy with
> the new language.
>
> https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39
>

Seems fine.

>
>> But, hold on, another problem has cropped up as well -- in 4.2, when
>> does PayToParty 'offer' her payment? Before or after she presses the
>> button? Isn't the 'offer' actually after she presses the button? If
>> so, then "Discovery..." in 4.2 is wrong -- it hasn't been offered
>> yet. Or, again, are there steps missing that aren't listed?
>
> The word "offer" in that context is problematic. I changed the phrasing
> from "PayToParty offers her" to "PayToParty accepts" to attempt and
> avoid the type of confusion the phrasing caused you. Let me know if that
> helps.
>
> https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39
>

I suspect it helps, but won't really know until I read it in context 
in the document flow. (I'm assuming that's not available yet, if these 
changes aren't committed).


>> A. Why is there a Privacy point under Kiosk, but not under Website?
>> Are people going to Websites not entitled to privacy?
>
> Further up in the document we state that some of these rows, like
> privacy, are not specified for each use case. When it makes sense to
> mention some aspect of privacy, we do so, at other times we don't. The
> same goes for security, exceptions, etc.  In this particular use case,
> Cory is using a loyalty card which enables the merchant to track him,
> thus the privacy warning. The website use case doesn't use a loyalty
> card, which is why we don't raise privacy implications there.
>
> That said, there are many privacy implications in play. Did you have a
> particular privacy implication in mind. Could you suggest some text to
> put in the privacy portion of the website use case?

No, only that I think it's a general need for all the transactions, 
including Website. Now that I've keyworded "Privacy" in the document 
and seen that you have various places where it's mentioned, in various 
contexts, I'll assume that the general principle is there, which I 
missed the first time through.

However, I see that most of these statements are late in the document. 
In fact the Cory example is the first place where there's an explicit 
statement. So it made sense that I'd flag it and assume you weren't 
going to have general statements at a different logical level -- 
because wouldn't you have put those first, if they were there? But in 
fact I discover you have many such statements later.

So I suggest that somehow you have the most general of the privacy 
statements earlier, before any of the examples. This would then 
function the same way CSS functions -- by analogy, as if the privacy 
goal is in the body style sheet in the header and applies to 
everything, unless there is a local override.

In other words, having increasingly general statements about privacy 
later in the document seems backwards.


>> But this is not the same thing as the
>> payer having 'questionable judgment', which would be a decision by
>> some third party that the payer's judgment was questionable. I
>> suggest re-writing to clarify...
>
> Reworded, let me know if the rewording works for you.
>
> https://github.com/w3c/webpayments-ig/commit/2cacf81e3c8c078cdf55d2f54c2bd225f3face39

Seems fine.


>> Registration-less I don't agree that this case is non-essential. I
>> would like it moved to essential. It seems core.
>
> I agree, but the group decided that it was not essential at the
> face-to-face meeting in Utrecht. You will have to make a case for why
> you think it is essential. If you do that, and we haven't considered
> your reason, I can re-open the issue with the group under the W3C
> Process rule related to "reopening an issue due to new information that
> the group hasn't considered".

I'm not going to attempt that; instead I'll refer to the post I just 
sent to the web-payments CG about paradigm changes (link below). I 
think that this function is likely an important feature of our net 
future, but I'm not certain there's any point in (me, or possibly 
anyone) attempting to argue this here now with the W3C IG.

https://lists.w3.org/Archives/Public/public-webpayments/2015Apr/0045.html


>> Coupons & Loyalty cards Especially given that Registration-less is
>> non-essential, I object strongly to this one being essential. Taken
>> together (6.1.2.1 and 6.1.3), it looks like a strong bias in favour
>> of the merchant over the customer. I think this is a mistake.
>
> I agree, but the group has decided that this is essential. Please
> provide a more detailed analysis and I can open an issue based on the
> reasoning in the previous paragraph.

Same answer as previous.

>> By this point I'm beginning to realize the level of detail is too
>> much -- I can't read the same format over and over and still
>> comprehend it. So, yes, I think there are too many examples...(I
>> believe you asked about this earlier).
>
> Do you have a suggestion on what we could change to make this better,
> other than cutting down on examples? Each example is supposed to expose
> something unique that the other examples do not. Do you see duplication
> anywhere? We can cut out the duplicated bits, or perhaps do some merging.

That makes sense -- but still I broke down reading it. I think I 
recall the breakdown had to do with trying to keep track of all the 
different people's names...--I think there's some sort of mechanism in 
my mind (possibly everyone's?) that opens a new 'model' each time a 
new 'real person' (Sophia, Ben, Carol, etc. etc.) is presented. And I 
already have baggage in my mind -- emotional connections -- for each 
of these names, from my real life experience. This means dozens of 
restarts of models that have lots of extra data that isn't actually 
relevant here. It's paradoxical, perhaps, but I think it would be 
easier to concentrate on what's being said if only 'Customer' was used 
(no, not Payer, please, if you're going to use Payee for the other 
one). Then each example would show clearly the new situation, without 
distractions.

I'm only guessing at this -- I can't know unless confronted with a 
document (or representative section of the document) that is set up 
like that.

>> Overview thought: maybe the four main steps that are laid out at the
>> start --  Maybe these should divide the entire document. Of course
>> there would have to be an abstract or summary of them at the top,
>> but after that, instead of iteratively going through all four steps
>> -- what -- thirty-five times?
>
> Hmm, there is clearly a problem here, ...snip... So, I believe we're doing what
> you want, but you didn't get that impression from looking at the
> document (and that's bad).
>
> Could you take a look at the document again and let us know if there is
> still a problem?

You're right, it is set up that way. I can only refer to my previous 
statement about all the people. Not sure what happened. Somehow I got 
overwhelmed by it and had to abort. That's all I know.

Except to note that I'm fairly sure from my other writing/editing work 
that I can't approach such a document again until it's out of my 
short-term memory -- two or three days at least. After that I can 
approach it as a 'new reader' again -- more or less -- but before that 
I'll be remembering the emotional reactions and tangles I got into the 
first time around, so there won't be a hope of trying to assess the 
overall impact of any changes until then.

Steven Rowat

Received on Monday, 20 April 2015 00:12:22 UTC