|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
RE: One more deficiency of XML
William...
Hashes and checksums are great for keeping corruption out of the house.
And, I'll admit that TCP/IP protocols (especially those which include
managed key encryption) rarely cause problems, except in the key management
part.
It's more the in-house transfers that occur within a company that seem to
cause the most grief.
Someone pulls data off a server using "ASCII" instead of "Binary", or we
have the age-old 80 bytes problem. Those kinds of things. They do happen a
lot.
It exacerbates itself when the data is formatted in XML.
Take the 80 bytes thing...
You'd rarely, if ever have breaks in opening tags but possibly a lot of
broken end tags. There may be parsing issues in the "data" depending on
where in the value, clause, identifier, etc. the break occurs. Your parser
may be able to deal with "files of size" within a reasonable timeframe but I
don't look forward to the fixing part when good data turns bad.
You keep enlightening us with the benefits and I'll just go back to lurking.
Still waiting for that epiphany.
<LURK>
-----Original Message-----
From: William J. Kammerer [mailto:
Sent: Friday, February 04, 2005 2:24 PM
To: EDI-L Mailing List
Subject: [EDI-L] 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
.
Please use the following Message Identifiers as your subject prefix:
<SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the
list online at: http://groups.yahoo.com/group/EDI-L
Yahoo! Groups Links
|
 |
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
