David,
You are
right transactions, transactions,transactions.
But what
is a business transaction ?
I would
suggest that a transaction encompasses all those actvities that get the
goods/services to the buyer and the payment to the seller. When the Seller has
the mony and the buyer has the goods the transaction is over.
This
definition ties in fairly well with the legal requirements and the fact that one
particular document can be used at variuos stages of this global
trnasaction.
Within
this transaction there are sub-actvities.
ebXML seems to have a rather different view of a transaction - correct me if I
am wrong - but it appears that an ebXML transaction is a 'document exchange'
within my definition of transaction.
Cheers, Phil
----- Original Message -----
Sent: Wednesday, April 25, 2001 10:20
AM
Subject: Re: What do people really expect
from ebXML? - Core Components-Transactions!
Margeret,
> Your source is correct, and nowhere in here
does it say that it will define
> transactions. The key words within the
definition below are "specifications"
> and "framework" - not
"transactions"
The statement from the homepage says something leading in quite
a different direction.
"to 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"
My point is that business is built on transactions. A business
without
transactions is like a fish without water; if the business doesn't have
transactions
then it ceases to be a business. Am I not correct here ?
So what point is ebXML without transactions ? that specificially means
that
you can't conduct business. That's not what the www.ebxml.org homepage
says. It specificially says "conduct business"
Anyhow, you go on to say something about about transactions:
> The whole idea of the ebXML initiative is to
develop the specifications and
> framework so that the transactions can be
developed in a consistent
> way, using the Core Components that arise
from the business process models.
So really, you are acknowledging that transactions are a part of ebXML
(and agreeing
with the opening statement on the homepage. That's good to
see.
Regards
David Lyon
----- Original Message -----
Sent: Wednesday, April 25, 2001 5:47
PM
Subject: Re: What do people really
expect from ebXML? - Core Components-Transactions!
David
Your source is correct, and nowhere in here
does it say that it will define transactions. The key words within the
definition below are "specifications" and "framework" - not
"transactions"
The whole idea of the ebXML initiative is to
develop the specifications and framework so that the transactions can be
developed in a consistent way, using the Core Components that arise from the
business process models.
These are being developed with the past
experience (which can also be read as 'mistakes') that the UN/EDIFACT and
X12 business people bring to the table.
Sorry to disappoint you, but I (and I hope all
the others) believe that this is the best way forward.
My 0.0005USD cents worth!
Margaret Pemberton
----- Original Message -----
Sent: Wednesday, April 25, 2001 3:36
PM
Subject: Re: What do people really
expect from ebXML? - Core Components-Transactions!
Mark,
To quote my source:
What is ebXML?
ebXML is a set of specifications that together enable a modular
electronic business framework. The vision of ebXML is to 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. ebXML is a joint
initiative of the United Nations (UN/CEFACT) and OASIS, developed
with global participation for global usage. |
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.
The technical architecture document that is available is lacking
on details as how to make the above statement a reality.
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.
Regards
David Lyon
----- Original Message -----
Sent: Wednesday, April 25, 2001
3:02 PM
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 !
Well that's my 2 cents and I'm quoting
myself.
Thanks
Dave Welsh
People need transactions !
How can ebXML ever work if it doesn't
have transactions ?
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.
Take care
David Lyon
----- Original Message -----
Sent: Tuesday, April 24, 2001
10:36 PM
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 >
|