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

[David Powell <david@xactcommerce.com>]

I just hate to chime in.. here.. but David and William are of one mind
here.  And both are equally wrong.  But all is not lost, because at the
heart of it they both understand the very problems that their proposed
solutions bring.  And even moreso they offer wonderous words of advise that
another direction is possible.

David is pointing to the wonderful power of XML when he writes... "The
beauty of XML is that companies can add EXTRA fields without stuffing the
whole thing up for everybody else."

Guys.. let it go.. this idea to fix on the "basic" elements of "basic"
transactions..cripples ebXML rather than strengthening it.   The necessary
core is much simpler and at a higher level of abstraction.

William was pointing to this earlier today with his somewhat odious example
of data transfers between insurance agents and the State of Ohio.. this
exchange of information is not supported by any of the "basic" transactions
proposed here.. as "inevitible" and "necessary".

Folks using ebXML will naturally gravitate to transactions forms similar to
those being proposed by both William Kammer and David Lyons.  However, if
they have a means of advertising the "transactions" they are prepared to
handle and the data elements they need or provide.. it is a quick and easy
thing for an XML coder to map the names they use onto the names offered by
their trading partner.. especially if this "Language" supports this
capability as one of its core elements.

Let the XML coders handle this simple task.  Or, even a stupid synonym
dictionary, for that matter,  for folks who want "point and click"
possibilites in some future ebXML Rapid XML Development tool.  We either
have the possibility of mapping data element names or not.  Once you have
the possibility of adding extra fields which have differing names but the
same meanings, a path is set.  To support "common names" and "local names"
then you have to have two structures for managing this communication and a
big "if statement structure" to sence and switch between them.  Why not be
more general and less complicated by starting the process of adding extra
fields at field number one.. not field number seven.  Lets quit trying to
be data element "name" control freaks.  And while we are at it... lets
throw out the "transaction name" control idea too..

This is not to say that ebXML cannot propose "example templates".  These
"examples" are just that.. guidance for the timid and uninitiated.  Lets
not attempt to "legislate" business process.  Leave this to the EDI crowd.
This is fool hardy for developing an unbounded language specification.. and
most folks in this group seem to be saying that the goal of defining the
"sacred" core of business transactions is like debating the number of
angels who can stand on a pin head.  Fun, but a waste of time.  But once
this is agreed, they go right back at it.. because this seems to be
soothing, or something.  This is a "Language" specification.. lets quit
trying to specify the allowable variable names.


David Powell
Life & Energy Systems, Inc.
700 West Pete Rose Way
Cincinnati, OH 45203
513-721-4055



"William J. Kammerer" wrote:

> David Lyon was kind enough to give us the minimum required elements
> within a simple invoice line item, consisting of code (which I take to
> mean commodity code or vendor part no.), description, comments, unit of
> [measure], rate (or unit price), quantity, tax and amount.   This has
> "...been this way since time [immemorial]," and David wants to know "why
> has [its] understanding suddenly been lost?"
>
> I would agree that David's shopping list is probably a minimally
> sufficient set of Invoice line item components for the typical SME for
> small dollar transactions.  And as expected, it's probably the same as
> what you would expect for the converse: a minimally sufficient PO line
> item.
>
> So I hit the jackpot when I selected the model from the Open Buying on
> the Internet (OBI) Consortium, consisting of almost that exact same set.
> The only differences are 1) OBI requires a line item number in the PO -
> a requirement inherited from X12 EDI (though the converse, line item
> nos. for an invoice, are not required to be returned in the IT1
> segment), 2) OBI would allow, but not mandate, descriptions and
> comments, and 3) OBI (and EDI) has no need for David's line amounts.
> And I would argue that an ebXML abstract "core" line item would have no
> need for an amount either, since that can easily be calculated by the
> recipient with a stylesheet or what-not.
>
> Given the fairly decent match between David's intuition or experience,
> and the OBI guideline, perhaps the rest of the PO's core components can
> be "discovered" from the same document.  Now we can sit an innocent, say
> Betty Harvey, down with the OBI stuff and she would be able come up with
> a reasonable set of PO core components  - even though she's rarely
> sighted one of these critters.
>
> Which was the whole point of my spiel about reverse engineering. And I
> think BP's Catalog of Common Business Processes (bpproc_v0.99.pdf)
> section on Discovery of Core Components was saying this, also.
>
> 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