Issues for Mailing list of the Abstract Syntax Tree Metamodel Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 12591: Describe behavior of BinaryExpression
Issue 12592: Describe the behavior of ConditionalExpression
Issue 12593: Describe the behavior of Modulus
Issue 12594: Describe the behavior of BitRightShift.
Issue 12595: Add description of square brackets to ABNF Notation
Issue 12596: Remove square brackets surrounding Scope.childScope
Issue 12597: Change multiplicity of FunctionDefinition.returnType
Issue 12598: Consider changing Comment.text to Comment.body for consistency with MOF
Issue 12599: relative ordering of ShortInteger, Integer and LongInteger
Issue 12600: relative ordering of Character and WideCharacter
Issue 12601: relative ordering of Float, Double and LongDouble
Issue 12602: Change multiplicity of EnumType.enumLiterals from 1..* (i.e., '+') to 0..*
Issue 12603: Consider changing the name of SourceLocation
Issue 12604: Consider changing SourceFile.pathName to SourceFile.path
Issue 12605: Consider removing the attribute language from CompilationUnit
Issue 12606: Change ActualParameterE to ActualParameter
Issue 12607: Document version (1.3.2) does not match last entry in Revision History (1.6
Issue 12608: Change IntegerlLiteral to IntegerLiteral
Issue 12609: Change the word before to after in the description of ForCheckAfterStatemen
Issue 12610: Change the word OpenScope to opensScope in footnote 5
Issue 12611: Footnote 11 is not clear
Issue 12612: Change OpenScope to opensScope in footnote 12
Issue 12613: Inconsistent naming of FunctionMemberAttribute
Issue 12957: Section: Section 3.1.6, Figure 23
Issue 12958: Section: Section 3.1.6, Fig. 23: Association "file" between "IncludeUnit" and "SourceFile"
Issue 12959: Section: Section 3.1.4, Fig. 17 - CompilationUnit
Issue 12960: Section: Section 3.1.9, Fig. 38 - Introduce "EnumLiteral" as a subclass of "Literal"
Issue 12961: Section: Section 3.1.6, Fig. 20 - Introduce "EnumTypeDefinition" as a subclass of "TypeDefinition"
Issue 12962: Section: Section 3.1.9 - Introduce the missing expression "CollectionExpression"
Issue 12963: Section: Section 3.1.9, Figure 41 - Introduce attribute "EvaluateAllCases" of type Boolean in the object "SwitchCase"
Issue 12964: Section: Section 3.1.6, Figure 19 - Introduce different FormalParameterDeclaration
Issue 12965: Section: Section 3.1.9, Figure 34 - operators "Negate" and "Not"
Issue 12969: Page: top of 19 Pluralize "model" in the second line
Issue 12970: Page: botton of 19 Something is missing between "SAST" and "GAST".
Issue 12971: Section: 1.7 editorial
Issue 12972: Page: botton of 19 section 5.2
Issue 12973: Section 5.7 second para -- editorial issue
Issue 12974: Section 5.8 editorial issue
Issue 12975: Doesn't "DataDefinition" need a type attribute?
Issue 12976: Artifacts of development such as change lists need to be removed and versions reset to OMG publication standards.
Issue 12977: Section 5.8.2 In DeclarationDefintion
Issue 12978: Section 5.8.2 Shouldn't "VariableDeclaration" have an attribute for the variable type?
Issue 12979: Section 5.8.3 attribute for "includedUnit" only works for C and C++
Issue 12980: Section 5.8.3 In Type: isn't "volatile" just another StorageSpecification?
Issue 12981: Section 5.8.2 The inclusion of "PureVirtual" as a "VirtualSpecification" is also C++-centric
Issue 12982: Section 5.8.4
Issue 13078: Section: Table of Contents, Table of Figures and Tables
Issue 13079: There is no Section 4.

Issue 12591: Describe behavior of BinaryExpression (astm-ftf)

Describe behavior of BinaryExpression. Some languages evaluate only the left hand side of a binary, Boolean expression if evaluating the right hand side would not change the result (i.e., short circuit evaluation). Some languages always evaluate both sides. Specification of this behavior in the GASTM promotes interoperability when translating from one language to another.

Describe the behavior of ConditionalExpression. Some languages only evaluate the condition and one result expression (i.e., short circuit evaluation) and others (e.g., Visual Basic) evaluate all three expressions. Specification of the expected behavior in GASTM promotes interoperability since translation of this behavior from one language to another will produce the expected result. Recommend adopting the short-circuit behavior since this appears to dominate

Describe the behavior of Modulus. Some languages find that (-3 mod 2 = 1) and others find that (-3 mod 2 = -1). Recommend adopting the latter since this would align with OCL 2.0 (formal/06-05-01) p.143 context: Integer.mod(i: Integer): Integer post: result = self - (self.div(i) * i) 

Faron wrote
Describe the behavior of Modulus. Some languages find that (-3 mod 2 = 1) and others find that (-3 mod 2 = -1). Recommend adopting the latter since this would align with OCL 2.0 (formal/06-05-01) p.143 context: Integer.mod(i: Integer): Integer post: result = self - (self.div(i) * i).
Ravindra Naik's reply
OK. Indeed it will be nice to have an OCL like language to specify the precise semantics of all such operations that can result in ambiguous results. Though adoption of OCL for such a purpose can be taken up in a separate FTF, I recommend adopting the interpretation of Modulus as suggested by Faron, and including the same in the specification.

Describe the behavior of BitRightShift. BitRightShift does not specify what to do with the sign bit or one could say that the concept of arithmetic shift does not exist in the ASTM.

As per C specifications, result of shift operation on a signed type with a negative value is undefined or implementation-defined. Therefore, the GASTM assumes the shift operators to be applicable to unsigned integers only. For signed integers, the SASTM can extend the GASTM and add new operators.
Email interaction on 24th Aug. 09: Post the ballot-voting

Ravindra Naik's message:
The proposed solution is to explicitly specify that the bit right shift is applicable only to unsigned integers. The reason is that the C language specification leaves the semantics of shift operation on a signed type with negative value as undefined (or implementation defined). So is true with C++ language. 
        Should the Generic ASTM (GASTM) capture such specific representations, which can have differing semantics for each vendor? If we do, then such a representation is unlikely to exhibit the "generic" characteristics. Essentially, we have adopted the strategy that representations and semantics of constructs that are common to many popular and commonly used programming languages be part of GASTM; thus GASTM is not a UNION of all programming languages, hence the proposed solution.
Faron's reply:
I see no issue with specifying an arithmetic shift right. Languages that do not have this concept, such as C and C++, will never need to add it to its model. Otherwise, languages that do not have unsigned integers, such as Java, cannot represent a right shift at all.
Philip Newcomb's reply:
Regarding issue #12594, the language modeling elements of the
GASTM are intended  to specify the most general treatment of
meaning as well as serve as base classes for specialization and
differentiation into more specialized constructs to be supplied
by the SASTMs.
 
This situation could be handled equally well either by modeling
signage within GASTM or by leaving signage for later treatment
by one or more SASTMs.  
 
However, the property of signage on bit shifting is so common
that it is probably better for pragmatic reasons to handle it
within the GASTM rather than in one or more SASTMS. 

Add description of square brackets to ABNF Notation. It is not obvious that constructs bracketed by {'[',']'} pairs imply an optional construct. In other words, implementation of the construct is at the discretion of the implementer. This implication is only found in the non-normative ABNF description.

The description of the notations used in the ABNF specifications are given in section 2.5, and these notations need to be corrected / extended. Please note the following:
    - Notation { '[, ']' } are used to specify semantic attributes or associations
    - Notation { '<', '>' } are used to specify attributes

Remove square brackets surrounding Scope.childScope. Scope is required in a L1 conforming implementation. Therefore, is seems reasonable to require the childScope attribute if Scope is implemented.

Change multiplicity of FunctionDefinition.returnType from 0..* (i.e., '*') to 0..1 (i.e., '?').

Consider changing Comment.text to Comment.body for consistency with MOF.

Inorder to adhere to MOF standards, it is suggested to change the name of attribute "text" of "Comment" object to attribute "body".

There is nothing to describe the relative ordering of ShortInteger, Integer and LongInteger. Nor is there anything to specify the range of values each may contain. Consider adding a precision attribute to Integer and removing ShortInteger and LongInteger. Consider moving PrimitiveType.isSigned to Integer.isSigned

Discussion:
Ravindra Naik's reply:
-Request Farron to elaborate what he means by "relative ordering"			           -Ranges of values are usually dependent on implementation. For example, in C language, pointer  is 4 bytes on Solaris CC, but 8 bytes on Linux gcc, and therefore range of values is not (usually) specified by the language (architecture dependent)                                      -Since ShortInteger and LongInteger are types specified by many languages, it may be worth retaining them in GASTM. Whether we retain them or not, the attribute "isSigned" must be kept with "PrimitiveType" so that proper extensions can be supported for SASTMs.
Faron's reply:
>Request Farron to elaborate what he means by "relative ordering".
What I mean by relative ordering is (ShortInteger.precision <= Integer.precision <= LongInteger.precision) and (ShortInteger.precision < LongInteger.precision). This is just an example that happens to use the same relative ordering defined in C. It is not a recommendation that we use this particular definition.
>… the attribute "isSigned" must be kept with "PrimitiveType" so that proper extensions can be supported for SASTMs.
What does it mean to have a signed Boolean, Void, Character, or String? Maybe we should introduce an abstract Number type and derive Integer and Real (i.e., Double et al) from it.
>Range of values are usually dependent on implementation. For example, in C language, pointer is 4 bytes on Solaris CC, but 8 bytes on Linux gcc, and therefore range of values is not (usually) specified by the language (architecture dependent)                                               					
Currently, the specification implies (section 1.4) several ways to populate a GASTM: as an extension or refinement of the GASTM, as a translation from a SASTM to the GASTM, and as a translation from some other meta-model such as UML. 
Imagine you are working with a language to language conversion project (scenario 3) where the source language is Java and the target language is C#. Also imagine, for the moment, that you already have an instance of the Java SASTM captured through parsing the Java source. You wish to translate this instance to an instance of the C# SASTM using QVT. This QVT script would need to understand both the source environment and the target environment. For example, the QVT script would have to know that a Byte in Java is signed while it is unsigned in C#. This script is tightly coupled to the source and target languages. Note that this scenario also applies if the source and target SASTM are extensions of the GASTM since the script would need to accommodate the additional model elements. 
A reusable approach would be to create a QVT script to translate the Java SASTM into a GASTM and a script to translate the GASTM into a C# SASTM. Ideally, this new GASTM to C# SASTM script would be totally decoupled from the source language and environment so that one could use it in a C to C# translation project or a Pascal to C# translation project. The problem with this approach is that the original population of the Java SASTM (itself a transformation) was lossy. The parser (i.e., translator) needed two things: the source file and the environment. For Java, the environment is J2SE, J2EE, or J2ME and possibly the language version (1.4, 1.5, 1.6, etc). For C, the environment includes details about the processor architecture and the layout of memory (e.g., the BIOS is located at 0x300). In general, this information is not captured by the GASTM.
 Now, if we recognize that the SASTM is a high-fidelity representation of its language and that the GASTM is more abstract. We need to capture the information in the GASTM in a language agnostic way. For numbers, I am recommending that the source SASTM provide the mapping from a C short on a 32bit OS into a GASTM Integer with precision =  16bits and isSigned = true rather than require the translator to understand both the source and target languages and environments. A similar approach would work when translating from another meta-model such as UML. The platform specific model contains the information about the environment needed to specify the size of an Integer.
 I suspect that we would have similar difficulties when using the KDM as an intermediate representation. The QVT script would be tightly coupled to the environmental information contained there.
Ed Barkmeyer's reply:
I think introducing the _abstract_ Number type is a good choice.  And it can collect signed/unsigned and precision concepts, since they are general to numeric types but not to other primitive types.  That will also do minimal damage to the existing model.
The ASTM doesn't support "fixed-point" type descriptions of the COBOL "PICTURE" kind, which presumably would be added in an appropriate SASTM. These can be signed or unsigned and have scaling, and pre-decimal-point precision.  Such a type would be a specialization of Number that then has all the common numeric properties.
> * Range of values are usually dependent on implementation. ...
That is putting it nicely.  Short and long integer are implementation directions -- pragmata that have become datatypes.  In C, they are not specifications of precision; they are guidelines for the compiler to choose a precision.  In the JVM, they are well-defined.  So JVM short maps to a well-defined GASTM short, and C short maps to 'undefined integer type'.  The mistake is to assume that GASTM short must be undefined so that C short can be mapped faithfully INTO it.  The consequence is that we can't map it reliably FROM the GASTM to any type in any SASTM other than C, and we can't even be sure that is right.(Half of all standard C programs are non-portable, for this reason and the undefined I/O operations.)
> Imagine you are working with a language to language conversion                                                > project (scenario 3) where the source language is Java and the                                                      > target language is C#. Also imagine, for the moment, that you                                                    > already have an instance of the Java SASTM captured through                                                  > parsing the Java source. You wish to translate this instance to                                                    > an instance of the C# SASTM using QVT. This QVT script would                                               > need to understand both the source environment and the target                                                 > environment. For example, the QVT script would have to know that                                           > a Byte in Java is signed while it is unsigned in C#. This script                                                      > is tightly coupled to the source and target languages. ...
The argument is that these are actually different datatypes.                                                       They are different specializations of integer that may have consequences for the proper interpretation/translation of the program. So the GASTM allows us to capture the signed/unsigned attribute.
> Now, if we recognize that the SASTM is a high-fidelity                                                            > representation of its language and that the GASTM is more abstract.                               > We need to capture the information in the GASTM in a language                                          > agnostic way.
That is, the same problem applies to the lengths of the values. When the PL says that the meaning of 'short' is implementation-defined, it means that the actual datatype is determined by the environment the program actually ran on!  And if we provide no means of characterizing that meaning in general terms, we can't capture the intended datatype!
There is merit in this argument.  JVM 'short' is well-defined, but C 'short' is defined by the runtime environment.  And either GASTM 'short' is well-defined, and can be reliably translated or it is not, and cannot be.
It seems to me that there are two different concerns here:                                                                                                                 - capturing in a general model the semantics of the C datatypes, with all the ambiguity specified in the language standard; and                                                                                    - capturing in a general model the semantics of the datatypes used in a running program, using however many manuals were needed to determine that information.
The GASTM currently supports the first, and I agree that we need to do that.  But Faron's point is that we need to do the second, and I agree with that as well.  Different users of the GASTM have different objectives, and we need to be able to do both.
If the GASTM allows the specification of precision (in bits) on these types, but also supports the mapping to nominal types, it can do both. So I half agree with Faron's proposal.  Do not take out the nominal 'short' and 'long' types, but do let us capture 'integer with bit precision x'.
> For numbers, I am recommending that the source SASTM                                                          > provide the mapping from a C short on a 32bit OS into a GASTM                                              > Integer with precision = 16bits and isSigned = true  
I think rather that it should be mapped to a GASTM Short with with precision = 16bits and isSigned = true
That is, for processors that care about the nominal types in C, the mapping to GASTM 'short' is important.  For processors that care about translating to a correct implementation, the 16bits and sign are also important. And this is more argument for isSigned and precision to be attributes of a general abstract Number type.
The object of the GASTM is to _enable_ the capture and transfer of the analysis knowledge.  So let us make it possible to do that.
 > A similar approach would work when translating from another                                                   > meta-model such as UML.   ...
I didn't follow this, and I don't think I believe it.  Mapping from the GASTM to fUML is another subject entirely.
Faron's reply:   
> I didn't follow this, and I don't think I believe it.  Mapping from the GASTM to fUML is another subject entirely.

The direction was from UML to GASTM. My point was that the PSM should contain enough information to define the width of an integer in the GASTM model. However, you are right in that this is another subject entirely.
Ravindra Naik's reply:   
While I agree with your view-point, there are data-types like "Character" and "Byte" which can also be signed / unsigned in C/C++/Java/C#. Therefore, while it is a good idea to introduce an _abstract_ type named "NumberType", we may have to allow Character and Byte to inherit from NumberType.
We recommend splitting "NumberType" further into "IntegralType" and "RealType". The object "IntegralType" can have the attribute "isSigned", and will have all integral types (ShortInteger, Integer, LongInteger) as sub-types. The object "RealType" will have sub-types Float, Double, and LongDouble) Also, it is true that all fixed-point types that include float and decimal of C will inherit from NumberType.
Ed has aptly stated the design considerations for the GASTM. I also do agree with Faron's requirements, as I have been involved in a number of one-language-to-another-language tools, and have found the need of the precision, better called as "size". It will be very useful to include a <semantic> attribute "size" for all number types. By making it semantic, GASTM proposes that it is relegated to Level 2 compliance, and is not necessary for Level 1 compliance.
Note that, "size" will also be required for PointerType, since size of pointer is also dependent on the environment, and not necessarily specified by the language.
Another point we have noticed is the need of attribute "offset" - this is required for Members of AggregateType to capture the offset of the fields of the aggregate. The offset is required to capture the actual offset of the field with respect to the start address of the first field (which is 0). The offset can be different than the summation of the sizes of all previous fields because of word alignment that is dictated by the environment. Such an "offset" field can be specified as a <semantic> attribute.
When we looked at all the primitive types, we think that "String" does not appear to be really a PrimitiveType. Even in Java, it is actually a class type, and therefore can be added to the Java SASTM. We recommend dropping the "String" type from GASTM.

There is nothing to describe the relative ordering of Character and WideCharacter. Nor is there anything to specify the range of values each my contain. Consider adding an encoding attribute to Character or specifying a fixed encoding such as UTF-16 and deleting WideCharacter

Ravindra Naik's suggestion
We recommend considering variable-length character encoding for Unicode (UTF16) since most languages have adopted this. We agree that type WideCharacter (on many UNIX systems, this makes use of UTF32 encoding), though common to C and C++, can be dropped from GASTM specification, and can be added by the respective SASTMs.
Refer to Discussion section of Issue# 12599.

There is nothing to describe the relative ordering of Float, Double and LongDouble. Nor is there anything to specify the range of values each my contain. Consider adding a precision attribute to Float and deleting Double and LongDouble. Consider renaming Float to Real for consistency with OCL and UML

Ravindra Naik's suggestion
Since both Double and LongDouble are standard types in C99, and are supported by Java as well, it may be worth letting them be in GASTM. We agree with the suggestion to add precision as an attribute, Refer to Discussion section of Issue# 12599. Also, the name "Float" is recommended to be changed to "Real".

Change multiplicity of EnumType.enumLiterals from 1..* (i.e., '+') to 0..* (i.e., '*').

In the EBNF of GASTM, the EnumType.enumLiterals should continue to be 1..* (ie '+'), because while defining an enumeration, atleast one enum literal is mandatory. For e.g. enum Color { red, green, yellow }: here atleast one of the colors is mandatory. However, a forward declaration of enum type is allowed, and hence "enum Color" is a valid forward declaration, for which a provision must be made in the GASTM specification. We suggest including TypeDeclaration for this purpose, as follows:
Declaration		=>	TypeDeclaration;
TypeDeclaration	=>	AggregateTypeDeclaration
			=>	EnumTypeDeclaration;
TypeDeclaration	->	typeRef: TypeReference
Farron's reply:
About Issue # 12: 12602
Change multiplicity of EnumType.enumLiterals from 1..* (i.e., '+') to 0..* (i.e., '*').

I submitted this issue on an earlier version of the document so the page numbers no longer match. The relevant pages are 51, 71 and 92. I assume that section 3 is normative and section 2 is informative. Correct me if I'm mistaken.

The text for section 3.2.1.3.4.2.2 (below and page 92) claims in the description that EnumType has zero to many EnumLiteralDefinition while the property specification has one or more. Figure 27 on page 71 agrees with the property specification. The EBNF description in section 2.11.4 (page 51) also agrees with the property specification.

3.2.1.3.4.2.2 EnumType
    EnumType is a subclass of DataType, and has zero to many association enumLiterals to EnumLiteralDefinition.
  Property Specification:
    EnumType -> enumLiterals : EnumLiteralDefinition+
    ;

I ask that the multiplicity be changed to 0..* so that languages such as Java and C#, which do not require an EnumType to contain members, may be supported by the GASTM. Java, in particular, allows an EnumType to have member fields, methods, and constructors. In the case where the EnumType has no EnumLiteralDefinition, the EnumType behaves as a Class that cannot be extended.

I recommend moving the constraint on the lower bound to those SASTMs that require at least one EnumLiteralDefinition.
Ravindra Naik's reply:
For issue # 12602, I do understand your suggestion. However, Java enumerations seem to far more powerful than C enums(an example is available at http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html. There are other capabilities of Java's Enums that the EnumType in GASTM will not be able to support. These are:
	- Java enums can have attributes and methods
	- Java enum literals can have data associated with them
	- Java enums cannot extend other enums or classes (means that the EnumType cannot be treated as a class)
In short, this means that the Java Enums can be supported by extending AggregateType of GASTM. The C# language also has similar semantics attached to Enums. Therefore, I suggest that we should leave the Java and C# enums to be modelled at the SASTM level.

If the above is agreed, then should we retain EnumType at all in GASTM?

Ravindra Naik's suggestion:
For Java and C#, the Enums are much more powerful, can have attributes and methods (like classes), and are recommended to be represented in Java / C# SASTM by inheriting from AggregateType of GASTM. Additionally, Java Enums will need association of multiplicity 0..* to model enumeration literals.

It is recommended to retain multiplicity of EnumType as is, viz. EnumType.enumLiterals 1..* (i.e., '+') since enumeration definitions need to have atleast one enumeration literal.
To address the issue of forward declaration of enums and aggregate types, we introduce TypeDeclaration, as follows:
DefinitionUnit		=>	TypeDeclaration;
TypeDeclaration	=>	AggregateTypeDeclaration
			=>	EnumTypeDeclaration;

TypeDeclaration	->	typeRef: TypeReference

Consider changing the name of SourceLocation to SourceRegion for consistency with the KDM. Consider changing the names of SourceLocation's attributes to match those in KDM::Source::SourceRegion.

TCS believes that "SourceLocation" represents a more suitable name, since it represents a contiguous and specific position of source code, starting from a certain column and a certain line and ending at another column in another or same line. Region is a term with broader meaning, which can mean potentially discontiguous locations.
      While we would encourage having uniform naming conventions between ASTM and KDM as well as other standards, we would also like to recommend and adopt names that capture the underlying concept naturally.

Consider changing SourceFile.pathName to SourceFile.path for consistency with the KDM. pathName implies the name of a path rather than the path itself.

Inorder to adhere with the KDM standards we should consider changing name of attribute "pathName" of SourceFile object to "path".  Also "pathName" implies the name of a path rather than the path itself.

Consider removing the attribute language from CompilationUnit and adding it to SourceLocation. Having a language specifier on CompilationUnit precludes mixed language files such as embedded SQL in C source.

The attribute "language" in "CompilationUnit" is meant to capture the host language in which the program is written. Therefore, it is recommended to be retained as is.
If there are embedded language statements, they are enclosed within appropriate language name enclosures. For e.g. EXEC SQL, or extern 'C' or extern 'pascal'. Such embedded language statements, therefore, can be represented in the SASTM or PASTM with respective language names. SASTM / PASTM can use "AnnotationExpression" to capture such information.

Change ActualParameterE to ActualParameter

This seems to be a typo. It needs to be corrected

Document version (1.3.2) does not match last entry in Revision History (1.6). Document date does not match date of update.

Change IntegerlLiteral to IntegerLiteral

This seems to be a typo. It needs to be corrected to two places in the specifications.

Change the word before to after in the description of ForCheckAfterStatement

Change the word OpenScope to opensScope in footnote 5.

Footnote 11 is not clear

The specific foot-note <11> gives an example of the extent of what all is covered by the object "FunctionDefinition". Most of the footnotes were to ensure better communication while creating the specifications. We recommend to delete this footnote, and other footnotes in sections 2.10 and 2.11 as well, since these descriptions are captured in the normative portion of the document.
Issue# 12610 and Issue# 12612 from Ballot 1 are merged with this issue.

Change OpenScope to opensScope in footnote 12

Inconsistent naming of FunctionMemberAttribute. Sometimes called FunctionMemberAttributes

Association "className" is between "DerivesFrom" and "NamedType". Since one class can inherit from many classes, the target object should be "NamedTypeReference" and not "NamedType".

This is a correction that is mandatory.
The reason is not because there are multiple classes that a class can inherit from (this is taken care by the cardinality (0..M) of the association derivesFrom:DerivesFrom between ClassType and DerivesFrom). The reason is because the target of "DerivesFrom" is only a reference to a class, while the class itself is defined elsewhere.

Association "file" between "IncludeUnit" and "SourceFile" represents the source that is included. Since the same source can be included at multiple places, the target of this assocation can be "SourceFileReference" rather than "SourceFile"

The reason is that the association "file" between "IncludeUnit" and "SourceFile" represents the source that is included. Since the same source can be included at multiple places, the target of this assocation should be "SourceFileReference" rather than "SourceFile". Also, it is necessary to store the location information for each inclusion point.

CompilationUnit is not a Syntax object in itself, it is a container of syntax objects. Hence, it should belong to the GASTMSourceObject, and can actually inherit from SourceFile. Thus, SourceFile can represent copybooks or include files, and CompilationUnit can represent all other source files.

CompilationUnit is not a Syntax object in itself; it is a container of syntax objects. Hence, it should belong to the GASTMSourceObject, and should inherit from SourceFile. Thus, SourceFile can represent copybooks or include files, and CompilationUnit can represent all other source files.

Introduce "EnumLiteral" as a subclass of "Literal", since Enumeration Literals have no specific representation. 

The GASTM seems to have missed creating a representation for eunumeration literals. TCS proposes to add "EnumLiteral" as a subclass inheriting from "Literal".

Introduce "EnumTypeDefinition" as a subclass of "TypeDefinition", since it is missing from the ASTM specification. It will need to have an association named "definitionType" with "EnumType" that is already present.

The GASTM seems to have missed creating a representation for enumeration type.
We propose to add "EnumTypeDefinition" as a subclass inheriting from "TypeDefinition", and add an association "definitionType" with class "EnumType"

Introduce the missing expression "CollectionExpression". This is required to represent initialization expressions of C like { 10, 20, 30 }, and VALUE clause of COBOL like 10, 20, 30.

Initialization expressions like {10, 20, 30}, and VALUE clause of COBOL like 10, 20, 30 can be naturally represented by having a specific class of expression called CollectionExpression.

Introduce attribute "EvaluateAllCases" of type Boolean in the object "SwitchCase". This is to take care of capturing the differing semantics of whether to evaluate all cases or the first successful case.

In C Switch statement, only the first case expression that evaluates to the same value as that of the switch expression is matched, in COBOL Evaluate statement, all cases whose values match the Evaluate expression are considered to match.

Introduce different FormalParameterDeclaration (probably as subclasses) to handle "Ellipses" (…) parameter and "void" parameter

The unary operators "Negate" and "Not" appear to be similar, and hence one of them can possibly be discarded.

It seems to be an oversight to include both Negate and Not as Unary operators. We recommend to drop Negate and retain the Not as Unary operator.

Pluralize "model" in the second line

Something is missing between "SAST" and "GAST".

Change "conformance" to "conform". 2nd paragraph" change "agrede" to "agreed". 4th paragraph, 1st bullet: change "compliancewith" to "compliance with“

First sentence: change "is" to "as“

Second paragraph, pluralize "CompilationUnit". Third paragraph, change "the name" to "a name" (two occurrences), change "subclassified" to "subclassed", eliminate double "into“

Cannot parse the first sentence, please revise. In footnote, change "implementationdependent" to "implementation dependent".

Doesn't "DataDefinition" need a type attribute?

Artifacts of development such as change lists need to be removed and versions reset to OMG publication standards. 

In DeclarationDefintion, why isn't isRegister simply another StorageSpecification? Also seem too C-centric to include into a GASTM.

Shouldn't "VariableDeclaration" have an attribute for the variable type?

The attribute for "includedUnit" only works for C and C++. Both Java and Ada import a CompilationUnit.

In Type: isn't "volatile" just another StorageSpecification?

While your observation is valid, the "volatile" characteristic of Type is too C centric. We recommend dropping "isVolatile" attribute of "Type" object from GASTM and moving it into a SASTM for C.

The inclusion of "PureVirtual" as a "VirtualSpecification" is also C++-centric. Both Java and Ada recognize abstract-ness as different from the method of call resolution.

PureVirtual is too C++ centric for GASTM.  We recommend dropping "PureVirtual" from the GASTM and moving into a SASTM. 
Also, we recommend dropping "NonVirtual" object since OO languages do not explicitly specify non-virtuality. This also means that the association "virtualSpecifier" in the object "FunctionMemberAttributes" should become optional.
Also, we recommend replacing the attribute "isVirtual" with an optional association "virtualSpecifier" of type "VirtualSpecification" in the object "DerivesFrom".

The attributes startLine, startColumn, endLine, endColumn would seem to be syntactic elements, not semantic elements as annotated.

These are actually lexical properties (because a lexer captures this information).  We have already captured these properties as part of SourceLocation, which represents lexical characteristics.
We will incorporate corresponding change in the Table 11, and introduce another Table to describe source elements. We will also change the description of section 2.9 to reflect this decision.
Also, the description of denoting syntactic attributes and associations, and semantic attributes and associations in the abbreviated BNF needs correction in section 2.5. 

Regenerate Table of Contents, Table of Figures and Table of Tables to correct pagination.  Correct as an OMG editorial issue.

 1.1  Overview of the ASTM Specification 
                
                      There is no Section 4.   Correct as an OMG editorial issue.