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

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:d4bcvf$qsi$1@si05.rsvl.unisys.com...
>
> "LX-i" <lxi0007@netscape.net> wrote in message
>  news:5a47b$42685456$45491db9$15115@KNOLO
GY.NET...
> 
>
> Have you looked at "Native COBOL Syntax for XML Support", a Preliminary
> Draft Technical Report written by Don Schricker and proposed as a
follow-on
> for the 2002 COBOL standard (as well as for later incorporation into the
'08
> standard)?
>

I have. At length. I see a number of problems with it.
As I don't really care, I haven't placed any official objections or
suggestions.

> The currently-distributed version of this document is J4/05-0049 on the J4
> website www.cobolportal.com/j4/
>
> The US comments on this proposal have not been distributed yet, but when
> they are they will be available in document J4/05-0088 on the same
website.
>

Don's paper is well written and well put together but it is solving a
problem that doesn't exist.

There is simply no advantage in making XML support an integrated part of
COBOL.

(I believe it is being driven by fashion rather than need).

Anyone wanting to process XML can do so easily using the third party
components available. (Most of them are free).

This is a moving and evolving standard. It SHOULD be separate from COBOL.
It has no more relevance than including postscript generation into native
COBOL (in fact, given the growing emphasis on COBOL for batch processing and
reporting, including Postscript could actually make more sense than XML.)
 
>
> I'd be interested in your thoughts on how what you're doing would be
> simplified (or made more complicated) if it was done using the syntax in
> Don's PDTR.  Maybe you could lobby the 2200/IX folks, as a customer, that
> this is something customers need, and get compiler support for this stuff
> built in (even on a pre-2002-standard COBOL, as an extension)?
>
... or not...

For a vendor to implement this is a serious effort. In my opinion, the
rewards simply aren't worth that effort when there are free tools available
to do the job easily. If I was a vendor prioritising what parts of the 2002
standard I MIGHT consider implementing, this would be bottom of my list.

But that's just me, and the vendors will res[pond to the market place as
they perceive it...

Pete.