Re: COBOL and XML (was Re: OT - "lie" vs "error")

> *their* users had a problem that *did* exist, and that this was the
right way to solve it.

I tend to agree with Pete. The users certainly feel that they do have a
problem, and that is exchanging information between systems, or parts
of systems.  Currently it is done (as I have been doing for a couple of
decades) using CSV, or EDIFACT or EANCON, or Excel spreadsheets.
Something better certainly is required.

The problem that I see with XML is that it is no better at transferring
data than any of the methods above, but it _looks_ better.  A well
formed EDIFACT may have in part:

LIN+1+1'PIA+1+4578A:IN'QTY+21:45'...

Wheras the equivalent XML may be:

<line number="1">
<productcode origin="internal">4578A</productcode>
<quantityordered>45</quantityordered>
..
</line>

Whan a _manager_ looks at that he can actually read it and understand
what it is saying and so thainks that programs will be able to as well.
But XML is just a formatting tool, there is no inherent difference
between passing the data values in XML from how they may be in EDIFACT
or even a spreadsheet - except a manager may think they can read it.

The problem with XML is exactly the same with any interchange
mechanism: syntax and semantics. Just because it looks english like,
does not mean that the data can be read as english, nor that the
program can 'work out' that if it has 'product' or 'product_code' or
'prod' or 'article' or 'stockcode' or 'sku' that these are all
equivalents, or perhaps not quite.

Once an application has been defined for XML the tagnames, attributes
and values are established and then the XML can be fully understood.
This can then generate the cobol names for the data items (probably).
But in fixing the XML application and setting the tag names they could
be set to anything as long as they are consistent, it wouldn't matter
to the programs.

In other words it is not a magic bullet as many claim for it, it is
just a layer of syrup.  It is not a standard way of interchanging data
(though a particular application may be) but is just a way of
formatting the same data that could be formatted in many other ways
equally as effectively.

Now I grant that EDIFACT had been optimised for reduced bandwidth and
is quite terse, I remember sending them on 2780 protocol at 600baud
half duplex, and this is not so much an issue, but burying the data in
mounds of text does not make that data any more explicit. The tags are
just arbitrary names, they are not dictionary definitions that are
universally applicable.