RE: What do people really expect from ebXML? - Is CC really asetofLegos?

[Todd Boyle <tboyle@rosehill.net>]

Strongly agree with Philip.

> -----Original Message-----
> From: Philip Goatly [mailto:philip.goatly@bolero.net]
> Sent: Tuesday, May 01, 2001 12:58 AM
> 
> Hi Folks,
> 
>     I believe that a consideration of what data is essential in all
> transactions i.e what cannot be left out in any transaction( as 
> defined as a
> transaction in business terms) allows one to model a top down structure.
> Since these pieces of data are 'essential' then they must always be
> processed. It follows therefore that when one starts with this scenario,
> with the 'top level data' and the 'top level processes' the data and
> processes are intrisically bound together. The top levels can then be
> expanded to more detail.

I think there are six data aggregates in every binary transaction.  

1. amount  --  a currency/value pair
2. date/time  --  ISO 8601 date/time formats
3. two party identifiers  --  DUNS or other globally available party codes
4. what we exchange  --  A text string or a complete document or contract
5. due date / when do we settle  --  ISO 8601 date/time formats
6. how do we settle  --  codes such as EDIFACT payment codes and terms, 
      bank/settlement provider, IFX/OFX information, etc.

I'm not optimistic that the world will agree on the last two. 
But the first four are pretty darn obvious.  Party Ids are not
always disclosed therefore, aliases sometimes apply.  "sold to the
guy with the yellow shirt"... but Parties are not null.

This model excludes interactions that are not economic exchange events,
such as exchange of catalogs.  Thus, the model is tautological, and
trivial.  It defines a transaction as any exchange between two parties 
that has amount, date, and something bought/sold... then enumerates 
the data elements as amount, date, party ids... whoopie.

Todd