|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
One more deficiency of XML
Martin, the most reliable means of detecting corruption is to use some
kind of cryptographic hash; this is pretty much standard in EDIINT and
ebXML messaging services. The error correction protocols in the
underlying transport method also ensure that information isn't garbled.
To the best of my memory, we haven't seen many of the garbled
transmissions you're talking about when using TCP/IP protocols like
HTTP, SMTP and FTP. And what few "garbles" we've encountered have mostly
been a mismatch between character sets. What the heck are you using that
this is a significant problem? I don't even think I've had that many
problems with Kermit!!
Nevertheless, I'll add this "deficiency" of XML (or rather is it a
deficiency of your communications protocols?) to the list.
William J. Kammerer
Novannet
Columbus, OH 43221-3859 USA
+1 (614) 487-0320
----- Original Message -----
From: <
To: < <
Sent: Friday, 04 February, 2005 01:21 PM
Subject: RE: [EDI-L] The Ubiquity of XML - again.
Every time this issue gets revisited, I find myself wondering what I'm
missing. I just don't see the need to change horses (sorry) without real
business benefit. I'm hoping for an epiphany this time around.
I do have a slightly related question for the XML experts, though... I
know all those XML parsers out there do a great job of keeping the data
well-formed and validated throughout. But what happens when there is a
problem during transmission that "changes" the data in a way that makes
it no longer "well-formed"?
We see this kind of corruption, usually related to intersystem
communication, in most all the traditional EDI file types in use today.
When the data gets corrupted in one of the traditional formats, it's
usually a simple matter to open it and see what went awry. If an XML
file is no longer "well-formed", what is the procedure for identifying
the problem? (Assuming none of the XML parsers/viewers/editors are able
to work with it).
Many of the text editors I've used work acceptably on traditional files,
but start to labor on the larger ones. They'd be brought to their knees
on the same files represented in XML.
-----Original Message-----
From: William J. Kammerer [mailto:
Sent: Friday, February 04, 2005 7:53 AM
To: EDI-L Mailing List
Subject: Re: [EDI-L] The Ubiquity of XML - again.
Bill, you might get me to admit that XSLT is an inappropriate means to
transform XML to a printed report or flat file. Howard or I would
probably use COBOL for the final report generation.
But at the risk of beating dead horses, pray tell when is XML ever
inappropriate for outward-facing B2B interoperability? Let's be
even-handed about this: I can't even think of that many applications
for which X12 or UN/EDIFACT syntax would be inappropriate, except
perhaps for "real" binary data like JPEGs or PDFs. Excluding those
BLOB - Binary Large Objects - cases (for which the X12 BDS or BIN, or
better yet, the 102 - Associated Data Transaction Set, were designed),
X12 syntax (or, for that matter, UN/EDIFACT) is perfectly competent at
carrying anything from POs and Dispatch Advices all the way to oil
drilling geologic data and toxicological reports. And anything X12
syntax can do, XML can do equally well - or better.
The unsuitability of XML has been repeated so often and loudly (most
recently by you and Andres of England), without rationale. If people
believe what's repeated, I'm afraid that efforts like UBL and CICA will
be ignored. We don't want that to happen. Do we?
After all, even you would agree that - syntax aside - it's easier to
understand what the XML element "StreetName" means when it's ensconced
within "Address" within "Party" within "BuyerParty", even if you didn't
have the schema. Try doing the same with the N3 segment without the
standard or IG readily available.
William J. Kammerer
Novannet
Columbus, OH 43221-3859 . USA
+1 (614) 487-0320
|
|
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
