Section 5.8: What is the value of the definition of "OtherSyntaxObject"?

The change to specification is to replace name OtherSyntaxObject with new name MinorSyntaxObject at following places:
Table 2.3, page# <40>; Section# <2.11>, page# <47>, line# <14>; Section# <2.11.1>, page# <47>, line# <18>; Section# <3.1.6>, page# <63>, line# <13>; Section# <3.2.1.3>, page# <82>, line# <24>; Section# <3.2.1.3>, page# <83>, line# <1>; Section# <3.2.1.5>, page# <105>, line# <33, 35>; Section# <3.2.1.5.9.3>, page# <113>, line# <2, 23>; Section# <3.2.1.5.9.5>, page# <114>, line# <8>; Section# <3.2.1.5.9.6>, page# <115>, line# <9>; Section# <3.2.1.5.9.7>, page# <115>, line# <23>; Section# <A.2.1>, page# <123>, line# <4>.
An equivalent change is recommended in Figures 17, 21, 23, 33, , page# <65>as follows (only Figure 33 is shown since all other diagrams are already shown in previous issues of Ballot 2)

Figure 35
Disposition: Resolved

From consistency point of view, suggest change name of association "aName" between "LabelAccess" and "Name" to "labelName". Also association "aDefinition" between "LabelAccess" and "LabelDefinition" to "labelDefinition".

A change to specification will be in section# <2.11.2>, page# 50, line# 1 will change name of association from "name" to "typeName".
The Figure 20, in section# <3.1.6>, page# <65> will incorporate an appropriate equivalent change as follows.

Figure 20
A change to specification will be in section# <3.2.1.3.3.3>, page# 89, line# 2 will change name of association from "name" to "typeName".

A change to specification will be in section# <2.11.5>, page# 53, line# 8 will change name of association from "name" to "typeName".
The Figure 27, in section# <3.1.7>, page# <70> will incorporate an appropriate equivalent change as follows.

Figure 26
A change to specification will be in section# <3.2.1.3.4.5.2>, page# 96, line# 15 will change name of association from "name" to "typeName".

A change to specification will be in section# <2.11.7>, page# 55, line# 45 will change name of association from "name" to "identifierName".
The Figure 39, in section# <3.1.9>, page# <78> will incorporate an appropriate equivalent change as follows:

Figure 41
A change to specification will be in section# <3.2.1.4.9>, page# 100, line# 5 will change name of association from "name" to "identifierName".

A change to specification will be in section# <2.11.7>, page# 58, line# 13 will change name of association from "name" to "labelName".
The Figure 41, in section# <3.1.9>, page# <79> will incorporate an appropriate equivalent change as follows.

Figure 43
A change to specification will be in section# <3.2.1.4.11>, page# 101, line# 28 will change name of association from "name" to "labelName".

A change to specification will be in section# <2.11.7>, page# 58, line# 14 will change name of association from "definition" to "labelDefinition".
The Figure 41, in section# <3.1.9>, page# <79> will incorporate an appropriate equivalent change as above.
A change to specification will be in section# <3.2.1.4.11>, page# 101, line# 29 will change name of association from "definition" to "labelDefinition".

The Figure 28, in section# <3.1.7>, page# <71> will incorporate change to replace association name "aType" with "type" between objects NamedTypeReference and TypeDefinition, and association name "aType" with "type" between objects UnnamedTypeReference and Type, and is yet to be created.

Figure 26

Disposition: Resolved

1.1 Overview of the ASTM Specification

There is no Section 4. Correct as an OMG editorial issue.

Discussion:
Editorial correction in section 1.1 to correct references to Sections 4, 5, 6, 7, 8 and 9.
Summary of changes:
The change to specifications will be in section 1.1. References to section# 4.1, 4.2, 4.3, 4.4 will be corrected to section# 2.1, 2.2, 2.3, 2.4 respectively. Reference to section# 5 will be replaced with section# 2.5 to 2.11. Reference to section# 6, 7, 8, 9 will be replaced with section# 3, 1.9, 1.10 and 1.11 respectively. Few wordings will also need correction.
Disposition: Resolved

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

No Data Available

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

No Data Available

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

Discussion:
Refer to Discussion section of Issue# 12591.
Recommend adopting the short-circuit behavior.
Summary of changes:
The change to specification will be in section# <3.2.1.4.6>, page# <98>, line# <3>. New description added will be along the lines "Default behavior is short-circuit semantics of evaluation for onTrueOperand or onFalseOperand".
A change to specification will also be in section# <2.11.7>, page# <57>, line# <33>. By creating a reference to the semantics specified in the section 3.2.1.4.6 (described in previous para)
Disposition: Resolved

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.

Discussion:
Since logical binary operators (and, or) have evaluation semantics specified by language definition, it will be useful and important to include these semantics in the GASTM specification. There are three possibilities:

• We can assume that the default behavior is short-circuit semantics of evaluation. For other languages (e.g. VB), new operators can be defined in the SASTM for VB.
• Add an attribute (flag) for the binary logical operators (AND, OR) to indicate short-circuit evaluation. For this, we may have to introduce abstract classes for operators like logical operators, relational operators and mathematical operators
• Add new operators (ANDAND, OROR or any other suitable names) to specify short-circuit semantics of evaluation
  TCS recommends the first option of attaching default (short-circuit) behavior.
  Summary of changes:
  The change to specification will be in section# <3.2.1.5.9>, page# <111>, line# <6>. New description added will be along the lines "Default behavior is short-circuit semantics of evaluation for binary operators And, Or, BitOr, BitAnd, BitXor".
  A change to specification will also be in section# <2.11.7>, page# <56>, line# <47>. Create a reference to the semantics specified in the section 3.2.1.5.9 (described in previous para)
  Disposition: Resolved

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

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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)

The change to the specification will be in section# <3.2.1.5.9>, page# <110>, line# <21>. New description will be added along the lines "Default behavior of Modulus operator: Integer.mod(i: Integer): Integer post: result = self - (self.div * i)".
A change to specification will also be in section# <2.11.7>, page# <57>, line# <10>. Create a reference to the semantics specified in the section 3.2.1.5.9 (described in previous para).

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.

Please note that notation

is used to specify semantic attributes or associations. Since Scope and childScope are both semantic object and semantic association respectively, hence the square brackets around the childScope association is correct.
Summary of changes:
No change in specifications.
Disposition: Closed, No change

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 change to specification will be in section# <2.5>, Page# <43>, line# <18>. Replace line# <18> with the description "Notation

are used to specify attributes". Introduce at line# <19> the description "Notation

are used to specify semantic attributes or associations".

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

No Data Available

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

No Data Available

Change ActualParameterE to ActualParameter

The change to specification will be in section# <3.2.1.5.9.5.1>, page# <115>, line# <4>. Change description<ActualParameterE> to new description <ActualParameter>.

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.

No change is recommended in the specification

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.

The change to specification will be at following places:
Section# <2.3>, page# <42>, Table#<8> Row# <A175>, Change description <remove row describing PureVirtual>, Section# <3.2.1.5.9.3>, page# <113> and line# <6>, Change description <remove <VirtualSpecification => PureVirtual> >, Section# <3.2.1.5.9.3.2>, page# <113> and line# <14>, Change description<remove description of PureVirtual>

Section# <2.3.>, page#<42>, Table#<8> Row# <A176>, Change description< remove row describing NonVirtual>, Section# <3.2.1.5.9.3>, page#<113> and line# <6>, Change description <remove <VirtualSpecification => NonVirtual> >, Section# <3.2.1.5.9.3.3>, page#<113> and line# <18>, Change description<remove description of NonVirtual>,
Section# <2.11.5>, page#<52> and line# <41>, Change description <<isVirtual: Boolean>> to <virtualSpecifier: VirtualSpecification> , Section# <3.2.1.5.9.7>, page#<115> and line# <24>, Change description <Boolean property isVirtual> to <an optional association virtualSpecifier of type VirtualSpecification>, Section# <3.2.1.5.9.7>, page#<115> and line# <26>, Change description <<isVirtual : Boolean>> to <virtualSpecifier: VirtualSpecification>
The diagram <Figure 21>, page# <65> will incorporate an appropriate and equivalent change to as follows:

Figure 25
Also, Figure 22 is dropped as its contents are merged with those in Figure 21.
The diagram <Figure 23>, page# <66> will incorporate an appropriate and equivalent change as follows.

Figure 30

Disposition: Resolved

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

The change to specification will be at following places:
Section# <2.11.4>, page# <51>, and line# <6>, Remove <isVolatile : Boolean>. Equivalent changes are recommended at following places.
· Section# <3.2.1.3.4>, page# <89>, and line# <12>
· Section# <3.2.1.3.4>, page# <89>, and line# <15>
· Section# <3.2.1.5.9.2>, page# <112>, and line# <4>
· Section# <3.2.1.5.9.2>, page# <112>, and line# <12>

Also, the diagram# <Figure 17>, and <Figure 27> will incorporate an appropriate and equivalent change as follows:

Figure 17

Figure 26

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

"isRegister" attribute seems to be too C-centric for GASTM. We recommend dropping "isRegister" attribute of "DeclarationOrDefinition" object from the GASTM
Summary of changes:
The change to specification will be at following places:
Section# <2.11.2>, page# <48>, and line# <5>, Change description <remove isRegister : Boolean>. Equivalent changes are recommended at
· Section# <3.2.1.3.3>, page# <84>, and line# <24>
· Section# <3.2.1.3.3.1>, page# <84>, and line# <40>
Also, the diagram <Figure 19>, page# <64> will incorporate an appropriate and equivalent change as follows. Note that the single picture for DeclarationObject is split into two pictures for the purpose of clarity.

New Figure (diagram number will be given in the specification document)

Figure 22: DeclarationOrDefinition object

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

Discussion:
This issue was reported as part of the architecture board review. Since then, the specification document was modified and the issue is already addressed and closed.
Summary of changes:
No change in specifications.

Disposition: Closed, No change

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

Discussion:
It is necessary to correctly re-generate the Table of Contents, Table of Figure and Table of Tables.
Summary of changes:
The change to specifications will be in Table of Contents at page# <v>, List of Figures at page# <viii>, and List of Tables at page# <x>.

Disposition: Resolved

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

The change to specification will be at following places
Section# <2.7>, page# <45>, and table# <11>, Change description<delete initial two rows
Section# <2.7>, page# <45>, and line#<12>, Change description <Introduce new table as table#<12> with following rows and columns
SourceFile The source files that physically contain the programming language elements.
SourceLocation The physical source code location of each programming language element.
>
Section# <2.5>, page# <43>, line# <17>, Replace the description in left block with that in the right block.

Section# <2.5>, page# <43>, line# <18>, Replace the description in first block with that in the second block.

Disposition: Resolved

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

No Data Available

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

Discussion:
This seems to be an invalid Observation. "VariableDeclaration" does indeed have an association for variableType. This association is called "declarationType" and is specified one-level higher in the hierarchy for the "Declaration" object.
Summary of changes:
No change is recommended in the specification.
Disposition: Closed, No change

Doesn't "DataDefinition" need a type attribute?

DataDefinition does indeed need a type attribute. The type attribute is already present in Definition class, which is the super-class of DataDefinition. The type attribute is modeled as an association named "definitionType" with the class "TypeReference".
Summary of changes:
No change in specifications.

Disposition: Closed, No change

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

Discussion:
The issue was reported as part of the architecture board review. Since then, the specification document was modified and the issue is already addressed and closed.
Summary of changes:
No change in specifications.
Disposition: Closed, No change

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

The change to the specification will be in section# <2.11.7>, page# <56>, line# <36>. The class Negate will be deleted.
The Figure 34, in section# <3.1.9>, page# <75> will incorporate an appropriate equivalent change <ToBeDone>.
The Table 8 will be updated in section# <2.3>, page# 41 to delete the entry for "Negate".
Disposition: Resolved
Email interaction on 24th Aug. 09: Post the ballot-voting
The proposed solution was to drop Negate and retain Not. Both Faron and Nick have correctly pointed out that the two operators are different. While "Not" produces logical inversion of its boolean operand, "Negate" produces 2's complement of its integer operand. We recommend a change to the resolution - retain the "Negate" operator, but with the name as "UnaryMinus".
An equivalent change to diagram is in Figure 34.

Figure 36

First sentence: change "is" to "as“

The issue was reported as part of the architecture board review. Since then, the specification document was modified and this issue is not traceable in Beta1 specification. We assume that this issue is addressed and closed.
Summary of changes:
No change is recommended in the specification.
Disposition: Closed, No change

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

Discussion:
The issue was reported as part of the architecture board review. Since then, the specification document was modified and this issue is not traceable in Beta1 specification. We assume that this issue is addressed and closed.
Summary of changes:
No change is recommended in the specification.
Disposition: Closed, No change

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

The issue was reported as part of the architecture board review. Since then, the specification document was modified and this issue is not traceable in Beta1 specification. We assume that this issue is addressed and closed.
Summary of changes:
No change is recommended in the specification.
Disposition: Closed, No change

Pluralize "model" in the second line

The issue was reported as part of the architecture board review. Since then, the specification document was modified and this issue is not traceable in Beta1 specification. We assume that this issue is addressed and closed.
Summary of changes:
No change is recommended in the specification.
Disposition: Closed, No change

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

The issue was reported as part of the architecture board review. Occurrence of "subclassified" is recommended to be changed to "subclassed". Since the architecture board review, the specification document was modified and other concerns reported in the issue are not traceable in Beta1 specification. We assume that the other concerns are addressed and closed.
Summary of changes:
Change the word "subclassified" to "subclassed" at section# <2.10>, page# <46>, line# <10>.
Disposition: Resolved

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.

Section# <2.11.1>, page#47, and line# <20>, Remove <OtherSyntaxObject =>CompilationUnit>
Section# <2.9>, page#45, and line# <24>, Add <SourceFile => CompilationUnit >
Section# <2.11.1>, page#47, and line# <34>, Move
< CompilationUnit -> <language : String>
fragments : DefinitionObject*
[opensScope : ProgramScope?]
;
To
Section# <2.9>, page#45, and line# <31>
Also, the Figure 16 at section# <3.1.3>, page# <60> and Figure 17 at section# <3.1.4>, page# <61> will incorporate an appropriate and equivalent change as follows: (Figure 16 is shown for Issue# 12603)

Figure 17

Disposition: Resolved

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 change to specification will be in section# <3.2.1.3.1.1>, page# <83>, line# <20>. Change <IncludeUnit -> file : SourceFile > to < IncludeUnit -> file : SourceFileReference>. Similar change in section# <2.11.3>, page# <50>, line# <34>. Introduce SourceFileReference in Table 8, Section# <2.3>.
The Figure 18 at page# <63>, section# <3.1.5> will incorporate an appropriate and equivalent change to <ToBeDone>.
Also, add the following specification at section# <2.9> page# <45>, line# <21> and <25> respectively.
SourceFile => SourceFileReference
SourceFileReference -> locationInfo : SourceLocation
-> [ ofSourceFile : SourceFile ]
The Figure 16 at section# <3.1.3>, page# <60> will incorporate an appropriate and equivalent change to <ToBeDone>. Note that the existing Figure 16 is not a correct one, and needs to be replaced with the correct figure for GASTMSourceObject, as shown for issue 12603.
Disposition: Resolved

Introduce the missing expression "CollectionExpression". This is required to represent initialization expressions of C like

, and VALUE clause of COBOL like 10, 20, 30.

A change to specification will be in section# <2.3>, Table 8, page# 39, will introduce an entry for CollectionExpression with an appropriate section number.
A change to specification will be in section# <2.11.7>, page# 55, line# 38. Add an entry for CollectionExpression.
A change to specification will be in section# <2.11.7>, page# 58, line# 23. Add the following:
CollectionExpression -> expressionList : Expression *
The Figure 37 or Figure 39, in section# <3.1.9>, page# <77> or <78> will incorporate an appropriate equivalent change <ToBeDone>.
A change to specification in section# <3.2.1.4>, page# <95>, line# <27> will add an entry for CollectionExpression. Will also add an appropriate hierarchy specification by introducing a new section# <3.2.1.4.13>, page# <101>, line# <2>.

Figure 41
An update will be required in the table of appendix B.1, page# 129, 5th row from top titled "CollectionExpression", and an entry to be added in Table 8, section# <2.3>.
Disposition: Resolved

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 change to specification will be at following places.
At Section# <2.11.2>, page# <50>, line# <6> and section# <3.2.1.3.3.3>, page# <88>, line# <9>, add <TypeDefinition => EnumTypeDefinition>
At Section# <2.11.2>, page# <50>, line# <15>, add <EnumTypeDefinition -> definitionType : EnumType;>
Add a new section# <3.2.1.3.3.3.3>, page# <88>, line# <26> to explain EnumTypeDefinition.
The Figure 20 at section# <3.1.6>, page# <65> will incorporate an appropriate and equivalent change as follows:

Figure 20

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

Though this is a valid requirement, it is very specific to C programming language, and therefore can be incorporated in the SASTM of C. Therefore, this change is recommended not to be incorporated in the GASTM specifications.

Summary of changes:
No change in specifications.
Disposition: Closed, No change

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.

The change to the specification will be in section# <2.11.6>, page# <54>, line# <21>. New attribute will be added for SwitchCase class as follows:
SwitchCase -> < isEvaluateAllCases : Boolean >
The Figure 32, in section# <3.1.8>, page# <74> will incorporate an appropriate equivalent change as follows.

Figure 33

Disposition: Resolved

Inconsistent naming of FunctionMemberAttribute. Sometimes called FunctionMemberAttributes

No Data Available

Change OpenScope to opensScope in footnote 12

Discussion:
This seems to be a typo. It needs to be corrected.
Summary of changes:
The change to specification will be in section# <2.11.2>, page# 49, Footnote # <12>. Change description <OpenScope is an optional semantic attribute> to new description <Assocation opensScope is an optional semantic association>.
This issue is similar to the issue# 12611 of Ballot 3 about footnotes , and is therefore merged with issue# 12611.

Disposition: Duplicate or Merged

Change the word OpenScope to opensScope in footnote 5.

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

Summary of changes:
The change to specification will be in section# <2.11.2>, page# 47, Footnote # <5>. Change description <OpenScope is an optional semantic attribute> to new description <Assocation opensScope is an optional semantic assocition>.
This issue is similar to the issue# 12611 of Ballot 3 about footnotes , and is therefore merged with issue# 12611.

Disposition: Duplicate or Merged

Change the word before to after in the description of ForCheckAfterStatement

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

Summary of changes:
The change to specification will be in section# <3.2.1.4.13.11.5>, page# <104>, line# <40>. Change description <Condition is tested before the Body is executed> to new description <Condition is tested after the Body is executed>.
Also, a related change is recommended in section# <3.2.1.4.13.11.4>, page# <104>, line #<34>. Change description <ForCheckStatement> to new description <ForCheckBeforeStatement>.

Change IntegerlLiteral to IntegerLiteral

The change to specification will be in section# <2.11.7>, page# <56>, line# <17>, and section# <3.2.1.4.1.>, page# <96>, line# <10>. Change description <IntergerlLiteral> to new description <IntegerLiteral>.

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

In the Beta 1 version of the document, the above discrepancy is eliminated.
Summary of changes:
No change is recommended in specifications.
Disposition: Closed, No change

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

The change to specification will be in section# <2.11.7>, page# <56>, line# <17> and section# <3.2.1.4.1>, page# <96>, line# <10>. Add <Literal => EnumLiteral > in the Literal's subclass hierarchy
The Figure 38 at section# <3.1.9>, page# <78> will incorporate an appropriate and equivalent change as follows:

Figure 40

Disposition: Resolved

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

No Data Available

Footnote 11 is not clear

The change to specification will be in sections 2.10 and 2.11. All the footnotes will be deleted in these two sections.
Disposition: Resolved