Re: [xml-dev] Why XML?

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote1>
Why would anyone use something as arcane as XML when flat files have
worked perfectly well since .... whenever. Between 'trusted' parties,
anyway.
</Quote1>

A few reasons:

(1) You're working in Tech Support and just received a call regarding
Purchase Order #135796 - it appears that an incorrect Ship Date was
assigned to the PO. You suspect a bug in the system. So, you examine the
data:

PO13571357962003081020030811500.003 MAIN ST. ANYWHERE USA 55796 AT

Or, you examine the data:

	.......
<SenderNumber>1357</SenderNumber>
<PONumber>135796</PONumber>
<InitiatedDate>2003-08-10</InitiatedDate>
<ShipDate>2003-08-11</InitiatedDate>
<TotalAmount>500.00</TotalAmount>
<ShipAddress>3 MAIN ST. ANYWHERE USA 55796</ShipAddress>
<ShipCode>3 MAIN ST. ANYWHERE USA 55796</ShipCode>
	.......

Which is easier?

(2) You and your trading partner decide that an additional Shipping
Address field is required. You can add it to the flat-file
representation by updating programs, regression testing, etc., etc.

Or, you can add it to the XML representation by adding it to the XML
schema that represents your data exchange.

Which is easier?

<Quote2>
why invent nonsense like attributes? What can they do that nested
elements can't?
</Quote2>

Attributes make sense in many cases - particularly in cases where one
needs to ensure that certain information is "coupled together" so that
the chances of any processing taking the information out of order are
minimized. 

For example, consider approach (a):

<Payment currency="USD">300.00<Payment>
<Payment currency="EUR">500.00<Payment>

Versus approach (b):

<Payment>300.00</Payment>
<Currency>USD</Currency>
<Payment>500.00</Payment>
<Currency>EUR</Currency>

In approach (a), the chance of a processor (such as an XSLT stylesheet)
being written to associate a currency of "USD" with the second value of
500.00 would - all other things being equal - be pretty slim. However,
in approach (b), there is a greater chance that a processor could
inadvertently confuse the order and associate the currency of "USD" with
the value below it (500.00) rather than the value above it (300.00).

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton

Matthew.Bennett@facs.gov.au wrote:
> 
> Hi All,
> 
> I appreciate XML's strengths re: markup, but I don't think it has much of a
> role in data exchange. Why would anyone use something as arcane as XML when
> flat files have worked perfectly well since .... whenever. Between
> 'trusted' parties, anyway.
> 
> Two things make me wonder about the competence of those who designed XML.
> 1. If you wanted to keep it comprehensible, why invent nonsense like
> attributes? What can they do that nested elements can't? W3C has violated a
> first-order principle of language design; that there should only be one way
> of doing something, such that everyone ought to devise the 'same' program
> to solve the 'same' problem. COBOL obviously is the grossest offender in
> this regard, but XML's scarcely any better. And 2. If a start tag must have
> a matching end tag, what purpose is served by that ridiculous slash in an
> end-tag?
> 
> Cheers,
> Matt Bennett
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard