Re: The initial ebXML business vocabulary - A call for a listofcandidates

[Abid Farooqui <farooqui@tampabay.rr.com>]

Oh BTW, if you see some of my postings a few days ago, I have looked at what
you mentioned
"Someone suggested that ebXML adopt XEDI to begin defining markup - XEDI
supports every X12 and EDIFACT transaction from any version - including the
examples just mentioned.  See www.xedi.org for more info."
and also suggested that to this list besides the original poster.
Abid

----- Original Message -----
From: "John Evdemon" <jevdemon@vitria.com>
To: <ebxml-dev@lists.ebxml.org>
Sent: Thursday, June 21, 2001 7:54 PM
Subject: RE: The initial ebXML business vocabulary - A call for a list
ofcandidates


> On Abid Farooqui: Wednesday, June 20,  wrote:
> >
> > In my opinion these needs are tackled even today by systems like
> traditional
> > EDI but I think that traditional EDI's weakness is in its complexity,
lack
> > of similarity between document standards across verticals, its
non-tagged
> > nature and its price (both the purchase price and the maintenance price
> > because you literally need to employ and EDI person to keep the maps
> > up-to-date, keep the software up-to-date and deal with new partners that
> > come onboard etc.).
>
> Interesting statement - EDI is, indeed, implemented differently across
> verticals.  I believe you'll see the same thing happen with whatever
markup
> recommendation comes out of ebXML.
>
> > You need an EDI consultant basically and that is simply
> > not going to work in the 21st century.
>
> Somebody better tell this to the Global 1000 using EDI to conduct
e-business
> today.  Whatever happened to the concept of leveraging and extending
> existing investments in technology?    The best approach is usually to
> preserve what works and extend it to integrate with others.
>
> > Moving on to XML based standards ... XML is simple and it provides
> > flexibility. However, flexibility requires responsibility. What I mean
by
> > that is that if we over engineer the solution (business document
standards
> > etc.) even with XML then you end up just like with EDI after everything
is
> > said and done. Too complex, requires a consultant almost full-time and
so
> > on. That is no improvement, its just change of hands.
>
> This appears to be where we are headed.
>
> Many companies that have already adopted existing XML "standards" have had
> to replace or extend them because the "standards" didn't reflect their
> internal semantics.  A realistic example is a large EDI-enabled
corporation
> using XML to communicate with SMEs.  Most XML "standards" do not support
all
> of the fields in a typical EDI Purchase Order.  Further, most existing XML
> "standards" only support a few business transactions (e.g. Purchase Order,
> Invoice, Shipping Notice).  Other transactions (such as Freight Receipt
and
> Invoice or Materials Safety Data Sheet) are simply unavailable.
>
> Someone suggested that ebXML adopt XEDI to begin defining markup - XEDI
> supports every X12 and EDIFACT transaction from any version - including
the
> examples just mentioned.  See www.xedi.org for more info.
>
> > If we are really
> > serious about solving the business problem then the requirements are
> > simple,
> > make a solution that is not necessorily perfect but applies to 90% of
the
> > scenarios, make it simple to use, administor and add partners with and
> make
> > it work across industry verticals because business does not happen in a
> > vaccum. If we should ever learn something from recent history it should
be
> a
> > lesson from Microsoft. When they first came out with Windows, the
> operating
> > system was hardly even a contendor for even close to perfect (it isn't
now
> > even) but it was simple to use. It provided the end user an interface
that
> > is much more intuitive (visual, GUI) and it had software running on it
> that
> > solved most of the common problems. This provided a marked advantage
> > over
> > Unix like operating systems even though they were and perhaps even today
> > are
> > more robust than windows. Yet you can see that windows has taken off.
>
> Microsoft was building on top of an already established "standard" called
> DOS.  DOS wasn't pretty, but it worked (much like EDI itself).   Using
> XML-based representations of EDI transactions makes them easier for
non-EDI
> companies to create and consume.
>
> ebXML seems to be looking to adopt an XML standard that is already
prevalent
> in the business community.  I suggest that we should be looking at broader
> e-business standards - restricting ourselves to custom XML-based
initiatives
> will be much more difficult (since most XML-based initiatives are rather
> immature when compared to EDI).
>
> There are currently far more companies using EDI than XML (or, more
> correctly, XCBL) for e-business.  That said, ebXML should define its
markup
> using the dominant e-business standard (EDI) as a foundation.
>
> > In essense in this particular situation with ebxml, if we are to develop
a
> > solution, we need to develop it so that it solves most of the problems
not
> > all (the ROE ... Return Of Effort, in going from most incrementally to
all
> > is too large to justify even trying) and that it is asstandard across
> > verticals as possible to reduce complexity and is easy enough to use
that
> > any decent computer user can administor and maintain it.
>
> Agreed - again, EDI is already a standard across many different verticals.
> Defining markup for these verticals should leverage the metadata
associated
> with existing standards.  XEDI would seem to provide a great starting
point
> for markup development since it already represents over 3000 business
> transactions (all of which are derived from the X12 and EDIFACT metadata
> standards).
>
> > I still favor the concept of a universal PO, a universal FNACK and so
on.
>
> Its already available - its called an 850 Purchase Order and an 855
Purchase
> Order Acknowledgement (or, in the case of EDIFACT, Orders and OrdersP).
> Granted these are EDI standards, but a quick look at the associated
metadata
> helps you realize that these documents contain the fields that most
> companies use to conduct business.
>
> > Specific
> > extensions
> > to these universal document(s) can be applied by each industry group if
> they
> > are really really needed (I discourage these from the bottom of my
heart)
> > and as that happens software patches (perhaps even optional components)
> > can
> > be released by vendors to deal with these extensions. If things are kept
> > simple I don't think moving from today's systems to the new ones will be
> as
> > painful as you might think.
>
> Your description sounds suspiciously like EDI today.
>
> The real value that EDI can provide to ebXML is in the metadata - ignore
the
> cryptic syntax and associated VAN requirements.    Leverage EDI's
> comprehensive set of metadata to define the schemas for ebXML and avoid
> re-inventing the wheel.
>
> John Evdemon
> Regional CTO/Director of Engineering
> Vitria Technologies
> www.vitria.com
> www.xmls.com
>
> ------------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org