Enterprise Service Bus

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: &n= bsp; (212) 840-2298

Email: sseitz@ansi.org =

_____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: &= nbsp; 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 &nbs= p;

"P" Members not supporting = registration

"P" Members abstaining &n= bsp;

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: &nb= sp; JTC 1/SC22

Circulation Date: 2005-02-28

Closing Date: &= nbsp; 2005-05-28

------------------------------------------------------------------= ----

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 &nbs= p;

1(US)

"P" Members not supporting = approval

"P" Members abstaining &n= bsp;

3(Denmark, France, Switzerland)

"P" Members not voting <= /o:p>

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

National Body = Comments

US<= /b>

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
[27]   Misc   ::= =3D   Commen= t | PI | = 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 (& ' > < ") 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=3D"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=3D"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=3D"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=3D"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<= /p>
Phone: (212) 642-4918

Fax: (212) 840-2298

Mismatch	XML=	COBOL
Elided levels or data = items	<book = ISBN=3D"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=3D"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=3D"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=3D"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...