OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Definition of Business Processes





Christian, do you see this group developing the common business objects and how
do you see incorporating the work you are doing with t9.  I'm struggling to
understand this.




Christian Huemer <ch@ifs.univie.ac.at> on 02/13/2000 08:33:59 PM

Please respond to Christian Huemer <ch@ifs.univie.ac.at>


To:   andrew.chilcott@stpsolutions.com
cc:   ebxml-bp@lists.oasis-open.org, ebxml-core@lists.oasis-open.org,
      un-tmwg-tg5@sfo.harbinger.com (bcc: Beth Grossman/ACORD)
Subject:  Re: Definition of Business Processes




Andrew wrote:

> 1. Whilst I agree that SME's need some form of generic template to
> start from, I really cannot see that it is possible for a global
> organization to determine a detailed process that would be globally
> acceptable.

andrew, i completly agree.
this is why ebXML is only delivering a framework (and not content on
message level). nevertheless, the identification of common business
objects - what ron mentioned - is very crucial for the success of
ebXML. these common business objects have to be shared by all
ebXML compliant solutions for business transactions.

this means that there will be different solutions  for
ordering. but all extend the same common
business objects. so there will be different software moduls
for different solutions. but since they share the same common
business objects they are extending the basic solution. oo-software
development should ensure the usage of reusable components and
therefore keep the costs at a minimum.


> 2. There are enormous merits in defining a very basic generic framework
> that all ebusiness can use. However, I would suggest that this should go no
> further than defining basic structures ie. Orders, Order Confirmation,
> Delivery, Invoice, Payment and the mechanism for passing Standing Data
> between the parties to a transaction ie Name, Address, Tel etc etc.
> 3. ebXML cannot do this in isolation - there are other organizations
> working on generic XML Schema that will be in practical use before ebXML
> produces a recommendation. In particular can I refer you to www.basda.org
> where some 200 of the world's leading accounting and business software
> houses have agreed an XML Schema.

i also agree on these points. ebXML cannot do this in isolation. therefore,
ebXML is an initiative that is open to anyone.

we know that there are existing 'vertical' solutions, which work quite
well. but this situation is very similar to that of traditional EDI
standards in the 70's and 80's. There were also quite well working
branch specific solutions on the market (that's what people told me,
i was to young those days). but cross-industrial interchanges caused
a problem. this led to X12 and UN/EDIFACT. therefore we should not
repeat this mistakes again. i mean it is already too late, but it
would soon get worse.

therefore, we hope ebXML will become the framework for a sigle global
electronic market. this hope is based on the fact that the initiative
is hosted by the two major organisations of the edi and the xml world.
so we hope that you can convience the guys from basa to join the
project.

christian








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC