Title: RE: What do people really expect from ebXML? - Core components..

Philip,

Yup, I
remember those days when mainframe timesharing was it; and ALGOL with the
Beatles and a little free love was a popular in Europe and other
places.

I suppose by your definition of data modeling, it'd be fair to
include ANSI X.12 and the UN/CEFACT EDIFACT process as data modeling in their
own way ? Especially now that CEFACT mandates models with all new EDIFACT
messages.

Also
when you say xCBL doesn't have a data model, are you asking or stating a fact ?
I wasn't sure by your words.

I come
from an era when IT was called Data Processing. The truth of the fact that
Computer Systems produce data has not gone away despite the change in name
from DP to IT.

You
may design the most sophisticated process in the world e.g the best factory -
but if you have no raw material i.e data you cannot do much. However even if
you have very unsophisticated processes but do have raw materials you can
create something of value viz. The pyramids in Egypt.

ebXML
has concentrated on process, often to the detriment of what is being
processed- the data.

A
process model is part of ebXML but I have not seen a data model of any note.
xCBL seems to be something which exists and may perhaps be a starting point
for some core componenets - but even this does not seem to include a data
model - but it may be that I missed it.

At Bolero we
have been data modelling - amongst other things for nearly 2 years - and have
come to a number of conclusions which could be of use, when this work moves
forward.

Subject: RE: What do people really
expect from ebXML? - Core Components -Transactions!

The sentence "enable a global
electronic marketplace where enterprises of any size and in any
geographical location can meet and conduct business with each other
through the exchange of XML based messages" is a strong statement
that about using xml messages.

Maybe to my reading I'm picking up a more important message
from the text. Yes, I agree with you there's a strong statement of
XML will be used, but I would have thought an even stronger statement
comes across that ebXML is about getting people around the world to meet
and conduct business with each other.So
the challenge for us all would seem to be about addressing how
business get's done; ie. what's behind/beyond the events and activities
that revolve around an actual XML message flow.

The move of traditional EDI from a document based
focus to a Business Process modeling approach, seems to promise to be
an interesting (and very challenging) activity to
come.

The technical architecture document
that is available is lacking on details as how to make the above
statement a reality.

Well an architecture is usually a statement of form and/or
function, while the mechanics can be found in more technical
specifications plus other supporting documents. There's some truth to that
w.r.t. ebXML, and there's a full set of publically available documents for
everyone (including yourself) to
review.

I am hoping that this mailing list will
enable me to find out more about the core components so that we can
achieve the above stated goal.

If there is any way that I may be able
to help, I would be glad to offer my services.

Reviewing the ebXML documents out for public comment
would be a great start.

It's good you voice an open opinion, and you can review the
ebXML material today, which is a very positive strength of
having an open ebXML development process; as opposed to some other
closed technical developments.

Subject: RE: What do people really
expect from ebXML? - Core Components -Transactions!

Sorry David,

People need world peace, a good solution to world hunger and a
cure to Diabetes, but failing that and much more
.....

EDI or not
...

(Business) People need (better) Business
Processes

.... and part of processes are Business Transactions; and
part of transactions are Business Documents - which is where Core
Components start coming into play and probably something more closer to
what I gather you might recognize from some of the traditional EDI files
people exchange today.

Perhaps you can best check your source who has been
informing you about ebXML, and I do beg to differ as to what ebXML is
being 'marketed' as !

I can only advise you to review the ebXML documents that are out
for public review for some time now, perhaps starting with the ebXML
Technical Architecture.

ebXML right now is about setting the stage so the world can do
business electronically.

Although we'll all get to reap some specific immediate benefits,
ebXML is not specifically about another way for data transport or
yet another way to made an 'edi file'.

And where we go from here ...... NOW the real hard work begins
for us all in business and industry associations !

I was led to believe that ebXML was all
about defining some standard XML transactions for eb.

What the world expects is some simple XML
documents for:

- Product Catalogs

- Purchase Orders

- Invoices/Receipts

- Payment Advices

- Statement of
Accounts

The work isn't hard. There are hundreds
of different definitions around and thousands of people who will
willingly do the work.

All that is needed is just to choose one
simple set, document it, and go through a revision process just as
with EDI. That's what I've been told ebXML would be
doing.

Presently, the problem isn't lack of XML
definitions, it's having a well balanced set.

Operating under the auspices of the
United Nations, and the way that ebXML is marketed, a lot of people
with EDI experience have been given the impression that ebXML will
define some XML transactions not dissimilar to EDI. That is *a very
real expectation*.

People really are expecting an XML
transaction set from ebXML. Especially those with an EDI
background.

Subject: RE: What do people
really expect from ebXML? - Core components..

David,

ebXML has
never intended to create transactions as a deliverable. In
fact, ebXML does not even have a requirement to develop the
specifications to develop them. Is this a failure of
ebXML - in my opinion yes. Do we need these documents
quickly - yes. Is it best if a single consistent approach to
schema design, naming conventions, use of ancillary W3C
specifications is developed by an international, neutral standards
body - yes. Will we get them quickly - doubtful if after 18
months we still don't have an agreement on what it is we are
developing a process for.

Mark

> -----Original Message-----> From: David Lyon [mailto:djlyon@one.net.au]> Sent: Monday, April 23, 2001 11:01 PM> To: ebxml-core@lists.ebxml.org> Subject: Re: What do people really expect from
ebXML? - Core> components..> > > All,> > We really need some XML specifications for the core
> components of ebXML, as> we have products that we really want to ship
later in the year.> > It appears as though there are some difficulties in
defining the core> components, although
I note there have been some good efforts in the> directory area and so forth.> > If ebXML needs to produce
documentation quickly, then I would suggest> concentrating on the most important things as far as eb
is concerned.> > In my opinion, there are four documents that need to be
> designed, or adapted> from existing patterns.>
> They are:>
(1) The Purchase Order>
(2) The Invoice / Receipt / ASN>
(3) The Payment Advice>
(4) The Statement of Account>
> With documentation that describes these
four documents, a lot > of pressure
on> ebXML could be dissapated.> > I've seen that we
have quite a few people here who are >
sufficiently skilled> to make a start on
these components. Also, Edifact/X12 could > quite easily be> stripped to
produce a relatively simple subset. It doesn't need to do> everything, only the basic stuff.> > Forgive my
optimism, but we have Customers who really want to > bash some of> these messages
around. It's costing me money every day that > ebXML is not> going, so if
called upon, I'd certainly be willing to help.> > Take care all> > David Lyon> > > > > > > >
------------------------------------------------------------------> To unsubscribe from this elist send a message
with the single word> "unsubscribe" in
the body to: ebxml-core-request@lists.ebxml.org>