Mark, I'm kind of curious how long something has to be in the marketplace
and tested in the industry before it's not "new". I actually think most
businesses (more specificially - most I/T shops) are using the "new" excuse
to avoid change. HTTP/SSL is used daily (if not every second) to send
information securely across the Net. I know of several businesses who are
sending financial transactions using EDI-INT as the standard (I won't name
them as I don't have their permission to publish nor does it make good
security sense to publish that information). HTTP-S is a transport protocol
that can be used for application-application communication realtime. It's
not just for browsers. The nice thing about it is that it flows over common
ports through firewalls and has well-defined listeners. EDI-INT specified
both S/MIME and HTTP-S as the two protocols for transmission to provide
options for the industry (thank goodness for options).
If you are pulling your XML into your browser, then you need more
information on how this technology can be implemented. XML provides a
general purpose language specification with commonly available parsers that
can turn those elements into application-readable elements. Not only can
you write code to read these elements and act on them but software vendors
can do so and are. XML provides a simple specification for defining and
managing data and metadata. Granted it might be a little more bulky than
some of the current EDI specifications but the inventory of tools that can
accept and manage this information far exceeds anything in X.12 land.
Now for my two cents on the overall XML issue. XML by itself does not solve
the underlying problem of defining and describing the information exchanged.
There is one of the primary common elements between XML and trad EDI. Until
the information is clearly defined and accepted, you are in point-to-point
solutions and get varying degrees of value from the exchange (I say varying
because if that's the only exchange you have the benefits are big, if that
is one of many exchanges the benefits of point solutions are marginal). I
strongly encourage X.12 to continue it's effort of embracing and adapting
the existing standards to XML. I don't advocate porting as you can't take
advantage of the rich definition and syntactical validation you get with XML
and it's host of specifications. I do suggest taking the existing
standards, converting them to some modeling tool (Rational Rose comes to
mind), and producing a richer and more robust standard that is based on the
wealth of knowledge used to create the original standard.
----------------------------------------------------------------------------
-
Randy Bear
USAA - I/T Architecture
Phone: (210) 913-2142 Email: [EMAIL PROTECTED]
...the opinions expressed are those of the author and not those of USAA...
-----Original Message-----
From: Mark Kusiak [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, January 31, 2001 2:44 PM
To: [EMAIL PROTECTED]
Subject: Re: More Words of Current Wisdom on XML
Scott,
Secure Internet protocols such as S/MIMI, HTTP/ssl or FTP/ssl exist,
and your right
to say they are there. But they are new technology. Most businesses
are fickle about
placing "critical information" on the internet. Invoicing
information is a case in
point. It has always been left up to the desires of the two or more
involved parties as
to their abilities to compromise on the point. It definitely
requires a shift in the
"existing" paradigm. My point on this statement is that EDI data can
be transported
across the internet. The Paradigm here is that the internet is an
unsecured media.
The afore mentioned protocols may be secure, but that has yet to be
proved as the
end all solution. They need a little more burn in so to speak.
I have not seen a browser handle EDI data, but I've also never seen
a browser load
anything into an application either which is exactly my point. The
browser also
will not load XML data into an application.
Where are the savings of being able to move to XML so that I must
hire large
work forces to handle what I currently have happening today by
machine?
These are the issues being dealt with in the field. The only
solution is how
long can I push this out so that I'm not forced into doing these
things by the
800 Lb Gorilla......
Mark
-----Original Message-----
From: Scott Jolly [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 31, 2001 11:35 AM
To: [EMAIL PROTECTED]
Subject: Re: More Words of Current Wisdom on XML
Mark Kusiak wrote:
> I agree with Brian. I also read the article. One issue mentioned
was
> that EDI dataCANNOT be sent across the INTERNET. WRONG, it can as
long
> as you don't mindeveryone else having access to and utilization of
the
> information.
>
> What happened to S/MIME and HTTP/ssl or even FTP/ssl? When
companies
> use the Internet as
> a transport, they need to think about how secure the data needs to
be
> when working out the details with
> partners.
>
>
>
> EDI likeXML can be routed across the internet.
>
> The persons who can build the mouse trap which allows for the
> securing of thedata over the internet that is generic yet secure,
will
> be in a good position.I am looking at XML closely and it's great
if
> you want to have get and display(XML's version of rip and read)
with
> very little interface with an application.It's great if you want
to
> have a clerk read the information off of a displayedform and enter
the
> information into your application. Making it so a human doesnot
have
> to enter the data into the application is where the cost of
> exchangingelectronic formats are highest. XML does not solve this
> problem or reduce thosecosts associated with it.
>
>
> I would argue these points. Never before have vendors pledged and
> started to
> deliver on having there applications produce and accept XML. I
have
> seen press release and
> demos from folks like SAP, Peoplesoft, JD Edwards, Great Plains,
> Microsoft and Oracle that all are
> working on having XML as the input or output.
>
> Ever see Internet Explorer or Netscape Communicator 6.0 handle EDI
> data???
>
> I have been around EDI for about 10 years. I was supporting M2/4
at a
> carrier when TDCC was still in
> use and was in awe when most carriers started to use 003020. I
> realize that several years may pass before
> all of the wrinkles are ironed out with XML, I place hope in the
ebXML
> effort to standardize some of the issues.
>
> One will still have to write the interfaces that arethe most
expensive
> portion of the process with more robustness piled on to handlethe
> things that XML will "pass on to the application". If "the
> application" isa human being, then it becomes a training issue, if
> it's a computer program, itbecomes an even more expensive
proposition.
> Sorry to the SME who was suppose tobenefit from the reduced costs
of
> XML!!!
>
> I don't think this is about the SME, it is about the larger
company
> that using the Internet can reach all of his partners
> in a cheaper more effiecient way than doing tradationally more
expense
> VAN based EDI (some of my best friends work at VAN's).
>
> When viewing a web form (and not a fax), it really doesn't matter
if
> it started as XML or EDI, just that it is no longer a fax handled
> individually by the sender and that the response from the SME is
not
> going to be touched by a person, but go all the way to the system
of
> record...
>
>
> Scott
> "all opinions are strictly my own"
>
> XML is the same buzz word that EDI was twenty years ago.EDI needs
to
> get to the internet so that there is a deliverable working
> processwhich doesn't cost an arm and a leg to move data. Even a
first
> class mailing inUS costs $.35. My point is that it costs to move
data
> around and will continue tocost as time goes on.....
Mark-----Original
> Message-----From: Brian Lehrhoff
[mailto:[EMAIL PROTECTED]]Sent:
> Wednesday, January 31, 2001 7:54 AMTo:
[EMAIL PROTECTED]:
> Re: More Words of Current Wisdom on XML Ok, I've read the
"article."
> Doesn't EDI fix most of the problems that hesays are broken
features
> in XML? I get challenged constantly with "Thismethodology seems to
> work pretty good, but, if anyone can come up with abetter one that
> works i'll gladly take a look at it." And I'd sure like a piece of
> that 12 month, $1,000,000 project to fixsomething that isn't
> broken. "William J. Kammerer" wrote: > Thanks to Greg Olsen, of
> Contivo, Inc., for discovering this gem. See> "Technologists
Debate
> the Best Way to Implement XML," by Peter Lucas,> published
01/22/01 on
> Ecomworld.com. Anytime you let a "journalist"> loose with a word
> processor, misquotes, havoc and lies invariably> abound. Even so,
the
> trash to text ratio in this one is so excessive> that a mere two
> snippets hardly do it justice. Read for yourself at>
> http://www.ecomworld.com/online/columns/read.cfm?contentid=381.>>
"In
> addition, structures defining XML documents are inherently>
> simpler...The structure is so simple that e-mail can qualify as an
> XML> document.">> "...Unicode, an 18-bit coding language created
by
> Microsoft Corp,> Redmond, Wash,...supports 64,000 definitions per
> character and can> translate documents written in almost any
> language.">> William J. Kammerer> FORESIGHT Corp.> 4950 Blazer
> Memorial Pkwy.> Dublin, OH USA 43017-3305> +1 614 791-1600>> Visit
> FORESIGHT Corp. at http://www.foresightcorp.com/> "Commerce for a
New
> World">>
>
=======================================================================>
> To contact the list owner: mailto:[EMAIL PROTECTED]> Archives
at
> http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
--%%%%%%%%%%%%%
> cut here %%%%%%%%%%%%%%%Brian Lehrhoff ([EMAIL PROTECTED])EDI
> ConsultanteB2B Commerce212-703-2121%%%%%%%%%%%%% cut here
> %%%%%%%%%%%%%%%
=======================================================================Todiv
> > contact the list owner: mailto:[EMAIL PROTECTED] at
> http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
