----- Original Message -----
Sent: Monday, June 25, 2001 10:25
AM
Subject: RE: The initial ebXML business
vocabulary - A call for a list ofcandidates
Folks,
When ebXML was in its embryotic state, there was a general
feeling that using existing EDI element identifiers would be undesirable, they
would not reflect the directions towards business process solutions. However,
now that ebXML approaches a mature stage and universal element names appear
light years from resolution, I am not so sure about this.
The UNTDED (UN Trade Data Elements Directory) which is the
core of all UN/EDIFACT messages, contains descriptions of all elements by
number and short description plus attributes. As an example, DE1004 is a
"Document/Message Number". A similar identification in X12 is 324 "Purchase
Order Number".
The advantage of the UN over X12 was that DE1004 could be
applied to any business document to number it. The type of document is
identified clearly in an XML document so the more generic element name is
justified. If I was sending a EDI DESADV (despatch advice) in response to a
EDI ORDERS message I would identify the original purchase order using
again, DE1004 "Document/Message Number". No confusion and universal
applicability.
I note that the UCC-EAN GCI usage is element name = Document,
Attribute of ID. Fairly close to the UNTDED.
XML schemas developed by various organisations have used the
existing EDI UNTDED conventions and have been able to accelerate their
releases. The outstanding variation to this is RosettaNet which has been
developed by a specific Industry although with some leaning on X12. Other
industry members have expressed interest in using the RosettaNet element
identifiers.
If I was developing my own schema my logical choice would be
to fall back on the years of effort put into the UNTDED. XML purists however
would pull their hair out no doubt with cries of "..but it does'nt matter!".
After all is'nt this the very essence of XML, use any element name you like
but define it clearly.
Having said that, the argument for a universal approach for
element names in electronic business messages has been widely accepted.
As there are numerous schema developments for the business community taking
place every day and everybody confident in their approach, it would appear
that a 'new' universal vocabulary will present difficulties in bringing to
fruition - should we persevere?
With the capability of extensibility within the XSD schema, we
could namespace to a UNTDED vocabulary, or other vocabulary for that matter.
What I am suggesting here is re-writing, or use as is, the existing UNTDED for
ebXML use. History has shown that no matter how close we get to a universal
development, there is always some differentiation required by a user that has
not been foreseen. EDI was difficult to change, XML is more
sympathetic.
I can look back on at least 12 years of waiting for
application software developers to interface to EDI messages and with little
response. I do not believe that there will be a rush to support XML. There are
around 1000 different back-office and ERP applications in use here downunder
within our comparitively small business community. Middleware software
providers can ease the burden and accelerate the uptake of XML particularly
with the use of any-to-any translation software now firmly in place.
Wavell Cole
-----Original Message-----
From: John
Evdemon [mailto:jevdemon@vitria.com]
Sent: Friday, 22 June 2001 9:55
To:
ebxml-dev@lists.ebxml.org
Subject: RE: The initial
ebXML business vocabulary - A call for a list
ofc
andidates
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