W3C home > Mailing lists > Public > public-webpayments@w3.org > November 2011

Re: Unofficial Draft 25 October - comments

From: Steven Rowat <steven_rowat@sunshine.net>
Date: Mon, 31 Oct 2011 17:54:21 -0700
Message-ID: <4EAF433D.9090309@sunshine.net>
To: public-webpayments@w3.org
On 10/31/11 7:51 AM, Manu Sporny wrote:
>>> http://payswarm.com/specs/ED/use-cases/2011-10-25/
> Great, thanks for reviewing the document, Steven! :)

Don't thank me too profusely, I haven't read most of it yet. :-) .

> Hmm... good point. It had been something that we were just publishing
> as a company before, but since there is a CG now, the copyright might
> need to be W3C? Alternatively, we could probably place it under
> CC-BY-SA (I think that would be my preference).

I think I'd be happy with either one; just not solely Digital Bazaar 
being mentioned, which I think is not appropriate now. Perhaps a 
relevant quote is "justice not only needs to be done, but needs to be 
seen to be done". If the system being created is a true level playing 
field, then that must be reflected in the copyright of the documents 
creating the system.

And a separate directly related point (which may be better in its own 
thread): the question of statements about conflict-of-interest in the 
authors of the documents. Here I'll give the example of scientific 
peer-reviewed publishing, which I've had more experience with: there 
has been a significant shift, after some key events, to having all 
financial or other remunerative connections be disclosed by all 
authors of a document, when those connections bear on either the 
subject of the discussion or the financial support for those producing 
the document. This is not meant merely to prevent conscious 
manipulation by unscrupulous people (although it does that as well). 
It's also meant to correct for the interesting discovery, supported by 
high-caliber peer-reviewed scientific studies, that authors tend to 
produce studies that vindicate their own financial position even when 
they aren't consciously trying to.

And what we are involved in, in this list, is work that is not only 
indirectly guided by the flow of money; the work is also *about* the 
flow of money. Thus I think it would be a good idea if we were squeaky 
clean on this and followed the same format.

Adopt the support disclosure format commonly used for peer-reviewed 
academic work, in which the authors, editors, or other contributors 
(anyone willing to allow their name to be used in support of the 
published form of the document) state:
   a) Direct Support: Any support or remuneration they have received 
to do work on the document; and from whom.
   b) Indirect Connections: Any income, support, fees, stocks, or 
other remuneration or holdings they have in businesses directly 
impacted by the standard or format being developed.

This does not have to be extensive; but it does need to be stated in 
an honest way sufficient for interested readers, if they so desire, to 
look up the connection and decide for themselves if there is a reason 
why Manu Sporny, CEO of Digital Bazaar, would want to slant the 
standard in a particular direction at a particular time -- even if 
Manu himself wasn't aware of what he was doing. :-) .

> I'd prefer to mark it as a "provisional" name......[snip] unless we can pick a name that is much, much better than
> PaySwarm. Doing that at this point in the process, however, might be
> bike-shedding the discussion too early.

Good, I agree, that you could mark or indicate it as provisional 
somehow, and then leave it for now. At a further point it may become 
obvious that it should either be written into the spec and retained or 
that it's no longer accurate or not as good as some alternative that's 
come up.

> We could also bunch all of the "Requirements" into a separate
> section..[snip]...
> Or, we could start out with requirements and then point each
> requirement to the use case it came from?

Possibly; but first I think there's a more fundamental change in the 
layout that needs to be made; see the detailed example for Penelope below.

> I'll try to think of categories for each use case, but it's hard to do
> with a good set of use cases because each use case is a different
> operational category in and of itself.

Again, possibly; and again, I think there's a major reorganization 
best done before you address this. See below. I expect I'm whetting 
your appetite. I hope I come up with something worth the trouble. :-) .

> Was the thing that was daunting about the list the repetition of
> "Requirements"? Or was it that there was a big list and you didn't
> really know if there was a higher-level structure to it?

In my original reading, and again just now, it wasn't just the TOC 
list that I found daunting; it wasn't just the repetition of 
'Requirements'; it's the way the sequence of ideas is laid out in the 
full text of the individual sections. I actually tried to read several 
sections and couldn't, on both occasions. It made my mind go screwy, 
and I gave up relatively quickly. After some consideration, I believe 
I see why now.

I believe the problem stems in part from a confusion in possible 
interpretations of the term 'Use Cases' from the title: *whose* use 
and for *what*: the problem experienced by the end-user, or the 
solution proposed by programmer of PaySwarm? Both are there, 
intermingled, like this: you explicitly lay out as the first paragraph 
of each section a specific example of a personal problem context as a 
'use case'; but the title before this is an abstraction of what the 
programmer's process needs to do -- so a quick switch in mental 
attitude is needed there; then the third section switches back to an 
abstract description of the programmer's 'use case'; and finally you 
finish, the fourth section, with more specifics of the programmer's 
use case.

So, of your four sections, three are about the programmer's use-case; 
only the second one, but generally the longest one in terms of amount 
of text, is from the point of view of the end-user's 'use'.

Here's an example of what happens when I, as a person who is not an 
expert *either* in the programming language of PaySwarm, *or* in the 
specifics of Penelope's life as a photographer, encounters one of your 
sections. Let's take Penelope's section:

[ 2.5 Micropayments to Thousands of Individuals ]

First I read that title, and try to understand where you're going: I 
have a vague idea of what micropayments might be, but really no idea 
of how they would be sent to thousands of individuals, or who might 
benefit (and whether I would). I assume though that you're going to 
talk about this, and it has something to do with sending a lot of 
identical packets over the web, right? And that's a programming use 
case, right? So I move on expecting something about programming.

[Penelope has completed her fourth book of photography.].
Huh! Who is Penelope? I guess this is an example of a person's 'use 
case'. It must be related to the title, because otherwise why would 
you put it there? Maybe I'll see the connection in the second sentence.

[She would like to charge a very small amount for her travel expenses 
and supplies but doesn't want to make a living from the sale of her book.]
Huh! I still don't see the connection. I've got a mental image of 
Penelope now though, and her book of photography, and the fact that 
she's got some concerns about how she makes a living. I'm starting to 
forget that this is mostly going to be about programming use-cases. 
I'm getting involved in the person's 'case'. I don't really see a 
connection between the two things yet.

[Penelope does, however, want to make a number of contributions to 
charities that she would like to support as well as give her fans the 
ability to contribute to their favorite charities.]
Hm, my picture of Penelope's life has gotten several new layers; it's 
really complex. I'm still straining hard to connect this to the title. 
I'm not sure I've learned anything useful or where we're going.

[Giving individuals on the network the ability to add optional payees 
to licenses and contracts would enable payment models such as online 
tipping for artists, donations to charity, and batched payments to a 
particular initiative or cause to be made along-side the purchase.]
The language suddenly switches to language that programmers and/or 
financial analysts would use and understand, as opposed to Penelope 
herself or general readers like myself, so I assume we've switched to 
a programmer's 'use case'. But in any event I'm unsure who are the 
'individuals on the network' and who is referred to in 'add optional 
payees'. Are we still talking about Penelope there? Or somebody who 
writes programs for her? Or an ISP?  I'm lost again.

[2.5.1 Requirements]
[    * Network participants must be allowed to add arbitrary accounts 
as payees for transactions if allowed by the original content owner.
     * A large number of payee accounts must be allowed to be batched 
with content transactions. Lists of payees should be allowable up in 
the thousands of payees.]

Now I'm clear again: we're in the programmer's use-case. But the only 
thing that I'm also sure about is that it refers directly to the title 
(otherwise why would it be in this section?) I'm not sure exactly how 
it will refer to either Penelope's life example (the user's use-case) 
or the abstraction that followed it that might have been the 
programmer's solution use case.

---End of example---

I know I exaggerated a little with my 'Huh!'; but not much; and on the 
other hand the same thing happened in several sections I tried to 
read: the idea flow confused me in the same way.

I suggest trying a new flow for all of them, and possibly redefine 
'use-case' and be consistent about what level it is for.

Perhaps since most of it is the programmer's 'use case' already, the 
story about the person should be demoted to being an example, labelled 
as such, and placed either third or fourth in the sequence. Or, the 
person example should be removed altogether and placed together in a 
section of examples at the end of the document.

> That's an good summary of some of the things that we're attempting to
> achieve here, Steven. I'm concerned that it's a bit heavy handed...
> that is - it might scare some people away. Or it might make
> corporations believe that this standard isn't for them. I think it
> would be a mistake to take, what comes across as, an anti-corporation
> stance in the introduction.

Fair enough. But given what has happened in the past (including the 
HTML5 spec becoming controlled by employees of corporations) and what 
is happening now worldwide on many levels -- the disastrous ecological 
results of corporate globalization and control of governments -- I 
believe it's necessary to be very forward about this in order to 
prevent the individual from being shut out. If you think corporations 
might fear they are in danger of being shut out, I'll take that as a 
positive sign. I believe we can reach some compromise in which the two 
can coexist. :-) .

Received on Tuesday, 1 November 2011 00:57:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC