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

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

David,

 

> 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.

Who says all is lost ?

 

I'd say that there has been a lot of very good work done by the members, by and large.

 

I'll stand by my analogy of the car without wheels.

 

Whilst it may sound sensationally bad at first, it's not something that can't be fixed.

 

Wheels are easy to fix on at the last minute in a car factory, and likewise, so are some basic XML message/element definitions.

 

The only tragedy occurs when the factory management process is so rigid that it is unable to incorporate minor design changes as they are discovered on the factory floor.

 

> 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.

On a designers CAD station, wheels don't look like such an important thing, especially when you're looking at it from a totally abstract perspective. "Think of all the weight that could be saved without the wheels" is what they'd say.

 

Anyhow, keep up all the good work.

 

I'd say ebXML should continue - stopping production just 'cos the wheels aren't on yet is no answer either.

 

David Lyon

 

----- Original Message -----

From: David Powell <david@xactcommerce.com>

To: <ebxml-core@lists.ebxml.org>

Cc: William J. Kammerer <wkammerer@foresightcorp.com>; David Lyon <djlyon@one.net.au>

Sent: Wednesday, May 02, 2001 3:34 PM

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

> 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
> 
>