Re: What do people really expect from ebXML? - spinning mirrors?

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

William,

> David Lyon wants simple transactions, like POs.

Also, Pricelists, Invoices, DDs ASNs, Statement of Accounts and Payment
Advices, but that's about all for the first few rounds of ebXML..

These are just the basic building blocks of business. Without these,
business is impossible.

> Instead of agonizing over the "process," why not look and see what's been
done before? -

I can only go to so many EDI Conferences, Training Programs. They get a bit
boring after a while. I represent lot's of SMEs who want something new.

We don't want bigger and better steamtrains - we want to drive around in our
own cars.

> where presumably the authors thought long and hard into what goes into a
> simple PO.  But where should we start?

A simple set of definitions for the real basic documents of business.
Relatively common structures accross documents with little detailed
interpretation.

The beauty of XML is that companies can add EXTRA fields without stuffing
the whole thing up for everybody else.

This is such a major improvement over EDI that if I yelled it, I'm sure you
would almost be able to hear it where you are at the moment.

Therefore in a brief example a simple invoice might have the simple columns
in it's line items:

 -  code
 - description
 - comments
 - unit of messure
 - rate
 - quantity
 - tax
 - amount

It's been this way since time immorial, why has it's understanding suddenly
been lost?

Granted though, some more complex industries they may need extra columns
like:

 - conversion factor
 - colors

The point is that nothing is broken in XML when people ADD EXTRA elements
for the industry that they are in.

Furthermore, a statement of account only ever consists of basically the
following elements in it's line items (transactions):

 - date
 - description
 - debit amount
 - credit amount
 - balance

If additions are necessary in a particular industry, they can be done
without breaking the software on the receiving end on the XML transaction.

This is something that was NEVER possible with EDI, and that's why most of
us are attracted to ebXML.

> why not look and see what's been done before?

That's why we are here William, to help fix up the problems that we have
encountered in the past and not to keep reliving them with people dishing up
EDI over and over and over again. We want to move on...

David Lyon


----- Original Message -----
From: William J. Kammerer <wkammerer@foresightcorp.com>
To: ebXML Core <ebxml-core@lists.ebxml.org>
Sent: Wednesday, May 02, 2001 7:59 AM
Subject: RE: What do people really expect from ebXML? - spinning mirrors?


> Back when I was in high school, just a few short years ago, I took a
> Physics class and one of our assignments was to figure out the speed of
> light using Foucault's method based on spinning mirrors or some such
> nonsense.  Though we were provided with the materials and detailed
> instructions, I - having no patience or desire to get my hands dirty -
> proceeded to figure out how to do the least amount of work.   So instead
> of laboriously screwing around with mirrors, motors and lasers, and
> making repeated measurements, I figured if I started with the (known)
> speed of light I could just work backwards and calculate (on a computer,
> which they had in those days) the correct position and rotation of the
> geegaws.  Needless to say, I came up with a beautiful set of
> experimental observations.
>
> Unfortunately, I was the only one in the class who came up with anything
> near the correct answer - apparently the teacher had left out a step or
> two in his instructions, which would have made arriving at the actual
> speed of light impossible.  I was found out, and swore off the hard
> sciences from that day forward.
>
> Lack of patience is a family trait, as witness my great-uncle Paul
> Kammerer, from Vienna.    Uncle Paul was a Commie, and was intent on
> proving the inheritability of acquired characteristics, which would
> somehow buttress Marxist ideology. See
> http://www.mbl.edu/publications/Ciona/Kammerer/.  Anyway, instead of
> waiting to see if his experiments proving Lamarckian inheritance would
> be borne out, he supposedly counterfeited results which, when
> discovered, ended in disgrace and suicide in 1926.  Fortunately, the
> Cincinnati Kammerers came through relatively unscathed by the scandal,
> though we had for a short time considered changing the family name to
> Goebbels.
>
> Despite these unfortunate histories, I would still advocate reverse
> engineering when it comes to core components.  Instead of analyzing a
> "process," which is messy, - and besides, the process may not give us
> any idea of what the data requirements are - we should just work
> backwards and mine core components from already existing materials like
> EDI guidelines and EDIFACT directories.
>
> David Lyon wants simple transactions, like POs.  Instead of agonizing
> over the "process," why not look and see what's been done before? -
> where presumably the authors thought long and hard into what goes into a
> simple PO.  But where should we start?
>
> Simpl-EDI sounds, well - simple. See
> http://www.e-centre.org.uk/products_edi_simpledi.htm  But simplicity
> belies its name - the EDIFACT messages are simple only because
> assumptions are made on the use of sophisticated databases keyed on EAN
> (UPC) codes and EAN GLNs.  Simple - yes, but for LEs (Large
> Enterprises)!  Maybe a more fruitful model is that of the Open Buying on
> the Internet (OBI) Consortium, whose specification provides for a simple
> ASC X12 850 PO;  see http://www.openbuy.org/.
>
> If my arguments aren't convincing, then have a look at the ebXML Catalog
> of Common Business Processes (bpproc_v0.99.pdf), whose section 6.4 -
> Discovery of Core Components - notes the following:
>
>    The catalog of common business processes is useful for
>    discovery and analysis of core components that will be
>    used as the building blocks for deriving business documents
>    within a given context. This can be done by checking all
>    sources of documents listed and cross-referenced on the
>    Common Business Process Catalog to identify a document that
>    may have the information needed (which may be EDIFACT, X12,
>    xCBL, RosettaNet PIPs, CII, OAG BODs). There may be an
>    existing document, which is similar and could be evaluated.
>    Next identify if the document components meet the business
>    requirements. If so,  then these components can be reused.
>
> Sounds reasonable. I'm sold.
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>