prowl transaction record id uniqueness is only between two entities

[els]

***from Miles:

My eyebrows were raised a little at the mention of "#some_id" because
of
course that is going to be "hard" to synchronize at both ends of a
transaction. "hard" is something of an understatement. From your
other
discussions on the net it appears this is more about binding together
two
related transactions together which makes sense. Some system where by
unique
ids (in a given name space) can be proposed on one end and then
accepted on
the other end might work, but of course it is complicated so probably
deserves some more discussion.

***

Your comment allows me to explain another benefit of using the
"canonical" publishing syntax. In reality, the coordination is
required only between two transacting entities, and it may be as
simple as having the #some_id assigned by a particular cash register
belonging to entity receiving the credits in a transaction. In fact,
the id parameter maybe exlcuded and is optional in the Prowl
publication syntax.

The emphasis is on the uniqueness of the whole published transaction
record, not just the id parameter.

[els]

>The emphasis is on the uniqueness of the whole published transaction
> record, not just the id parameter.

Just to add more clarification:

The #some_id parameter is only needed to confer uniqueness to a given
published transaction record. For example, say that Al and Bob both
work for autoshop1.com. They both take the same bus route to work one
day. So autoshop1.com, on behalf of Al and Bob, would publish a
"payment" as follows:

2009-04-06 from autoshop1.com to metrobus.gov 3.00 dollars. //Al's
payment for his bus fare

2009-04-06 from autoshop1.com to metrobus.gov 3.00 dollars. //Bob's
payment for his bus fare


Without a #some_id parameter, it would appear that autoshop1.com has
published the same payment or transaction record twice. The same
ambiguity would apply to when metrobus.gov publishes matching record
copies of the same transaction records.

To avoid ambiguity, a simple solution might be to have the transactors
agree to use metrobus.gov's 'receipt number' as an id to confer
uniqueness to each instance of payment by Al or Bob. For example,


2009-04-06 from autoshop1.com to metrobus.gov 3.00 dollars
#route63pssngr100.
//Al's payment for his bus fare, now published as a unique transaction
record in its entirety


2009-04-06 from autoshop1.com to metrobus.gov 3.00 dollars
#route63pssngr101.
//Bob's payment for his bus fare, also unique as a complete
transaction record


I don't know if I am missing something, but the way I see it, it would
be difficult to encounter collisions among **complete or whole
records** using the simple method of seller-generated id numbers that
I just described. There would be no need to coordinate universally
unique id on a global scale - but please let me know if you see a flaw
in my analysis.

Edgar

[Guillaume P. Lebleu]

On Apr 6, 2009, at 12:04 PM, els wrote:

> I don't know if I am missing something, but the way I see it, it would
> be difficult to encounter collisions among **complete or whole
> records** using the simple method of seller-generated id numbers that
> I just described. There would be no need to coordinate universally
> unique id on a global scale - but please let me know if you see a flaw
> in my analysis.

Correct me if I'm wrong, but isn't all you need a conversation
identifier between the two parties to the transaction?

In addition, I know this is probably due to PROWL design, but I would
expect transactions to be between Bob' s account and metrobus.gov's
account, and Al and metrobus.gov, not autoshop1.com and metrobus.gov.
At the very least, consider they have sub-accounts at metrobus.gov:

2009-04-06 from A...@autoshop1.com to metrobus.gov 3.00 dollars
#conversation_id

Guillaume

[els]

>Correct me if I'm wrong, but isn't all you need a conversation
> identifier between the two parties to the transaction?

As long as the "conversation identifier" that you refer to is able to
confer uniqueness to a published transaction record, then we agree
that simple mechanisms are available to avoid collisions against other
records that are also published on the web.

>In addition, I know this is probably due to PROWL design, but I would
> expect transactions to be between Bob' s account and metrobus.gov's
> account, and Al and metrobus.gov, not autoshop1.com and metrobus.gov.
> At the very least, consider they have sub-accounts at metrobus.gov:

In certain "accounting models", your expectations would be accurate.
Prowl could accomodate such scenarios by accomodating different
"accounting models" that specify which accounts could trade with whom
(Prowl itself is agnostic to such concerns outside of those user-
defined conventions.)

For example, when you mention "sub-accounts", I think of a community
currency (cc) accounting model, whereby Al, Bob and metrobus.gov are
members of the same mutual-credit accounting system such as might be
administered by "metrobus.gov" or a district such as "seattlemetro-
cc.org". This basically implies *intra-entity* transactions, where the
entity is the currency administrator.

On the other hand, the autoshop1.com example assumes a scenario where
*inter-entity* transaction has transpired. Al and Bob earns credits
that are issued to them by their employer, autoshop1.com. When they
use credits to pay for their respective bus fares as charged by
metrobus.gov, then they are really using autoshop1.com's credits to
cancel a portion of metrobus.gov self-accrued debits. This implies the
use of an accounting model such as OCAUP.


Edgar