W3C home > Mailing lists > Public > public-webpayments@w3.org > March 2012

Web Payments Telecon Minutes for 2012-03-20

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 20 Mar 2012 15:45:04 -0400
Message-ID: <4F68DE40.5040009@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
Thanks to Dave Longley for scribing! The minutes for today's telecon are
available here:

http://payswarm.com/minutes/2012-03-20/

Full text of the discussion follows for archival purposes at the W3C.

---------------------------------------------------------------------
Web Payments Community Group Telecon Minutes for 2012-03-20

Agenda:
   http://lists.w3.org/Archives/Public/public-webpayments/2012Mar/0035.html
Topics:
   1. PaySwarm Reference Implementation
   2. Vocabulary Review - Commerce
   3. Commerce Vocabulary Classes
   4. Commerce Vocabulary Constants
   5. Commerce Vocabulary Properties
Facilitator:
   Manu Sporny
Scribe:
   Dave Longley
Present:
   Dave Longley, Manu Sporny, David I. Lehn, David Nicol, Jeff Sayre
Audio:
   http://payswarm.com/minutes/2012-03-20/audio.ogg

Dave Longley is scribing.
Manu Sporny:  The above link is for the day's agenda.
Manu Sporny:  We'll be going over some vocabularies related to
   payswarm.

Topic: PaySwarm Reference Implementation

Manu Sporny: https://dev.payswarm.com/
Manu Sporny: Skipping this because there aren't any people that
   haven't seen it on the call.
Manu Sporny:  We're going to first discuss the commerce
   vocabulary.

Topic: Vocabulary Review - Commerce

Manu Sporny:  The main thing to try and understand with this
   vocabulary is to see what we might be able to get rid of (cut
   down) or things we might want to consolidate into the vocab.
David I. Lehn: http://payswarm.com/specs/source/vocabs/commerce
David I. Lehn: that's the latest one. we should look at that
Manu Sporny:  so we'll go from the top-level classes down into
   the constants and properties.

Topic: Commerce Vocabulary Classes

Manu Sporny:  Deposit, Account, Payee, all straightforward and
   needed.
Dave Longley:  PayeeRule is necessary, we use it - tells us what
   people allow to be tacked on to the prices they list... [scribe
   assist by Manu Sporny]
Manu Sporny:  Wo we're keeping all of the classes in the commerce
   vocab.
Manu Sporny:  Are there any classes we need to be adding to the
   vocab?
Manu Sporny:  Last week we discussed the security vocab and it
   needed some work, but commerce seems fairly solid.
Manu Sporny:  Would credit card, banking account go in here?
Manu Sporny:  One specifically for each.
Dave Longley:  We might also wrap all of the payment methods into
   a Payment vocab.
Dave Longley:  We were also talking about a 'pay' vocabulary and
   wrapping those things up into a single vocabulary - credit cards,
   banking information, etc. [scribe assist by Manu Sporny]
Manu Sporny:  So we can talk about the pay vocab and the credit
   card vocab at the same time later.

Topic: Commerce Vocabulary Constants

Manu Sporny:  On to the constants listed in the vocab...
Manu Sporny: http://payswarm.com/specs/source/vocabs/commerce#toc
David I. Lehn: Our code has Exclusive/Inclusive w/o the
   "Percentage" extension
Dave Longley:  We use all of the constants in the vocabulary
   now... so we don't need to get rid of any of them. We have made
   some changes - we don't have exclusivePercentage and
   inclusivePercentage anymore... I think we just have percentage
   [scribe assist by Manu Sporny]
Dave Longley:  We have 'rate' and 'rateContext' now...
   'rateContext' specifies how you understand the rate [scribe
   assist by Manu Sporny]
Dave Longley:  Exclusive percentage is something like a sales
   tax... [scribe assist by Manu Sporny]
Dave Longley:  Inclusive percentage is a way of calculating the
   total w/o modifying the total... so if you want the article to be
   $0.05 - payee rule w/ inclusive percentage of 2% would mean the
   article will always be $0.05... [scribe assist by Manu Sporny]
Manu Sporny:  Exclusive percentage, add on to the total,
   inclusive percentage doesn't modify the total, it breaks up the
   percentages within the total for different destinations.
Dave Longley:  'rate' can only be percentage or flat amount
   [scribe assist by Manu Sporny]
Dave Longley:  'rateContext 'determines how 'rate' is used to
   calculate the final amount. [scribe assist by Manu Sporny]
Manu Sporny:  We don't have how to resolve payees in the specs
   anywhere, right now, right? [scribe assist by Manu Sporny]
Dave Longley:  Yeah, we need to add that to the specs. [scribe
   assist by Manu Sporny]
Dave Longley:  Commerce spec should be changed to remove
   ExclusivePercentage and InclusivePercentage. [scribe assist by
   Manu Sporny]
David I. Lehn:  Which is more up to date the implementation or
   the spec w/respect to Exclusive/Inclusive Percentage?
Dave Longley:  Commerce spec should be modified to add constants
   for Percentage, Exclusive, and Inclusive. [scribe assist by Manu
   Sporny]
Manu Sporny:  We'll want to take a look and see if there's any
   way we can simplify this.
David I. Lehn: dln, tilgovi: We're chatting over voip now, you
   are welcome to join
Manu Sporny:  We need to remove ExclusivePercentage,
   InclusivePercentage and add Percentage, Exclusive, and Inclusive.

Topic: Commerce Vocabulary Properties

Manu Sporny:  Looking at 'account', 'source' and 'destination' -
   we need all three? [scribe assist by Manu Sporny]
David I. Lehn:  If you look at the account, it specifies the
   account for a person, it isn't a source or a destination.
Manu Sporny:  We can use it to list all of the public accounts on
   an identity page.
Manu Sporny:  We marked up the previous demo in RDFa using that.
Dave Longley:  I don't remember if we had to have 'account'...
   'account' was bleeding into cases where we need to use 'source'
   or 'destination' [scribe assist by Manu Sporny]
Dave Longley:  We need to be more clear in spec language on when
   you use 'com:account' vs. 'com:destination' [scribe assist by
   Manu Sporny]
David Nicol:  What about 'vendor' and 'customer' [scribe assist
   by Manu Sporny]
David Nicol:  There are/we want more layers, many layers of
   little definitions
Manu Sporny:
   http://payswarm.com/specs/source/vocabs/commerce#account
Manu Sporny:  that link gives an example that describes a person
   that has an account
David Nicol: Has the Payswarm vocab named the layers?
Manu Sporny:  We achieve layers by saying there are "identities"
   with "accounts" (two layers) ...
Manu Sporny:  We have identity as one layer and account as
   another.
Manu Sporny:  There is a distinction between account, source, and
   destination, we need all three
Manu Sporny:  'amount' is next... refers to a number of bitcoins,
   dollars, etc.
Manu Sporny:  'amount' only specifies the value, not the unit of
   measurement.
Manu Sporny:  Unit of measure is com:currency which is next
David I. Lehn:  Possible problem with inconsistency between
   string and IRI for the value of a currency
Manu Sporny:  We could come up with a string for each alternative
   currency
Manu Sporny:  If we can specify currency mints we get problems
Dave Longley:  Why don't we just normalize and always use IRIs
David I. Lehn:  There isn't an official IRI for USD, etc.
David Nicol: That's one less thing for ICANN to do, if this
   working group takes ownership of the comprehensive list of short
   currency codes
Manu Sporny: We could do something like this - "com:currency":
   "iso4217:USD" or this "com:currency": "cur:USD"?
David Nicol: iso4217 will drift, that's one issue. Requiring
   upgrading when it happens.
Manu Sporny:  Do we need com:date? [scribe assist by Manu Sporny]
Dave Longley:  We were definitely using dc:created for signature
   creation... [scribe assist by Manu Sporny]
Dave Longley:  Transactions may not be created at the same time
   they're authorized... so "com:date" is not the same thing as
   "dc:created". [scribe assist by Manu Sporny]
Dave Longley:  Any time we authorize or finalize a transaction,
   we use "com:date" [scribe assist by Manu Sporny]
David I. Lehn:  I have marked some places where we need to go
   back and look at it
Dave Longley:  Source or destination seems to be more specific -
   you can't misunderstand that in the same way as to/from (which
   can be about identities, or it can be about accounts) [scribe
   assist by Manu Sporny]
Jeff Sayre: +1
David Nicol: to/from is at identity layer and source/destination
   is at account layer?
Manu Sporny:  David Nicol, effectively, yes. We should keep
   source and destination because they are more specific to
   accounts...
Manu Sporny:  and they enable more layers of differentiation
   between identity, financial account, etc.
Manu Sporny:  next up is 'destinationOwnerType'
David Nicol: and not lose to/from as they pertain to something
   subtly differnt
Dave Longley:  Yeah, this is important for making the
   differentiation in PayeeRules, so we need it. [scribe assist by
   Manu Sporny]
Manu Sporny:  it is used in a payee rule, to specify that the
   only particular owners of destination accounts can take a cut of
   a sale, etc.
Manu Sporny:  We need to move gatewayApprovalCode and
   gatewayError in the Payment vocabulary... not in the Commerce
   vocabulary. [scribe assist by Manu Sporny]
Dave Longley:  Yeah, this is one of those things that bled into
   this vocab, we need to move it out. [scribe assist by Manu
   Sporny]
Manu Sporny:  we're moving all of the gateway related properties
   to the payment vocabulary.
Manu Sporny:  any concerns about doing that change?
David I. Lehn:  That's fine, i haven't noticed gateway error
   before
Dave Longley:  The example for gatewayError is bad, but we may
   need to return this in exceptions. [scribe assist by Manu Sporny]
David I. Lehn:  It seems like it would be part of a response in
   some generic exception system
Manu Sporny:  'maximumRate' is used
Dave Longley:  I think we need to add minimumRate to the spec.
   [scribe assist by Manu Sporny]
Manu Sporny:  forTransaction is for reverse linking transfers to
   the transaction they are a part of
David Nicol: ...something about Ted Waitt (ed: founder of Gateway
   Computers)
David I. Lehn: we don't have minimumRate anywhere in our code.
   maybe that wasn't needed?
David I. Lehn:  I'm not sure ... will have to go back and look.
Dave Longley:  We may not need "com:forTransaction"... [scribe
   assist by Manu Sporny]
Dave Longley:  I don't know if we minted any URLs for transfers.
   [scribe assist by Manu Sporny]
Dave Longley:  If we did give them URLs, then we would want
   reverse links... but if they're just embedded inside
   transactions, maybe we don't need it. [scribe assist by Manu
   Sporny]
Dave Longley:  If we have a transfer as a starting point in the
   database, then we may need forTransaction. [scribe assist by Manu
   Sporny]
Manu Sporny:  We can't think of a good reason for forTransaction
   but we should double check before removing it.
Manu Sporny:  We could go through the payswarm reference demo now
   and answer some questions about it?
Jeff Sayre:  I think the time would be best spent going through
   the vocab.
David Nicol:  Agreed that time would be best spent talking about
   the vocab.
Dave Longley:  Maybe next time we can start out with the demo
   quickly.
Manu Sporny:  'limitation' is next, it allows people who sign
   listings to specify that they don't want anyone else taking a cut
   of a sale.
Manu Sporny:  Can be used to prevent affiliate type sales
David Nicol: We don't want to bring issues from business layer
   down here
David Nicol: rules about "no multi-level" -- no reselling?
Dave Longley:  I think we need com:limitation - need a way to
   specify that someone shouldn't get paid. [scribe assist by Manu
   Sporny]
David Nicol: Just don't want to put anything complex here
Dave Longley:  We need a vocabulary that specifies rules for who
   gets paid... we need to give some basic set of rules somewhere.
   [scribe assist by Manu Sporny]
Manu Sporny:  Well, the question is what vocabulary the terms
   should go in. [scribe assist by Manu Sporny]
Dave Longley:  I'm for breaking it out into a separate vocabulary
   - but it's something that we absolutely need. [scribe assist by
   Manu Sporny]
Manu Sporny:  Anything associated with business rules, payee
   limitations, etc. should be shifted to another vocab maybe.
David I. Lehn: Soon we will have a vocabulary explosion problem
   if we keep splitting vocabularies
David Nicol:  layers are good
Manu Sporny:  It's good to understand where the layers are
Manu Sporny:  Commerce should maybe have two layers low-level
   accounts, and high-level 'what makes the money dance around' ...
   rules about how the money can move between accounts, in exchange
   for assets, etc.
Dave Longley:  Yes, we need to find a good balance here, so we
   don't have a vocab explosion but we don't want to mix layers and
   get things muddled.
Manu Sporny:  We could split the vocab documents into 2, 'high'
   and 'low' levels.
Manu Sporny:  moving on
Manu Sporny:  'minimumAmount' is already here, what about
   'minimumRate'? [scribe assist by Manu Sporny]
Dave Longley:  The reason we have 'minimumAmount' is to specify a
   floor to the amount that one would collect... [scribe assist by
   Manu Sporny]
Manu Sporny:  minimumAmount specifies a floor
Dave Longley:  Once payee amounts are resolved, they can't be
   below that floor.
Manu Sporny:  'payeePosition' is next and is important because it
   can be used in the payee algorithm
Manu Sporny:  We need to spec out payeePosition a bit more if we
   keep it
Manu Sporny:  We might just use @list in JSON-LD now to avoid
   having to specify the order by property
David I. Lehn:  We need to be clear about what the order is and
   how its used
Manu Sporny:  So we need to decide if we can get rid of it... if
   so, we should probably drop it.
Dave Longley:  Having the position helps people know to be
   specific
David Nicol: 'payeePosition' is a complicated business rule that
   only comes into effect when there is a short payment
Manu Sporny:  The algorithm and everything is complicated enough
   we're going to need visual depiction, etc.
David I. Lehn:  If order is external instead of inside the object
   you could reuse them.
Dave Longley:  We don't always give them @ids right now, but if
   they have @ids they could be reused
Dave Longley:  If the payees have @ids, then we may want to reuse
   them in different places, which is an argument against having
   payeePosition. [scribe assist by Manu Sporny]
Manu Sporny:  Which is an argument against payeePosition
Manu Sporny:  Top of the hour, we need to wrap up the call.
David I. Lehn: <currency
   currencyScheme="http://www.fpml.org/ext/iso4217">DEM</currency>
David I. Lehn: fpml has some scheme thing. they require
   registration to look at the spec though. just found an example on
   their site.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Tuesday, 20 March 2012 19:45:40 UTC

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