|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
RE: <ADVOCACY> Why I Don't Like XML
No doubt there's many ways to skin an XML cat, and I'm not saying that mine
was necessarily the best way nor the worst way. Bottom line is what Earl
Wertheimer said, however;
"When WalMart sends POs in XML, we'll be ready. Until then, fagetaboudit.."
Well, maybe not exactly then. :) We do like to be fast followers of
technology, but frankly I also like to sleep at night knowing where my data
is. I can do that on the "Big Iron" but not yet so easily on the XML
sandboxen.
-----Original Message-----
From: John Nadvornik [mailto:
Sent: Friday, February 04, 2005 3:13 PM
To: Hurd, Richard [SLCUS]
Cc: EDI-L Mailing List
Subject: Re: [EDI-L] <ADVOCACY> Why I Don't Like XML
Rich,
Not to argue with your point. I think you choose technology that best fits
you needs, but you could shrink your data stream buy using attributes and
being little more creative with the XML structure. This acheives the same
goal you are attempting with less data. Though, its still not as small as
the EDI structure, I think you can see where I'm going.
<BuyerParty>
<Address CoName="Wilie E. Coyote" StreetNo="123" StreetName="RoadRunner
Lane" City="Flat Rock" State="NV" Zip="12345"/>
</BuyerParty>
John
Hurd, Richard [SLCUS] wrote:
> -----Original Message-----
> From: William J. Kammerer [ mailto:
<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
<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/ <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
