Subject: N 3809-Summary of Voting on SC 22 N 3872, Registration and Approv al Letter Ballot for ISO/IEC PDTR 24716, Information technology-Programmi ng languages, their environment and system software interfaces-Native COB OL Syntax for XML Support

From: Sally Seitz <[email-masked]>
Date: Tue, 7 Jun 2005 16:40:22 -0400

ISO/IEC JTC 1/SC22

Programming languages, their environments and system software interfaces

Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22 N3908

TITLE:

Summary of Voting on SC 22 N 3872, Registration and Approval Letter Ballot
for ISO/IEC PDTR 24716, Information technology-Programming languages, their
environment and system software interfaces-Native COBOL Syntax for XML
Support

DATE ASSIGNED: 

2005-06-07

SOURCE: 

SC 22 Secretariat 

BACKWARD POINTER: 

N/A 

DOCUMENT TYPE: 

Summary of Voting 

PROJECT NUMBER: 

STATUS: 

The results of this ballot are forwarded to SC 22/WG 4 for review,
production of a disposition of comments report, and preparation of the DTR
text

ACTION IDENTIFIER: 

ACT 

DUE DATE: 

N/A 

DISTRIBUTION: 

Text 

CROSS REFERENCE: 

SC 22 N3872

DISTRIBUTION FORM: 

Def 

Sally Seitz

ANSI

25 West 43rd Street

New York, NY  10036

Telephone:  (212) 642-4918 

Fax:             (212) 840-2298 

Email:  [email-masked] 

_____end of cover page, beginning of PDTR registration summary______________

SUMMARY OF VOTING ON

Letter Ballot Reference No:  SC22 N3872

Circulated by:                JTC 1/SC22

Circulation Date:            2005-02-28

Closing Date:                 2005-05-28

SUBJECT: Summary of Voting on SC 22 N 3872, Registration and Approval Letter
Ballot for ISO/IEC PDTR 24716, Information technology-Programming languages,
their environment and system software interfaces-Native COBOL Syntax for XML
Support

The following responses have been received on the subject of registration: 

"P" Members supporting registration without comments  

12 (China, Czech Republic, Finland, Germany, Italy, Japan, Republic of
Korea, Netherlands, Romania, Russian Federation, United States, United
Kingdom)

P" Members supporting registration with comments             

"P" Members not supporting registration

0

"P" Members abstaining                   

3(Denmark, France, Switzerland

"P" Members not voting                   

6 (Belgium, Canada, Egypt, DPR of Korea, Slovenia, Ukraine,)

__end of registration summary, beginning of approval summary_____

SUMMARY OF VOTING ON

Letter Ballot Reference No:  SC22 N3872

Circulated by:                JTC 1/SC22

Circulation Date:            2005-02-28

Closing Date:                 2005-05-28

SUBJECT: Summary of Voting on SC 22 N 3872, Registration and Approval Letter
Ballot for ISO/IEC PDTR 24716, Information technology-Programming languages,
their environment and system software interfaces-Native COBOL Syntax for XML
Support

----------------------------------------------------------------------

The following responses have been received on the subject of approval: 

"P" Members supporting approval without comments 

11 (China, Czech Republic, Finland, Germany, Italy, Japan, Republic of
Korea, Netherlands, Romania, Russian Federation, United Kingdom) 

P" Members supporting approval with comments             

1(US-)

"P" Members not supporting approval

0 

"P" Members abstaining                   

3(Denmark, France, Switzerland)

"P" Members not voting                   

6 (Belgium, Canada, Egypt, DPR of Korea, Slovenia, Ukraine,)

National Body Comments

US

General comments:

1.      U.S. COBOL experts have reviewed PDTR 24716 and consider that the
general approach is sound and the features will have value for users.
Several areas of the specification (noted in our detailed comments) require
additional specification so that applications can behave in a consistent
manner across implementations.   

2.      Clarify whether XML 1.0 is supported.  For guidance see
http://www.w3.org/XML/Core/#Publications, which states that "XML Parsers are
expected to understand both XML 1.0 and XML 1.1".  Only XML 1.1 is
referenced in 2 (Normative references).  XML 1.0 is referenced in definition
4.3 (XML document).  XML 1.0 is used in the example in C.4.2.  The
specification states that XML 1.1 documents are written, but fails to
clearly specify the version or versions accepted for input.   Our
recommendation is that both XML 1.0 and 1.1 be accepted on input and that
XML 1.1 be created on output.

3.      There is no discussion of how the miscellaneous information
NT_Misc[27]   Misc   ::=   Comment
<http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-Comment>  | PI
<http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-PI>  | S
<http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-S> 
which can precede or follow the root element is treated on input, nor
whether it is or can be generated on output.  

4.      The concepts section should explicitly mention the portions of XML
that are not supported by the TR.

5.      There is no description of references: 

*        Whether character references are resolved on input, or generated on
output; (These need to be resolved on input.  On output they need to be
generated.)  

*        Whether predefined entities (&amp; &apos; &gt; &lt; &quot;) are
resolved or generated; (These need to be resolved on input and generated on
output.)

*        Whether general entity references are resolved on input if there is
a DTD or generated on output;  (These need to be resolved on input, but do
not need to be generated on output.)

*        The treatment of PE references.  (These need to be resolved on
input, but do not need to be generated on output.)

6.      There is no description of the data types (USAGE, PICTURE) that can
be specified subordinate to the 01 level item under the XML FD. There are
some implicit restrictions in the use of COMPUTE and UNSTRING to describe
the transfer of data to subordinate items without the IDENTIFIED clause.
Furthermore, NUMVAL-F, rather than NUMVAL-C, should be used when floating
point data items are involved.  Look at what descriptions make sense and map
all combinations of COBOL and XML that make sense.  Perhaps use MOVE versus
SET to distinguish which types make sense.

7.      It is not stated whether the 01 level items under the XML FD must be
structurally compatible with the XML documents on input. For example, are
the following configurations allowed, and if so, what processing occurs for
various START and READ ... ELEMENT statements:

Mismatch

XML

COBOL

Elided levels or data items

<book ISBN="0-596-00675-6">
  <superfluousTag>
    <title>Enterprise Service Bus</title>
    <author>David A Chappell</author>
    <pages>352</pages>
  </superfluousTag>
</book>

1 book identified.
  2 ISBN identified attribute
      pic 9x999x99999x9. 
  2 title identified pic a(80).
  2 pages identified comp pic 999.

Missing identification

<book ISBN="0-596-00675-6">
  <superfluousTag>
    <title>Enterprise Service Bus</title>
    <author>David A Chappell</author>
    <pages>352</pages>
  </superfluousTag>
</book>

1 book identified.
  2 superfluousTag.
    3 ISBN identified attribute
        pic 9x999x99999x9. 
    3 title identified pic a(80).
    3 author identified pic x(40).
    3 pages identified comp pic 999.

Reordering

<book ISBN="0-596-00675-6">
  <title>Enterprise Service Bus</title>
  <author>David A Chappell</author>
  <pages>352</pages>
</book>

1 book identified. 
  2 author identified pic x(40).
  2 ISBN identified attribute
      pic 9x999x99999x9.
  2 pages identified comp pic 999.
  2 title identified pic a(80).

Extra levels or data items

<book ISBN="0-596-00675-6">
  <title>Enterprise Service Bus</title>
  <author>David A Chappell</author>
  <pages>352</pages>
</book>

1 book identified.
  2 ISBN identified attribute
      pic 9x999x99999x9.
  2 publisher identified pic x(40).
  2 usefulStuff. 
   3 title identified pic a(80).
   3 author identified pic x(40).
  2 pages identified comp pic 999.

And so on...

 

8.      Generally, the semantics of data transfer are missing. In some cases
no equivalent statement is described, nor is there a data description of the
items in the internal representation. And, as noted above, there are no
stated restrictions on the data description entries of data items under the
XML FD. Regardless of which data types are eventually permitted, the
semantics of the data transfer (conversion to and from XML character format)
must be described for each type.

9.      The lack of specified locale support precludes the processing of
files with data that uses multiple currency strings.  For example, READ
statement general rule 34 shows a COMPUTE statement that uses FUNCTION
NUMVAL-C without a LOCALE argument. Thus, XML data that is processed in a
given compilation unit can have only one currency string.  This seems an
unreasonable limitation.  There might be other limitations imposed by the
lack of locale support. The specification should be enhanced to provide for
locale-based processing where applicable.

10. Provide a note to explain why support for I/O open mode is provided only
when the file contains a single document.  Add concepts to describe the
scheme for input/output with the SAME AREA clause.  This is not an obvious
solution to the lack of I-O mode.

11.  Add an index.  

Detailed comments:

1.      Page 1:  2, Normative references:

*        Do JTC1 procedures now permit normative references to publicly
available specifications (PAS), such as W3C recommendations, without the use
of the PAS process?  If not, move the W3C references to the bibliography or
follow the PAS process for these references.  If this is not an issue for
the TR, it might be an issue when XML is incorporated in the next edition of
the standard. 

2.      Page 1:  2, Normative references (or bibliography, wherever these
end up):  

*	update the reference for "Namespaces"  to XML 1.1 dated 4 Feb 2004.

*	update the references for XML Schema Part 1 and Part2 to 18 Oct.
2004.
*	add a reference to XML 1.0.

3.      Page 1:  4, Terms and definitions

*	4.2, document type definition:   A DTD is written in a unique
language, specifically not XML.  Suggested rewording:  "A specification of
the markup language that defines the elements, attributes, comments, notes,
and entities that a document can contain and specifies the relationships
among them within the document."
*	4.3, XML document change "1.0" to "1.1"; put a comma before the
date.  Or, if both 1.0 and 1.1 are accepted as input, clarify the rule.
*	Add a definition of "XML schema"

4.      Page 3:  6.2, Changes to 9, I-O, objects, and user-defined
functions, [c] 9.1.7, Organization

*	First paragraph, first sentence:  Change "document" to "document or
a sequence of XML documents."
*	Third paragraph, second sentence:  This states that an XML-document
format OPEN "move data into associated data items described in the file
section." Is this correct? If so, how much of the structure is populated by
OPEN versus the explicit transfers done by READ statements?
*	Fourth paragraph:  Describe what happens to comments and processing
instructions occurring outside the root element on input and output.
*	Fifth paragraph:  State whether version 1.0 documents are accepted
as input.

5.      Page 4:  6.2, Changes to 9, I-O, objects, and user-defined
functions, [f] Element position indicator

*	If the WRITE statement does not update the element position
indicator, then a sequence of WRITE statements will insert elements (or
attributes) into the internal representation in reverse order. Is this what
was intended?
*	XML attributes do not have a well-defined order ("Note that the
order of attribute specifications in a start-tag or empty-element tag is not
significant."). Clarify that the element position indicator treats all
attributes as occurring at the same position.  That is, the attributes can
be read in any order.

6.      Pages 5-6:  6.3, Environment division [a], file control entry format
5 [XML]:  The specification of data-name-9 or data-name-10 in the ASSIGN
clause associates a file with a storage area.  The document contains no
rules for handling this type of XML file in an extend, I-O, or output open
mode.  There should be either a prohibition of these modes or an exception
condition when a CLOSE DOCUMENT statement would result in data overflowing
the assigned area.  If extend, I-O, or output open modes are permitted, the
following are among issues that need to be clarified:

*	In item d.3, it should be made clear that the term "XML data" refers
to one or more XML documents.
*	What happens if the storage area cannot hold the entire document
when a CLOSE DOCUMENT statement is executed?  Perhaps an I-O status should
be added for this situation.

7.      Page 9:  6.4, Data division, [a] Format 4(XML):

*	If the XML file is defined as EXTERNAL, clarify that the internal
representation of the XML document is shared with others.

8.      Page 10:  6.4, Data division [d], CODE-SET clause, new general rule
8:

*	Clarify that leading or trailing spaces are ignored in data-name-1.

9.      Page 10:  6.4, Data division [d], CODE-SET clause, new general rule
10:

*	Data-name-1 need not contain an alphabet name, so change "specified
alphabet" to "specified encoding."  
*	Change the default to be implementor-defined, which allows, among
other choices, the implementor to determine the code-set used in the XML
document.   

10.  Page 12:  6.4, Data division [f], IDENTIFIED clause, syntax rule 3 ff:

*	In syntax rule 4, clarify whether the data-name is used as written
(that is, in mixed case if written in mixed case) or, since data names are
case-insensitive, folded to lower-case or upper-case.  Recommendation:  On
output, use the case written in the declaration.  On input, match any case.

11.  Page 12:  6.4, Data division [f], IDENTIFIED clause, general rules 4, 5
and 6:

*	Describe the processing of (leading or) trailing spaces in
data-name-1 and data-name-2

12.  Page 13:  6.4, Data division [g], NAMESPACE clause, general rules:

*	How is this used on output? Where is the namespace attribute
generated? Is a default or explicit namespace used for elements? For
attributes, an explicit namespace must be used. For explicit namespaces,
what prefixes are used? How are leading or trailing spaces in the namespace
value in data-name-1 and data-name-2 handled?

13.  Page 14:  6.4, Data division [j], TYPE clause, new syntax rule:

*	Add a note explaining the restriction on the STRONG clause.  If
there is no reason for this restriction, remove it.

14.  Page 14:  6.5, Procedure division [c]:

*	exception EC-XML-CODESET:

o       Change "encoding attribute" to "encoding declaration." The XML
declaration does not have attributes. Attributes occur only within start or
empty tags. 

*	exception EC-XML-NAMESPACE:  

o       The namespace attribute is specified in a start tag or an empty tag,
not in the XML declaration. Also a document might contain many namespace
attributes which might apply to different parts of the document and to the
01 structure under the XML FD. Perhaps restate as, "A namespace attribute
value in the XML document did not match the namespace in the corresponding
NAMESPACE clause."

*	exception EC-XML-UPDATES:

o       The meaning of "... about to be discarded" is not clear.  I know the
exception descriptions should be kept short, but this one is not helpful
without more information.  Suggested rewording:  "A close statement was
interrupted because updates had not been written.  A RESUME statement would
cause loss of updates." 

15. Page 15:  6.5, Procedure division, [d], CLOSE statement, item 6, general
rule 12:

*	Allow CLOSE DOCUMENT for an input file.  An imbalance of OPEN and
CLOSE statements might cause confusion.  Suggested semantics:  The internal
representation becomes unavailable to the runtime element.

16.  Page 15:  6.5, Procedure division, [d], CLOSE statement, item 6,
general rule 14:

*        Missing specifications - are the following generated or not:

o       The standalone document declaration in the XML declaration

o       The XML version

o       The encoding

o       A document type (DOCTYPE) declaration if the TYPE clause has the DTD
phrase with the EXTERNAL phrase

o       Comments and or processing instructions preceding or following the
root element?

17.  Page 16:  6.5, Procedure division, [d], CLOSE statement, item 6,
general rule 17:

*	How would the internal representation change if the CLOSE statement
is successful?

18.  Page 17:  6.5, Procedure division, [h], DELETE statement, item 2,
general rules 13 and 14:

*	Reword rules 13 and 14 to show that the DELETE statement removes
elements and attributes.  This distinction needs to be made globally.

19.  Page 19:  6.5, Procedure division, [j], OPEN statement, item 5, new
general rule 26:

*	Change "schema or DTD name specified in the XML declaration in the
document" to "schema or DTD name specified in the XML document." The schema
or DTD is never specified in the XML declaration. The schema is indicated
via the location "hints" (attributes xsi:schemaLocation and
xsi:noNamespaceSchemaLocation) in the root element. The DTD is either
included in or referenced by the DOCTYPE declaration.

20.  Page 19:  6.5, Procedure division, [j], OPEN statement, item 5, new
general rule 29:

*	Notice that this means that the entire XML document, no matter how
large, must be read at open. This should probably be emphasized, since no
other file organization has this "open penalty."

21.  Page 21:  6.5, Procedure division, [k], READ statement:

*	Change "XML element" to "XML element or attribute."

22.  Page 22:  6.5, Procedure division, [n], READ statement, new general
rule 30:

*	The description, "It moves as much data as possible into the
associated data item" is inadequate.
*	The complete semantics for data descriptions permitted under the XML
FD, and for all entities that can occur either as XML element content or as
attribute values must be described. This includes such details as the
resolutions of references in the XML character data, as well as the
supported forms of input for data conversion, padding, truncation,
justification, etc.
*	It's not that the XML support is unimplementable. But there are so
many unspecified aspects that there would be essentially no portability
between different implementations.
*	Conversion of XML data encoded with UTF-16 to the native character
set needs to be taken into consideration.

23.  Page 22:  6.5, Procedure division, [n], READ statement, new general
rules 30 through 34:

*	Change the wording to show that the READ statement operates on
elements and attributes.
*	XML attribute order is undefined. Modify the description of the READ
statement (and the element position indicator) to clarify that attributes
within one start or empty tag can be accessed without respect to their
physical order in the document.

24.  Page 23:  6.5, Procedure division, [n], READ statement, new general
rule 34:

*	Is the last paragraph really true? If so, it's certainly in conflict
with the example!  An elementary item with an IDENTIFIED clause certainly
does not have "associated subordinate items." Does this really mean that
"the data associated with the tag ... is ignored?"
*	Specifying a MOVE statement without knowing the data types that are
supported as receiving fields, leaves the semantics undecided. Describing
data transfer in terms of an UNSTRING statement would appear to limit that
case to USAGE DISPLAY and NATIONAL data items only.  This is insufficient
for COBOL applications.
*	Add specification of how the data type is determined for the XML
sending fields and add the associated rules for data transfer for all
possible types, etc.  For example, for floating point data items, NUMVAL-C
would be inappropriate, and one would presumably use the NUMVAL-F function.

25.  Page 24:  6.5, Procedure division, [r], REWRITE statement, new general
rule 25:

*	The third paragraph describes the semantics of the data transfer in
terms of a STRING statement. This would appear to prohibit as sending fields
all data items except those with USAGE DISPLAY or NATIONAL. Is that really
the intention?
*	In addition, this is asymmetric with the READ statement, whose
description distinguishes between single and multiple associated data items.
For example, there would be loss of information if data were transferred to
a single associated numeric data item and then transferred via REWRITE from
the same numeric data item.

26.  Page 26:  6.5, Procedure division, [u], START statement, new general
rules 22 through 27:

*	Either reword these rules to include attributes (preferably) or add
a general rule stating that a START statement cannot be used to position to
an attribute. The latter resolution would make acquiring an attribute value
awkward, perhaps mandating an unnecessary READ to bypass a tag name.

27.  Page 28:  6.5, Procedure division, [y], WRITE statement, new general
rule 38:

*	The second paragraph describes the semantics of the data transfer in
terms of a STRING statement. This would appear to prohibit as sending fields
all data items except those with USAGE DISPLAY or NATIONAL. Is that really
the intention?

Editorial comments:

1.      Page iv:  Foreword:

*	second paragraph:  change "Part 3" to "Part 2".
*	penultimate paragraph:  change "handle XML documents" to "read,
write, and update XML documents" (handle is vague and colloquial in this
context).
*	penultimate paragraph:  delete "and schemas".

2.      Page 7:  6.3, Environment division, [h], b, 5): 

*	change the first "may be" to "are"
*	change the second "may be" to "can be"
*	change "as long as" to either "when" or "only when"  (less
colloquial)

3.      Page 7:  6.3, Environment division, [j]:  change "12.3.4.9.3"  to
"12.3.4.9.2"

4.      Page 14:  6.5, Procedure division [d] CLOSE statement, item 1:

*	change "The CLOSE statement" to "The XML-document format CLOSE
statement"

5.      Page 15:  6.5, Procedure division, [d], CLOSE statement, item 6,
general rule 13):

*	In the first sentence, change "fle-name-1" to "file-name-1."

6.      Page 15:  6.5, Procedure division, [d], CLOSE statement, item 6,
general rule 14):

*	delete the extra period at the end of the lead-in paragraph
*	in NOTE 1, change "may" to "can" and change "impacted" to
"affected"; 
*	NOTE 2, the wording is awkward; suggested rewording:  "... file
description entry are discarded if they were not written with ... REWRITE
statements."

7.      Page 33:  C.2, 4th paragraph, penultimate sentence:  change "Since"
to "Because" (since is temporal) and change "may" to "might" (both
instances)

8.      Page 38 and 39:  Example program getquote:  the data description of
filestat should be pic xx, not pic s9(9).

Sally Seitz

Program Manager

ANSI

25 West 43rd Street

New York, NY 10036

Phone: (212) 642-4918

Fax: (212) 840-2298