XML Standard

Chuck,

Just read Pete's latest reply to you - but I wont comment other than to
say I *do* agree with him about XML. For you and any other J4 folks who
may just eavesdrop :-

I've no idea how long (R)DBMS has been in play, but from a series of
Pete's other messages quite some decades and it has firmed up to its own
independent SQL Standard. No ifs, buts or maybes there is the standard
SQL set, although some such as DB2 or Oracle have added features -
extensions. We haven't attempted to embrace SQL into COBOL - each vendor
as appropriate provides an SQL preprocessor, which to be effective
*must* comply with the SQL syntax. Works like a dream whether or not you
are using Procedural or OO.

XML - don't know how long it's been around, but again a very well
*defined*  format in the XML Standard. Now I know less about XML than
you confess to knowing about OO - so I could be doubly-dangerous :-). A
very cursory read, but I liked Liant/RM's approach to XML. The XML
Standard format contains no ambiguity. I do find it difficult to accept,
that we need an entirely new file format to use XML, for the future in
COBOL. Why not some generic file-handler. Not used very much I guess,
but to overcome other system files, M/F have a Byte Stream File routine
- read in chunks or read in the whole file.

At this point in time - it looks like XML is here to stay - very much in
parallel with SQL. But fixed into a specific COBOL file format for XML -
what happens down the road when the XML standard sees justification for
some new extensions - can only hypothetically speculate, but we could
find ourselves screwed with our COBOL XML file format; possibly unable
to handle the new XML features; how long will it take the current J4
mechanism to respond.

While XML may well and truly become part of the computing firmament, who
is to say somebody, 10, 20 years down the road doesn't come out with
something which is XML plus five gold stars.  Does COBOL, some years
after the new tool (XYZ)  has been introduced,  consider introducing a
file type to handle the new animal XYZ ?  (My reference to a Byte-Stream
would cover that). I betcha, that independently, Liant/RM will be able
to react much more quickly than J4.

Various file options aside, and at this stage no deep thought - I would
tend to consider two sequentials (1) A file containing the XML template
with markers and (2) the output - using the format from #1  and
inserting text or whatever between the markers.

Jimmy

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9N0I8wMuflB@jpberlin-l.willms.jpberlin.de...
>.    On  16.12.04
>  wrote  t.morrison@liant.com (Tom Morrison)
>     on  /COMP/LANG/COBOL
>     in  tmnwd.758$iC4.74@newssvr30.news.prodigy.com
>  about  Re: XML Standard
>
>
> TM> XML is a data model.  If one thinks only of the serialized
> TM> representation of that data model on a byte stream file, then one
> TM> risks confusing XML with (1) a form of file access method, or (2) a
> TM> form of database,
>
>   Well, it is a form of database, a hierarchical database. There are
> database systems which do use XML as the format for their external
> storage. See e.g. Papyrus Office (www.rom-logicware.com).
[snip]

Ah, confusion abounds.  Papyrus, at least in its English presentation,
claims to use a relational database, which by definition must use the
relational data model.  Perhaps within the overarching relational structure
there are data that, considered in isolation, use the XML data model.

I guess this illustrates my point.  COBOL has, through the efforts of
proprietary vendors rather than standardization, arrived at a point where it
can reasonably manipulate the relational data model, typically by using
embedded SQL to provide access to a relational database.  Attempts to impose
the COBOL 'native' file structures on the relational model without
consideration of the requirements and limits of the relational model have
been -- shall we say -- less than well received in the market.

I have not said that one cannot build a database using the XML data model.
I have not said that one cannot integrate or accomodate the XML data model
in COBOL.  I *do* claim, however, that to impose COBOL file structures and
concepts on XML, while ignoring the other bits that go with 'XML' will be as
futile as imposing the COBOL file structures on the relational data model
while ignoring SQL has proven to be.

Best regards,
Tom Morrison
Liant Software Corporation

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9N0Lx5DeflB@jpberlin-l.willms.jpberlin.de...
[snip]

>   BTW, as to SQL and XML, there appears to be a ISO/IEC-9075 Part 14:
> "XML-Related Specifications (SQL/XML)".

I will look at this, but perhaps XQuery might be a more appropriate standard
(to be adopted soon).  XQuery -- again designed to work with XML -- probably
will produce 'better results' when working with XML than SQL/XML due to the
fact that SQL assumes a relational data model, and XML can happily represent
data that are not in the relational model.  (Of course, it *can* represent
data that *are* in the relational model too.)

"Tom Morrison" <t.morrison@liant.com> wrote in message
news:tmnwd.758$iC4.74@newssvr30.news.prodigy.com...
> "James J. Gavan" <jjgavan@shaw.ca> wrote in message
> news:7P4wd.526973$%k.216152@pd7tw2no...
> [snip] 
you 
Why 
overcome 
>
> Jimmy,
>
> Judging from the results obtained so far, I think that Liant and J4 have
> very basic differences in philosophy when it comes to XML.
>
> XML is a data model.  If one thinks only of the serialized representation
of
> that data model on a byte stream file, then one risks confusing XML with
(1)
> a form of file access method, or (2) a form of database, or (3) whatever
> else might be confusing that day.  If one thinks of the Document Object
> Model of XML, one can confuse XML as being some form OO programming.
>
> The XML data model is a close relative of the standard COBOL data model.
> Just as COBOL presently has constructs to manipulate its data model, COBOL
> should, if it is to integrate XML concepts, be modified better to
manipulate
> the XML data model.  This may, or may not, include OO, but I would point
out
> that COBOL has been manipulating its closely related (to XML) data model
for
> decades without formal OO constructs.  Similarly, if one thinks back a
bit,
> COBOL has been manipulating its data model with little regard for any of
the
> existing persistent storage mechanisms available.
>
> The "XML standard" is also a family of standards that work together.  Two
> very important standards which relate to manipulating XML documents are
> XPATH and XSLT.  While XSLT contains some imperative programming elements,
> these standards mostly concern declarative programming based upon the data
> model.  The WG4 document (04-0203), "Native COBOL Syntax for XML Support,"
> has no reference to the these standards.  The entire concept seems to be
> based upon the typical serialized representation of an XML document,
> complete with START and READ to 'traverse' a document.  Does anyone think
in
> terms of having to 'traverse' an array in order to change the contents of
a
> specific occurrence in that array?  So COBOL has this extratravagent means
> of 'traversing' a document, while XPATH describes the way 'everyone else'
is
> referencing data in an XML document.  In fact, COBOL standardization seems
> to feel compelled to maintain a metaconcept of XML in the statement,
"Formal
> XML rules allow only one document per file, but COBOL allows multiple
> documents per file.   The file position indicator maintains the document
> number of the current document in the XML file."  What is a document
number?
> And...why this disregard for "Formal XML rules" by a STANDARDS COMMITTEE?
>
Very considered and apposite post, Tom.

I agree. Whether COBOL implements XML or not, it certainly should NOT do so
by seeing XML through COBOL eyes.

It would be far better to consider XML AS IT IS, and ensure compliance with
the XML standards and XML "philosophy" and tools available.

I still think third party components can provide all the XML access anyone
ever needs, and I use them without problem from COBOL whenever I need to
process XML.

Actually, it doesn't really bug me if J4 waste their time because I think
they are irrelevant anyway, but it is annoying that there are things they
COULD be doing that are more part of COBOL...


> Well, time to take a breath, I guess...

When it comes to J4, get used to it... <G>
>

Pete.

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cpvi5r$1gda$1@si05.rsvl.unisys.com...
>
> "Tom Morrison" <t.morrison@liant.com> wrote in message
> news:tmnwd.758$iC4.74@newssvr30.news.prodigy.com...
> 
>
> ISO/IEC rules that apply to the development of standards to be published
> under that banner apply here.  "Normative" rules in the COBOL standard may
> refer to other international standards, but those references are pretty
> much
> required to be formally-adopted standards under the ISO or ISO/IEC
> banners.
[snip]
> What are the ISO/IEC -- or other international body -- designations for
> the
> standards for XPATH and/or XSLT?   If there aren't any, are there plans to
> get these standards "blessed" as "de jure" standards, rather than merely
> "de
> facto", by ISO/IEC?

[snip]

Despite some years of ANSI experience, I still refuse to join the bafflegab
(http://home.t-online.de/home/toni.g...iom_wm/id58.htm) of
international standardization.  Sorry.

That having been said, W3C has a web page describing its extensive
relationships with other standards-making bodies, including ISO.
http://www.w3.org/2001/11/StdLiaison.
Since there is formal liaison with ISO on XML (as well as other web-related
standards), I presume that progress is being made.  But "de facto" rules the
day, and I think XML is well accepted without regard to the ISO position --
if ISO indeed has one.

So...

>
> I'm no expert on XML and XML handling.  If there's a fundamental problem
> with the approach described in this proposal, I for one would like to see
> it
> fixed, but the best way to do that is for the person who *best*
> understands
> the issues and concerns to communicate them *directly* to the author.
> That, as I see it, would be you,. not me.  [snip]

Chuck, I understand your desire for this to happen (that is, "you, not me").
Unfortunately, because of the basic philosophical change needed and the
inertia of the bureaucracy, changing the course of COBOL/XML integration
would require a very substantial investment of time -- time that my
company's customers expect me to spend on their issues.  Besides that, the
author has already reported, in J4/04-0204, that, "[XPATH and XQUERY] will
not be used at this time."  I respect and value the author's knowledge of
things COBOL, but it sure sounds like his determination has been made.  What
weight would my opinion (not having 'paid my dues', e.g.) have against the
author's well-deserved reputation?

There is a fundamental flaw to the COBOL XML proposal.  All one needs to ask
is, "Would I find this file-oriented mechanism an acceptable approach to the
relational data model?"  I think the question will answer itself -- in the
negative -- for most folks.  Or perhaps one could ask, "Would I find only
sequential access to indexed files acceptable?"  Again, same answer.  But,
from my reading of 04-0203 and -0204, these are the types of handicaps that
are being proposed for XML integration.

Best regards,
Tom Morrison
Liant Software Corporation

..    On  17.12.04
wrote  t.morrison@liant.com (Tom Morrison)
on  /COMP/LANG/COBOL
in  nMDwd.188$F67.15@newssvr12.news.prodigy.com
about  Re: XML Standard


TM>>> XML is a data model.  If one thinks only of the serialized
TM>>> representation of that data model on a byte stream file, then one
TM>>> risks confusing XML with (1) a form of file access method, or (2)
TM>>> a form of database,

LW>>   Well, it is a form of database, a hierarchical database.
LW>> There are database systems which do use XML as the format for
LW>> their external storage. See e.g. Papyrus Office (www.rom
LW>> -logicware.com).
TM> [snip]
TM>
TM> Ah, confusion abounds.  Papyrus, at least in its English
TM> presentation, claims to use a relational database, which by
TM> definition must use the relational data model.

That's why I have been very careful to write that Papyrus Offices
uses "XML as the format for ... external storage"; that such can be
perused also to store relational tables is something that maybe Chuck
Stevens can explain using DMS II as an example.

You can see the minimal database of the Papyrus relaese here:
http://www.willms-edv.de/download/COBOL/Adressen.PB

It is stored as text, so your browser should not try to interpret
the XML tags. The same file with file extension XML:
http://www.willms-edv.de/download/COBOL/Adressen.XML
It looks nicer, but doesn't show this XML header:
<?xml version="1.0" standalone="yes"?>

TM> I guess this illustrates my point.  COBOL has, through the efforts of
TM> proprietary vendors rather than standardization, arrived at a point
TM> where it can reasonably manipulate the relational data model,
TM> typically by using embedded SQL to provide access to a relational
TM> database.

There is an standard by USA's NISC (National Institute of Standards
and Technology), namely ANSI X3.168-1989 "Information Technology -
Database Language Embedded SQL" which is, I assume, the common basis
of all ESQL implementations, isn't it?

TM> Attempts to impose the COBOL 'native' file structures on
TM> the relational model without consideration of the requirements and
TM> limits of the relational model have been -- shall we say -- less than
TM> well received in the market.

You mean present the database as a collection of individual files,
having to OPEN and CLOSE each one of those, without using SELECT from
several tables together? That would be, I dare to say, foolish.

TM> I have not said that one cannot build a database using the XML data
TM> model.

But one can look at an XML file as if it were a hierarchical (not
network) database. That is one of the possible views of it.

TM> I have not said that one cannot integrate or accomodate the
TM> XML data model in COBOL.  I *do* claim, however, that to impose COBOL
TM> file structures and concepts on XML, while ignoring the other bits
TM> that go with 'XML' will be as futile as imposing the COBOL file
TM> structures on the relational data model while ignoring SQL has proven
TM> to be.

Sure, but for the view of an XML document as a hierarchical
database, I would look to the CODASYL COBOL DML as a model. I don't
know if the original CODASYL document is available anywhere; I take as
my reference the PRM (Programmers Refernce Manual) for COBOL DML as
published by Unisys for their line of OS/1100-COBOL compilers, @ACOB,
@UCOB, and OO-COBOL. The CODASYL documents are stored at some
university in the USA, and the location of that library can at least
be found thru the CODASYL entry of the Wikipedia.

BTW, as to SQL and XML, there appears to be a ISO/IEC-9075 Part 14:
"XML-Related Specifications (SQL/XML)".


Yours,
Lüko Willms                                     http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Es gibt eine wahre und eine förmliche Orthographie. -G.C.Lichtenberg

"Tom Morrison" <t.morrison@liant.com> wrote in message
news:tmnwd.758$iC4.74@newssvr30.news.prodigy.com...

> The "XML standard" is also a family of standards that work together.  Two
> very important standards which relate to manipulating XML documents are
> XPATH and XSLT.  While XSLT contains some imperative programming elements,
> these standards mostly concern declarative programming based upon the data
> model.  The WG4 document (04-0203), "Native COBOL Syntax for XML Support,"
> has no reference to the these standards.

ISO/IEC rules that apply to the development of standards to be published
under that banner apply here.  "Normative" rules in the COBOL standard may
refer to other international standards, but those references are pretty much
required to be formally-adopted standards under the ISO or ISO/IEC banners.
As I understand it, it is possible to have references to international
standards from other organizations (e.g. IEEE), but the authors of proposals
referencing them have to jump through some hoops.  (For example, If IEEE
doesn't do the "fast-track" ISO/IEC procedures to ensure that the rewrite of
IEEE 754 is treated as an ISO document, and my "Syntactic Support for IEEE
754r ..." proposal gets done in time, there will probably have to be some
"hoops" I'll have to go through late in the game to ensure that the very
structure of the design is allowed.)  See ISO/IEC Directives Part 3:  Rules
for the structure and drafting of International Standards, Third edition,
1997, ISBM 92-67-01070-0.

What are the ISO/IEC -- or other international body -- designations for the
standards for XPATH and/or XSLT?   If there aren't any, are there plans to
get these standards "blessed" as "de jure" standards, rather than merely "de
facto", by ISO/IEC?

Note that such well-established standards as Unicode aren't included in
normative references in the COBOL standard; while the likes of ISO/IEC
10646-1 and even the draft ISO/IEC DTR 14652 are referenceable, and the
COBOL standard can (and does, in Annex D) specify the mappings between DTR
14652 and what amounts to Unicode, Unicode itself is only mentioned in the
bibliography on page 836 as a "useful reference".   This was a *huge*
international political issue that J4 and WG4 had to deal with, in which two
opposing factions on the subject of Unicode each threatened to derail the
entire standard if they didn't get their way.  It was the Japanese
delegation to WG4 that worked out the compromise on this.

> The entire concept seems to be
> based upon the typical serialized representation of an XML document,
> complete with START and READ to 'traverse' a document.  Does anyone think
in
> terms of having to 'traverse' an array in order to change the contents of
a
> specific occurrence in that array?  So COBOL has this extratravagent means
> of 'traversing' a document, while XPATH describes the way 'everyone else'
is
> referencing data in an XML document.  In fact, COBOL standardization seems
> to feel compelled to maintain a metaconcept of XML in the statement,
"Formal
> XML rules allow only one document per file, but COBOL allows multiple
> documents per file.   The file position indicator maintains the document
> number of the current document in the XML file."  What is a document
number?
> And...why this disregard for "Formal XML rules" by a STANDARDS COMMITTEE?

I'm no expert on XML and XML handling.  If there's a fundamental problem
with the approach described in this proposal, I for one would like to see it
fixed, but the best way to do that is for the person who *best* understands
the issues and concerns to communicate them *directly* to the author.
That, as I see it, would be you,. not me.  And if these concerns are
actually addressed in the proposal in ways that I don't happen to
understand, the person best equipped to assuage those concerns is the author
of the paper, again, not me!   That seems to me to argue for the idea that
some sort of direct communications between you and the author, in both
directions, could lead to some significant improvements to COBOL!  The
author's e-mail address and telephone number can be found on the J4 mailing
list accessible from the J4 website.

-Chuck Stevens

"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:7P4wd.526973$%k.216152@pd7tw2no...
> XML - don't know how long it's been around, but again a very well
> *defined*  format in the XML Standard. Now I know less about XML than
> you confess to knowing about OO - so I could be doubly-dangerous :-). A
> very cursory read, but I liked Liant/RM's approach to XML. The XML
> Standard format contains no ambiguity. I do find it difficult to accept,
> that we need an entirely new file format to use XML, for the future in
> COBOL. Why not some generic file-handler. Not used very much I guess,
> but to overcome other system files, M/F have a Byte Stream File routine
> - read in chunks or read in the whole file.

The basic idea of the Native XML proposal is to allow creation and retrieval
of a XML document, navigation within and update of that document, and
location of elements within it.  The file format itself is up to the
implementor, but as far as I'm concerned there's nothing whatever to
preclude it being as generic as you suggest.   What the XML
READ/REWRITE/WRITE  actually do  is deal with an individual *element* within
the document -- other verbs have already "expanded" the document from its
raw form in the file buffer into a more navigable memory structure of the
implementor's design.

> At this point in time - it looks like XML is here to stay - very much in
> parallel with SQL. But fixed into a specific COBOL file format for XML -

I don't think that's the case.

> what happens down the road when the XML standard sees justification for
> some new extensions - can only hypothetically speculate, but we could
> find ourselves screwed with our COBOL XML file format; possibly unable
> to handle the new XML features; how long will it take the current J4
> mechanism to respond.

I remember this being discussed, and I truly don't believe XML extensions to
be a problem.  Any extensions needed should be in the basic key-based format
already established for XML.  It's the format, not compliance with the
standard of the information in the format, that the COBOL mechanisms care
about.

> While XML may well and truly become part of the computing firmament, who
> is to say somebody, 10, 20 years down the road doesn't come out with
> something which is XML plus five gold stars.  Does COBOL, some years
> after the new tool (XYZ)  has been introduced,  consider introducing a
> file type to handle the new animal XYZ ?  (My reference to a Byte-Stream
> would cover that). I betcha, that independently, Liant/RM will be able
> to react much more quickly than J4.

Again, the basic XML *structure* is simple and powerful, and it is not
expected that that *format* will need to change unless it becomes something
*radically* different from what it is now (and I would argue that in that
event it's no longer XML).   Kind of like the question "What would happen to
your existing RPG compiler if somebody invented a free-format version of the
language in which any part of the specification could be anywhere in the
source line?"  I would argue that "The fundamental syntax of RPG is one in
which specifications are location-specific in the source line.   A language
in which column locations are not only different is *fundamentally* not
RPG."   Such I believe would be true of the COBOL XML specification.

> Various file options aside, and at this stage no deep thought - I would
> tend to consider two sequentials (1) A file containing the XML template
> with markers and (2) the output - using the format from #1  and
> inserting text or whatever between the markers.

I think these are covered by Don's proposal.

Note that he's revising it after the discussions at the J4 meeting last
w; the new document number will be 04-0234 when it is posted.

-Chuck Stevens

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9N0Lx5DeflB@jpberlin-l.willms.jpberlin.de...
[snip]

>   BTW, as to SQL and XML, there appears to be a ISO/IEC-9075 Part 14:
> "XML-Related Specifications (SQL/XML)".

I will look at this, but perhaps XQuery might be a more appropriate standard
(to be adopted soon).  XQuery -- again designed to work with XML -- probably
will produce 'better results' when working with XML than SQL/XML due to the
fact that SQL assumes a relational data model, and XML can happily represent
data that are not in the relational model.  (Of course, it *can* represent
data that *are* in the relational model too.)

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cpvi5r$1gda$1@si05.rsvl.unisys.com...
>
> "Tom Morrison" <t.morrison@liant.com> wrote in message
> news:tmnwd.758$iC4.74@newssvr30.news.prodigy.com...
> 
>
> ISO/IEC rules that apply to the development of standards to be published
> under that banner apply here.  "Normative" rules in the COBOL standard may
> refer to other international standards, but those references are pretty
> much
> required to be formally-adopted standards under the ISO or ISO/IEC
> banners.
[snip]
> What are the ISO/IEC -- or other international body -- designations for
> the
> standards for XPATH and/or XSLT?   If there aren't any, are there plans to
> get these standards "blessed" as "de jure" standards, rather than merely
> "de
> facto", by ISO/IEC?

[snip]

Despite some years of ANSI experience, I still refuse to join the bafflegab
(http://home.t-online.de/home/toni.g...iom_wm/id58.htm) of
international standardization.  Sorry.

That having been said, W3C has a web page describing its extensive
relationships with other standards-making bodies, including ISO.
http://www.w3.org/2001/11/StdLiaison.
Since there is formal liaison with ISO on XML (as well as other web-related
standards), I presume that progress is being made.  But "de facto" rules the
day, and I think XML is well accepted without regard to the ISO position --
if ISO indeed has one.

So...

>
> I'm no expert on XML and XML handling.  If there's a fundamental problem
> with the approach described in this proposal, I for one would like to see
> it
> fixed, but the best way to do that is for the person who *best*
> understands
> the issues and concerns to communicate them *directly* to the author.
> That, as I see it, would be you,. not me.  [snip]

Chuck, I understand your desire for this to happen (that is, "you, not me").
Unfortunately, because of the basic philosophical change needed and the
inertia of the bureaucracy, changing the course of COBOL/XML integration
would require a very substantial investment of time -- time that my
company's customers expect me to spend on their issues.  Besides that, the
author has already reported, in J4/04-0204, that, "[XPATH and XQUERY] will
not be used at this time."  I respect and value the author's knowledge of
things COBOL, but it sure sounds like his determination has been made.  What
weight would my opinion (not having 'paid my dues', e.g.) have against the
author's well-deserved reputation?

There is a fundamental flaw to the COBOL XML proposal.  All one needs to ask
is, "Would I find this file-oriented mechanism an acceptable approach to the
relational data model?"  I think the question will answer itself -- in the
negative -- for most folks.  Or perhaps one could ask, "Would I find only
sequential access to indexed files acceptable?"  Again, same answer.  But,
from my reading of 04-0203 and -0204, these are the types of handicaps that
are being proposed for XML integration.

Best regards,
Tom Morrison
Liant Software Corporation