Re: To get things started.... Data formats

[David Lyon <djlyon@one.net.au>]

Todd, all,

> That is a lot of work ---and I will do it---as soon as these three vendors
> give me permission to post parts of their docs.

It's good see that you are taking on the weight of the world, old Atlas...
but other people may have be able to put in valuable input also

> My recommendation will be that these SME XML's must converge a lot of
> things.  For example here are three date formats and address formats used
by the three companies.
>
> IntAcct
>      <datecreated>
>         <year>2000</year>
>         <month>8</month>
>         <day>18</day>
>     </datecreated>

This is such a cumbersome mechanism. Both to code, as well as for the
business user to understand.

Here in Australia we've been using an approach which simplifies this to:

 datecreated@="18-July-2000"

It's much easier to parse, and is far less prone to error than the first
example.

All of the datatypes get their own denominator, for example:

 String fields,       terminated with "&",    eg Address&="23 River Rock
Road"
 Currency fields,  terminated with "$",     eg Amount$=356.24
 Boolean fields,    terminated with "?"      eg Receipt_Required?=True
 Date fields,         terminated with "@"    eg
Shipping_Date@="28-October-2001"
 Integer fields,      terminated with "#",    eg Quantity_Required#=3

Fields are then built in blocks:

<?ebxml Document, version#=1.0, encoding&="UTF-8">
<!DOCTYPE "Purchase Order">
<Purchasor Details>
  Company_Name&="Hotwire Business Systems"
  Address_Line_1&="38^/332 Handford Road"
  Address_Line_2&=""
  Suburb_City&="Taigum"
  Region_State&="QLD"
  Postcode_ZIP&="4018"
  Country&="Australia"
  Telephone&=""
  Fax&=""
  Contact&="David Lyon"
</Purchasor Details>
<Vendor Details>
  Company_Name&="Backpackers by the Beach"
  Company_Address&="^m"
</Vendor Details>
<Delivery Details>
  Delivery_Mode&=""
  Delivery_Date@=20-March-2001
  Delivery_Address&=""
  Delivery_Instructions&=""
</Delivery Details>
<Order Item List>
  <Order Item>
    Code&="290"
    Name&="Female Dormitory Bed"
    Description&="Arriving Mon 21-05-01 2:12:51 PM, Departing Tue 22-05-01."
    Quantity#=2
    Rate$=90
    Tax$=0
    Amount$=180
  </Order Item>
</Order Item List>

Regards

David Lyon

----- Original Message -----
From: Todd Boyle <tboyle@rosehill.net>
To: William J. Kammerer <wkammerer@foresightcorp.com>; ebXML Development
<ebxml-dev@lists.ebxml.org>
Cc: ebXML Core <ebxml-core@lists.ebxml.org>
Sent: Thursday, May 31, 2001 3:40 AM
Subject: RE: To get things started....


> William J. Kammerer said,
> > Todd Boyle "urge[s] the EWG to accord a high priority to publishing a
> > common horizontal set of components at an early date.  This should
> > include all party, product, location, contact and other aggregates
> > necessary for the 30 million small and medium businesses (SMB's) in the
> > US to begin automating their bookkeeping."  Todd explains that "[the]
> > ongoing cost of printing and mailing paper checks, and altogether
> > unreconciled bookkeeping mess are a national disgrace, running well
> > above $100 billion/year."  >>I will not argue about wherever Todd
> > came up with that $100 billion/year figure.
>
> Here was my calculation.  http://www.gldialtone.com/survey_of_waste.xls
>
> Whoops I was off by 1.9 Trillion
> http://www.unece.org/press/pr2001/01trade04e.htm  or is that 2.9 Trillion,
> Ray?
> Oh well, a trillion here, a trillion there.. whatever.  If Ray Walker is
> right, then every day we goof off here in Core Components is costing the
> world $10 billion!  In fact, my recent post about qualifiers is the only
> technical post for the past three days, so you guys owe me $30 billion!
>
> > Todd should share with Core Components his idea (model) of what these
> > "party, product, location, contact and other aggregates" look like.  It
> > would be preferable that he not refer us to OAG, xCBL, Intuit and qbXML
> > to find out for ourselves.
>
> I have been working, quite persistently behind the scenes here, to get
> NetLedger, Intuit and Intacct to work together and converge their XML
> schemas (SMBXML, QBXML and Intacct XML)
>
> I have some comparisons I've done privately but need their permission
> to post their schemas and parts of the docs in order to talk about them.
>
> I also have requested some indication whether the idea of standardization
> is a dead issue for them.  Obviously, people will need to know that.
>
> > I could provide a model of these aggregates, but they would probably
look
> > a lot like EDIFACT - so I implore Todd to come up with his own.
>
> That is a lot of work ---and I will do it---as soon as these three vendors
> give me permission to post parts of their docs.  My recommendation will
> be that these SME XML's must converge a lot of things.  For example here
> are three date formats and address formats used by the three companies.
>
> IntAcct
>      <datecreated>
>         <year>2000</year>
>         <month>8</month>
>         <day>18</day>
>     </datecreated>
>
>    .Mailaddress: Optional. Mail address specific information.
>    Mailaddress Sub Elements:
>    .address1: Optional.
>    .address2: Optional.
>    .city: Optional.
>    .state: Optional.
>    .zip: Optional.
>    .country: Optional
>
> NetLedger
>
>    <postDate>01/14/2001</postDate>
>
>    <shipAddress>Bailey's Training Services&#xD;950 E. Algonquin
> Road&#xD;Arlington
>    Heights IL 60005</shipAddress>
>
> Intuit (QBXML is not finished or fully documented but has clues:)
>
>    <!ENTITY % DATETYPE "(#PCDATA)">
>
>    <!ENTITY % AddressDataMacro "(Addr1? , Addr2? , Addr3? , Addr4? , City?
,
>     State? , PostalCode? , Country?)">
>
>
> The biggest problem with these XML interface schemas is that they have
> processing commands deeply interwoven with all the business data
> content.  Approximately the top 1/3 of the XML instances are going to be
> invoking methods on the host or application.  This is how OAGIS BODs
> work.  These three SME applications are more different in their
> processing than in the content of the screens for a PO, invoice,
> payment etc. so there are major dependencies in the schemas that are
> just a distraction, if you're working on standardization.
>
> There is a very huge need for separating processing logic from the data
> content in A2A integrations with these products, if we are ever going to
> get anywhere with integration with SME software.  Then we can all benefit
> from the diversity in application services, not least these Vendors.
>
> Business Processs and Collaboration Patterns work of ebXML for B2B
> interactions needs to be extended across the border to the accounting
> and business applications. These vendors are still stuck with the old
> model of "my application, my interface".  That's ok-just 5 years ago
> we were thrilled that a program even had an interface!   But now, the
> interface language has to be understandable -we can't deal with a doctor
> or a carpenter or a waitress if they speak a different language.  So,
> they don't get a job until they learn the language of the country they
> live in.
>
> I think the Vendors are emotionally confusing the issue of standardization
> of business process interfaces, with standardization like CORBA or DCOM.
> When CORBA or DCOM or Sun's Java changes, it forces deep changes in your
> code just to stay alive.  But the BP layer does not specify that level
> of the protocol stack, any more than it contains business data like
> shipping address or product codes.  The BP layer, TP layer and messaging
> has been explained a lot better in the specs than what I'm doing here.
>
> What the application is going to see coming from the TP and BP layers
> to/from 3rd parties is precisely defined business documents, within a
> very tightly defined set of request and response containers or sort of
> framework.  The application vendor benefits because there is a data
> dictionary, business docs, and a framework for specifying requests
> and responses that is cross platform.
>
> My job is to get some (bleepin') business vocabulary that I can
> understand, and then buy some business collaboration manager (BCM)
> software that does these service layers for my application, that
> doesn't cost $4 figures.
>
> http://lists.ebxml.org/archives/ebxml-bp/200012/msg00014.html
> http://lists.ebxml.org/archives/ebxml-bp/200012/msg00020.html
>
> Ok here is my own thinking and this is no guarantee.
>
> The non-interoperable XML schemas from Intuit, NetLedger and Intacct
> are useless in themselves.  You could design better data aggregates by
> going to the user interface on these application to identify the kinds
> of information they support, and then highlighting the corresponding
> elements in in the Core Components dictionary with a marker pen.  This
> would take about an hour.
>
> You could identify the common requirements from among their control
> structures
> by simply reading the instance docs, and implementing them the standard
> way with CPP/CPA and in the BPSS.  They all have very simple stuff like
> login Id, company Id, transaction Ids, Add, Update, Delete, etc.  The fact
> that ebXML didn't specify A2A integration is not really fatal, I think,
> because you could still use the B2B oriented services to encapsulate your
> own A2A/CRUD methods.  It is these methods that we need to get the Vendors
> to standardize so we can stream them thru the BSI.  And Vendors will need
> to figure out standards for accounting recognition events to local
> applications, since ebXML BPSS doesn't seem to inform both parties,
> simultaneously, of both sides of the reciprocal movements they have
> executed.
>
> I am a GL looking for A2A integration but all my clients are web
> services companies and they are going to use BCMs to conduct
> busines on the internet.  So, I can either ask them to install my
> queer proprietary interface or learn how to talk to their BCMs.
>
> Todd
> Todd Boyle CPA   (425) 827-3107
> 9745-128th Av NE, Kirkland WA 98033
> func architect, NetAccount AS, Oslo, NO
> tboyle@netaccount.com  http://www.netaccount.com/
> tboyle@rosehill.net  http://www.gldialtone.com/
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>