|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
RE: <ADVOCACY> Why I Don't Like XML
There are always trade-offs for any technology or IT architecture. The
trade-offs must be balanced against both business and technical functional
requirements. If the **only** requirement were to be able to transmit a
short concise message using as few characters as possible, then of course,
X12 or UN/EDIFACT could be a logical choice. But, when - ever - was this the
single and only requirement?
There are a whole host of requirements.
My good friend & colleague, Mike Rawlins, wrote an excellent paper (his
masters thesis?) on this topic a while back. Perhaps he'd be willing to
share a portion of that paper discussing this.
Rachel
Rachel Foerster & Associates, Ltd.
39432 North Avenue
Beach Park, IL 60099
Voice: 847-872-8070
Fax: 847-589-8081
_____
From: Hurd, Richard [SLCUS] [mailto:
Sent: Friday, February 04, 2005 11:21 AM
To: EDI-L Mailing List
Subject: [EDI-L] <ADVOCACY> Why I Don't Like XML
> -----Original Message-----
> From: William J. Kammerer [mailto:
> 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.
FILE-CONTROL.
SELECT REPORT-FILE ASSIGN TO UT-S-REPORT01.
I'm all about that.
> 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.
Careful, Bill, people will be quoting you out of context like I just did.
:)
> And anything X12
> syntax can do, XML can do equally well - or better.
In the interest of fairness, I'm leaving this in there. :)
> 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.
First of all, I thought the whole point of XML was that you wouldn't need to
read it; the style sheets and parsers and whatnot would just know what to do
with it.
But that brings up a different issue for me. I think you put your finger on
part of the problem I have with XML... and this is my own personal discord,
so it has no basis other than (a) a lingering distrust of something I can't
quite get my arms around and (b) my natural predilection to have things nice
and neat.
The XML syntax for the above example would read something like this, would
it not?
<BuyerParty>
<Party>Wile E. Coyote</Party>
<Address>123</Address>
<StreetName>Roadrunner Lane</StreetName>
<City>Flat Rock</City>
<State>NV</State>
<Zip>12345</Zip>
</BuyerParty>
How about the X12 version of the same data?
N1*BP*Wile E. Coyote.
N3*123 Roadrunner Lane.
N4*Flat Rock*NV*12345.
That is... let me see...
44 characters of actual content.
(Wile E. Coyote123Roadrunner LaneFlat RockNV12345)
and
17 characters of "stuff" for X12
(N1*ST*.N3*.N4***.)
and
125 characters of "stuff" for XML.
(<BuyerParty><Party></Party><Address></Address><StreetName></StreetName><Cit
y></City><State>NV</State><Zip></Zip></BuyerParty>)
We have a trading partner with an odious program (that they recently
retired, thank $DEITY) called "one on one." The way it worked was that one
SKU was shipped per pallet if there were more than 5 cases per SKU. What
that meant, essentially, was that the cube utilization of smaller orders
went down dramatically, as we ended up shipping more wood to the customer
than product if we couldn't combine orders on the truck. A very non-value
added activity.
Our argument to the customer for cancelling 'one on one' - how about the
efficiencies in unloading one truck rather than two? And having to process
and store all those extra pallets? The small increase in the accessorial
charges were FAR offset by the other huge cost efficiencies gained in the
system.
Now maybe it's the puritanical spirit in me, but geez, if I'm spending damn
near twice as much time, data storage and bandwidth shipping my delimiters
as I am to ship my data (44 bytes versus 125 bytes), well that to me is just
plain dumb. I don't care how cheap it is, I don't care how fast your data
link is -- if you spent twice as much time shipping data than overhead, your
throughput would double. Wouldn't it?
As I said, that's just my opinion. The fact that I can read the tag within
the XML data is slightly less important to me than being able to
double-click on a document (say, an EDIFECS online standard) and figure out
what an N1*BP is - and I have plenty of people on the business side who can
do just that (not just EDI folk.)
So I remain unconvinced. Sorry.
[Non-text portions of this message have been removed]
.
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
* To visit your group on the web, go to:
http://groups.yahoo.com/group/EDI-L/
* To unsubscribe from this group, send an email to:
<mailto:
* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]
|
 |
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
