Hi Randy,
I discussed the points you raised with a colleague and we came to the
following conclusions:
>XML documents are self administering. The DTD coordinates your EDI
system's
>(parsing tool) ability critique, validate, and potentially re-submit for
>corrective measures. This is very convenient.
Nothing new - EDI parsers do this too, and yes it is very convenient.
However, the parser can only tell you if the structure and data values are
legal, not if they are correct. Similarly an XMl message, even with a
DTD/schema cannot tell you what to do with its content.
>Couple the XML documents with a Java based guaranteed messaging system, and
>I am
>convinced things are easier and more cost effective. A guaranteed
messaging
>system, using Java, SNTP and w/XML as the communication packet, is a great
>solution for the exchange of data of an e-Marketplace, but the flexible
>document
>format along with a good parser enables the e-Marketplace exchange system
to
>become a "black-box" solution for business partner exchanges is a single
>solution for all eCommerce . This solution now becomes a single point of
>management for inbound and outbound commerce for trading partners and
>e-shopping. One solution!!
To be honest we didn't really understand this bit.
Surely, as described, the e-marketplace is just a VAN running over IP - some
one has
to manage it, and users have to pay to use it. If you have multiple trading
partners across market places interconnects have to be established along
with mappings between XML formats used (and abused no doubt) on different
market places. It might not be a traditional VAN managing this - but
someone has to, and they need to make a profit.
Marketplace users still need to integrate incoming messages from different
sources - each member of a marketplace is guaranteed to implement the same
xml message standard differently - if only because they will all have
implemented the same business processes differently.
So what have you got? XML instead of EDI, some different software, a
different network protocol, and yet exactly the same problems as before.
>I highly recommend a MOM (message oriented middleware) based messaging
>system
>where JAVA is the technology behind the product. JMS will permit the IT
>departments to access the message queues easily from any platform.
Fine.
>The guaranteed messaging methods requires, a parser, and a standard set of
>business object documents (for loading a 850 or sending an 850 to the MOM).
>The
>result is a the "black-box" solution will work better with any exchange of
>information from any source trading partner, external system, or internal
>system
>requiring integration with the base ERP system.
You still need to map from XML format to XML format. Yes there are mapping
tools, but then so are there for EDI - a non-issue. People make the mistake
of assuming that EDI is expensive and hard to implement because EDI file
formats are hard to understand. They think, "I can understand XML - this is
easy, parsers are free, so XML must be cheap" This is rubbish.
The hard thing is mapping between disparate systems which have expressed
the same business processes in many different ways - the classic: customer
1 wants their invoice to reflect each order exactly, customer 2 wants
invoices that reflects delivery and can mix up lines of different orders.
XML helps us write code to map between processes, but it doesn't help us to
understand the
processes themselves - and that is why implementing an xml based solution
will still be hard.
>Points for Paul Williams and Richard to consider:
>
>*XML based EDI documents are generally 10k to 40K depending on many things.
>That's not very large!
And anyway bandwidth is increasing - verbosity doesn't matter
>* Vans will still needed for less capable IT departments. The Van is
>polled
>by the receiving organization where trading partners are not ready for XML
>exchanges with your organization. Will Van's convert the X12 doc's to XML?
>Hopefully the VANS recognize the service value, and will push the XML into
>X12
>until others are ready to receive XML.
Everyone needs VANs, whether they run as traditional VANs or over IP - a
networking protocol doesn't change basic requirements. IP just opens up the
competition to non-traditional VANs
>* Will Vans starts validating XML doc's? I would expect this service is
>desirable for "lite" IT departments...
Everyone needs validation, where it happens doesn't really matter
>* Mercator (parsing tool) is very easy to manipulate. It's as least as
easy
>as
>mapping tools that accompany EDI products.
See note above - cool mapping tools do not equate to ease of mapping,
they simply allow the user to concentrate on reconciling different
implementations of business processes, rather than on a file format.
In our view the physical expression of data as xml is an advance over the
physical expression of data as edi - it is easier to write software over
xml, xml maps beautifully to object oriented programming languages -
especially Java. However an xml based solution running over the internet
still needs to be implemented and maintained by people who understand
business processes, and who can reconcile apparent structural
incompatibility between different implementations of the same processes.
True VANs need to change - new comapnies are emerging which take on the role
of VAN, but they are just as necessary as ever before - and with more and
more companies wishing to participate in e-Business, the VAN is probably
more vital than ever.
So Randy, yes EDI file formats may be allowed to die, but the VAN will live
on doing the same job as before but wearing trendier clothes.
Regards
richard
Richard Ward
Sterling Commerce
Telephone: +44 (0) 1246 279700
Fax: +44 (0) 1246 230117
[EMAIL PROTECTED]
visit our e-business demonstrator web-site at:
http://amalfi.chesterfield.stercomm.com/amalfi_pizza/
Keep visiting that web-site for regular updates!
-----Original Message-----
From: Randy Buckner [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2000 14:31
To: Richard Ward
Cc: 'Paul Williams'; [EMAIL PROTECTED]
Subject: Re: Are there really any benefits?.
Richard,
In your last comment you stated: " It's good for you but is it really worth
it?" ....50p for a 10 mile bus ride is convenient where time is
important...
XML documents are self administering. The DTD coordinates your EDI system's
(parsing tool) ability critique, validate, and potentially re-submit for
corrective measures. This is very convenient.
Couple the XML documents with a Java based guaranteed messaging system, and
I am
convinced things are easier and more cost effective. A guaranteed messaging
system, using Java, SNTP and w/XML as the communication packet, is a great
solution for the exchange of data of an e-Marketplace, but the flexible
document
format along with a good parser enables the e-Marketplace exchange system to
become a "black-box" solution for business partner exchanges is a single
solution for all eCommerce . This solution now becomes a single point of
management for inbound and outbound commerce for trading partners and
e-shopping. One solution!!
I highly recommend a MOM (message oriented middleware) based messaging
system
where JAVA is the technology behind the product. JMS will permit the IT
departments to access the message queues easily from any platform.
The guaranteed messaging methods requires, a parser, and a standard set of
business object documents (for loading a 850 or sending an 850 to the MOM).
The
result is a the "black-box" solution will work better with any exchange of
information from any source trading partner, external system, or internal
system
requiring integration with the base ERP system.
Points for Paul Williams and Richard to consider:
*XML based EDI documents are generally 10k to 40K depending on many things.
That's not very large!
* Vans will still needed for less capable IT departments. The Van is
polled
by the receiving organization where trading partners are not ready for XML
exchanges with your organization. Will Van's convert the X12 doc's to XML?
Hopefully the VANS recognize the service value, and will push the XML into
X12
until others are ready to receive XML.
* Will Vans starts validating XML doc's? I would expect this service is
desirable for "lite" IT departments...
* Mercator (parsing tool) is very easy to manipulate. It's as least as easy
as
mapping tools that accompany EDI products.
*I have not been responsible for or heard of a project where a MOM system
receives XML - EDI transmissions from a VAN. Is this possible? I hope it
is...
* If VAN's elect to not provide services to convert to XML to EDI to benefit
a
customer of yours, consider directing that partners documents "reverse"
through
the parsing, mapping tool...
If I missed one of your issues, feel free to call or email...
Cordially
Randy Buckner
Richard Ward wrote:
> Good question Paul. Really there is no benefit at all for using xml in
EDI.
> The sad thing is that the real advantage of EDI is often overlooked
because
> of a preoccupation with cutting out the VAN. xml was/is seen as a means
to
> allowing EDI over non-charging networks. Its a bit like walking 10 miles
to
> save 50p on bus fare. It's good for you but is it really worth it?
>
> Where xml is really useful is in e-Marketplaces (portals, vortals,
extranets
> or whatever current buzz word is preferred). Most business visitors to an
> e-Marketplace will have applications of their own. Using the browser to
> access the e-Marketplace will soon have them saying what they said in the
> late 70's and early 80's after suppliers had provided a nice black
screened,
> green charactered terminal into their ordering system with the promise of
> better responsiveness if they typed in the orders themselves. A few weeks
> later the instruction would come to take it away and that they were fed up
> of typing everything twice. Once into the suppliers terminal and once
into
> their own system. "No. We will send you our orders by fax or phone. You
> type them in!"
>
> Now if the e-Marketplace is served by systems that use xml and xsl the
> visitor can be attracted to the site, start working and when they are
ready
> for integration with their own systems they will have a structure that is
> perfect for the task. They don't need to do the typing twice, they don't
> introduce typographical errors in the process, they get the same
advantages
> they would have had from EDI.
>
> We find that the dynamic information is best served via xml with xsl with
> the more static information via EDI.
>
> By the way all this talking shop stuff about the "Standards" is just a
> repeat of what went on when EDI came on the scene. Just like EDI, some
folk
> just got on with it and started using it. If you want to see some
> applications in use with xml let me know. Our customers have been using
our
> xml offerings for several years in real world business.
>
> Regards
>
> richard
>
> Richard Ward
> Sterling Commerce
> Telephone: +44 (0) 1246 279700
> Fax: +44 (0) 1246 230117
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: Paul Williams [mailto:[EMAIL PROTECTED]]
> Sent: 28 June 2000 08:54
> To: [EMAIL PROTECTED]
> Subject: Are there really any benefits?.
>
> To: <[EMAIL PROTECTED]>
> Hi all
>
> Again, like a few other recently I'm a new member and this is going to be
my
> first input into the group. I have a question, it's a simple one I think,
> but
> may ruffle up a few feathers.
>
> I've recently been looking into XML/EDI as part of a work project, and as
> said
> by another member recently there is an awful lot of information out there,
> it's
> quite difficult to piece it all together. BUT I now have some ideas
about
> what
> XML can do, and where it may be used, BUT and here's my question......
>
> IS THERE REALLY ANY BENEFIT FOR USING XML?
>
> As I understand it, when we receive an XML message we will still have to
run
> it
> through an application (such as Gentran so we can map out into a format
that
> our
> database systems (such as Oracle) can understand.
> Using a Parsa and a DTD (and with all the XML tags in the file) surly it's
> more
> complicated and increases the size of the message being sent? I don't
see
> what XML in EDI can benefit the company.
>
> IS THERE ANYONE WHO MAY BE ABLE TO PERSUADE ME OTHERWISE?. (your comments
> will
> be greatly received.)
>
> Cheers
> Paul
>
> ------ XML/edi Group Discussion List ------
> Homepage = http://www.XMLedi-Group.org
>
> Unsubscribe = send email to: [EMAIL PROTECTED]
> Leave the subject and body of the message blank
>
> Questions/requests: [EMAIL PROTECTED]
>
> To receive only one message per day (digest format)
> send the following message to [EMAIL PROTECTED],
> (leave the subject line blank)
>
> digest xmledi-group your-email-address
>
> To join the XML/edi Group complete the form located at:
> http://www.xmledi-group.org/xmledigroup/mail1.htm
>
> ------ XML/edi Group Discussion List ------
> Homepage = http://www.XMLedi-Group.org
>
> Unsubscribe = send email to: [EMAIL PROTECTED]
> Leave the subject and body of the message blank
>
> Questions/requests: [EMAIL PROTECTED]
>
> To receive only one message per day (digest format)
> send the following message to [EMAIL PROTECTED],
> (leave the subject line blank)
>
> digest xmledi-group your-email-address
>
> To join the XML/edi Group complete the form located at:
> http://www.xmledi-group.org/xmledigroup/mail1.htm
--
Randy B Buckner
Director, Manufacturing Systems Group
Protech Systems, Inc.
[EMAIL PROTECTED]
New Jersey Phone: 609.714.0700 ext. 55 Fax: 609.714.0705
Atlanta Office Phone: 770.237.5421 Fax: 770.237.8348
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
