Re: XML and OO COBOL

From: James J. Gavan (jjgavan_at_shaw.ca)
Date: 05/25/04 

Date: Tue, 25 May 2004 00:34:12 GMT

Warren Simmons wrote:

> Chuck Stevens wrote:
>
>> "James J. Gavan" <jjgavan@shaw.ca> wrote in message
>> news:Qqqsc.574985$oR5.345059@pd7tw3no...
>>
>>
>>> So far as J4 is concerned, perhaps there should be a more general
>>> re-think - and they shouldn't try to define a COBOL feature to the nth
>>> degree. Possibly, to qualify as complying to the official COBOL
>>> standard
>>> they should have a check-list :-
>>
>>
>>
>> As I understand it, J4 had little choice in this matter. ANSI
>> X3.23-1985
>> allowed the implementors to describe an implementation that had only the
>> most basic levels of the Nucleus, Sequential I-O and Inter-Program
>> Communication modules as "fully conforming" with that standard,
>> albeit with
>> the "minimum subset", ignoring altogether the other modules (Relative
>> and
>> Indexed I-O, SORT-MERGE, and Source Text Manipulation) as well as higher
>> levels like, for the Nucleus, SET 88-LEVEL TO TRUE, STRING, and nested
>> REDEFINES (Level 2), and from Sequential I-O, the LINAGE clause and
>> CLOSE
>> ... NO REWIND (also Level 2).
>>
>> The national bodies expressed the opinion through ISO/IEC
>> JTC1/SC22/WG4 (as
>> a direct mandate) that implementations would either conform to the
>> standard
>> or they would not be in conformance, period. There are certain
>> areas in
>> which WG4 relented -- the Screen Section and related language elements
>> being the most notable, allowing such language elements to be "processor
>> dependent" -- but they are few and very limited (see ISO/IEC
>> 1989:2002 pp.
>> 696-697 for the list of such elements).
>>
>>
>>> "To be COBOL 20?? compliant your compiler must have these features :-
>>>
>>> - a
>>> - b
>>> - c
>>> - XML
>>> - OO
>>> - OO Collection classes .
>>> - OLE support etc.......
>>
>>
>>
>> Bottom line is this: Aside from the aforementioned
>> Processor-Dependent list
>> on pages 696-697, a COBOL compiler that claims to conform to this
>> standard
>> must conform to this standard, not "except for OO", not "except for
>> VALIDATE", not "except for INITIALIZE WITH FILLER". Be in
>> conformance, or
>> be not in conformance. If an implementor decides that providing
>> table-format VALUE clauses or support for record-level locking syntax is
>> Just Too Hard, too bad; that compiler doesn't conform to the standard.
>>
>> If you don't like this approach of having "compliance" mean the same
>> thing
>> to everybody, then it's ISO/IEC you're going to have to convince through
>> your national bodies. Moreover, as WG4 has expressly *not* allowed
>> such a
>> major change in philosophy in the standard currently under
>> development, the
>> chances of reinstating the concept of "optionality" prior to the
>> publication
>> of the *next* standard -- currently planned for late 2008 -- is
>> pretty much
>> out of the car until development starts on the standard after that.
>>
>>
>>> Somebody wrote to me once he was optimistic that standard
>>> classes/collections could be ready by 2006, before COBOL 2008. Given
>>> current momentum, ( and we are already at mid-2002),
>>
>>
>>
>> There are two projects being handled as Technical Reports by J4:
>> "Collection class library" and "
>> "Native COBOL syntax for XML". Both are expected to apply against
>> the 2002
>> standard, to be published well before the next standard (much as the two
>> Amendments to the '85 standard were), and *also* to be incorporated
>> into the
>> 2008 standard when it is published. Work continues on both of these
>> Technical Reports.
>>
>> Incidentally, the "class library" approach (as distinct from the "native
>> syntax" approach) to XML was discussed at some length. The direction
>> given
>> by WG4 to J4 was that the current requirements for XML handling were
>> orthogonal to the requirements for classes, and that existing COBOL
>> users
>> were better served by having support for XML using syntax already
>> familiar
>> to them than by making extensive use of object-oriented design
>> features in
>> the program a prerequisite.
>>
>> This is similar to the issues involving dynamic-capacity tables,
>> which can
>> clearly (and easily) be handled within implementor-defined (as well as
>> user-defined) classes; the requirement here is that the changes to the
>> Procedure Division of an existing program with a fixed-capacity table to
>> turn that table into a dynamic-capacity table would be at most
>> minimal, and
>> preferably nonexistent, which a dynamic-capacity table (or, for that
>> matter,
>> an XML-handling) implementation requiring the use of classes would not
>> fulfill.
>>
>> -Chuck Stevens
>>
>>
> Chuck is telling it like it is. However, this has to do with defining
> the standard, and NOT the evolution of it. In my view, the c.l.c could
> do the same job the old COBOL committee did, and much better as there
> was no COBOL or HISTORY then.
>
> Warren Simmons, NewJersey

For the minute I couldn't tell whether you were agreeing with me or not
Warren :-)

Quite right - Chuck is spelling it out like it is, constrained by rules,
initially set by a bureaucratic structure - largely to cover their
asses. (Not the J4 people but ANSI and ISO). Now Pete Dashwood had a
bloody good laugh when I said a guy got pulled in with a speeding ticket
- "Exceeding the speed limit on a bicycle, on a public footpath". Well
the same wise city council here in Calgary has introduced a whole set of
irritating by-laws just recently, barbecues - party-time finishes at
midnight, no letting smoke drift into your neighbour's place, etc.,
etc., and the really best one "You CANNOT put doggy poop in your garden
compost". Now with a population getting up there close to one million
and ONLY 46 by-law inspectors for the city - you can imagine how
effectively that last one is going to be controlled ! (Visions of
surreptitious people creeping into your backyard/garden in the wee small
hours, with a set of weighing scales - weight is important evidence).

Let's try a hypothetical on you Chuck. Unisys God bless 'em. Your think
tank comes up with a super duper idea on an OO Data Base - whatever
that means, (they are talked about but I'm not aware of any). Management
buys into it, and as you pursue the idea it truly firms up and is going
to be a winner. Dah, Dah ! 'Unisys is proud to announce that as of
...ccyy/mm/dd. we have the Unisys OO Database with all the following
glowing features". You are going to sell it like hell - and you ain't
waiting for nobody, but nobody !

Hmmm.... interesting say the other J4 guys (and girl). "You crafty SOB
Chuck, you kept that tight-lipped". To them it makes real sense this
should be another module in COBOL. Committee pores over what you have,
does a bib and tuck here and there and hopefully come up with something
which is close enough to your original that it doesn't involve you in
major change. However, not likely I know (or hope !), you deliver a
horse and by consensus J4 turns it into a camel. Aren't you,
(well I'm assuming it wont be 'You' but guys further up the Unisys totem
pole) going to tell IBM et al to "Go take a hike ! We've got 20,000
installations using what we dreamed up".

Take that hypothetical - COBOL conforming or not - and your initial one
isn't 'cos it doesn't have J4 blessing, it might just make more sense
for each to produce their own OO Database - the competitiveness will
engender new techniques. Perhaps some 10 years down the road , the
participants in J4 could have a meeting on this topic - do some horse
trading - and then perhaps come up with the conforming model..
(Meanwhile - I await intrigued until there's some documentation - I'm
hoping my M/F "collections" don't get revamped as a zebra or camel !)

By 'horse trading", making concessions, conceding certain things remain
intact even though all participants don't buy into some of the smaller
features. Horse trading - not putting a blank *** of paper on the
table and starting from scratch, which so far has happend several times
with collections. If Bill Klein hadn't 'resurrected' Russell's proposal,
at this stage there wouldn't even be a piece of blank paper on the table !

Your off the hook Chuck - happend way before you got involved - for your
sins :-)

Jimmy, Calgary AB