Abstract Syntax Tree Metamodel Avatar
  1. OMG Specification

Abstract Syntax Tree Metamodel — All Issues

  • Acronym: ASTM
  • Issues Count: 50
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
ASTM-50 Section 5.8: What is the value of the definition of "OtherSyntaxObject"? ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-49 Section: Section 3.1.9, Figure 41 ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-35 Section: 1.7 editorial ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-34 Page: botton of 19 Something is missing between "SAST" and "GAST". ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-33 Page: top of 19 Pluralize "model" in the second line ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-32 Section: Section 3.1.9, Figure 34 - operators "Negate" and "Not" ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-31 Section: Section 3.1.6, Figure 19 - Introduce different FormalParameterDeclaration ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-30 Section: Section 3.1.9, Figure 41 - Introduce attribute "EvaluateAllCases" of type Boolean in the object "SwitchCase" ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-29 Section: Section 3.1.9 - Introduce the missing expression "CollectionExpression" ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-28 Section: Section 3.1.6, Fig. 20 - Introduce "EnumTypeDefinition" as a subclass of "TypeDefinition" ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-27 Section: Section 3.1.9, Fig. 38 - Introduce "EnumLiteral" as a subclass of "Literal" ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-26 Section: Section 3.1.4, Fig. 17 - CompilationUnit ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-25 Section: Section 3.1.6, Fig. 23: Association "file" between "IncludeUnit" and "SourceFile" ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-24 Section: Section 3.1.6, Figure 23 ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-23 Inconsistent naming of FunctionMemberAttribute ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-22 Change OpenScope to opensScope in footnote 12 ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-21 Footnote 11 is not clear ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-20 Change the word OpenScope to opensScope in footnote 5 ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-48 There is no Section 4. ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-47 Section: Table of Contents, Table of Figures and Tables ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-46 Section 5.8.4 ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-45 Section 5.8.2 The inclusion of "PureVirtual" as a "VirtualSpecification" is also C++-centric ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-44 Section 5.8.3 In Type: isn't "volatile" just another StorageSpecification? ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-43 Section 5.8.3 attribute for "includedUnit" only works for C and C++ ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-42 Section 5.8.2 Shouldn't "VariableDeclaration" have an attribute for the variable type? ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-41 Section 5.8.2 In DeclarationDefintion ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-40 Artifacts of development such as change lists need to be removed and versions reset to OMG publication standards. ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-39 Doesn't "DataDefinition" need a type attribute? ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-38 Section 5.8 editorial issue ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-37 Section 5.7 second para -- editorial issue ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-36 Page: botton of 19 section 5.2 ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-4 Describe the behavior of BitRightShift. ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-3 Describe the behavior of Modulus ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-2 Describe the behavior of ConditionalExpression ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-1 Describe behavior of BinaryExpression ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-11 relative ordering of Float, Double and LongDouble ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-10 relative ordering of Character and WideCharacter ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-9 relative ordering of ShortInteger, Integer and LongInteger ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-8 Consider changing Comment.text to Comment.body for consistency with MOF ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-7 Change multiplicity of FunctionDefinition.returnType ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-6 Remove square brackets surrounding Scope.childScope ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-5 Add description of square brackets to ABNF Notation ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-19 Change the word before to after in the description of ForCheckAfterStatemen ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-18 Change IntegerlLiteral to IntegerLiteral ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-17 Document version (1.3.2) does not match last entry in Revision History (1.6 ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-16 Change ActualParameterE to ActualParameter ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-15 Consider removing the attribute language from CompilationUnit ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-14 Consider changing SourceFile.pathName to SourceFile.path ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-13 Consider changing the name of SourceLocation ASTM 1.0b1 ASTM 1.0 Resolved closed
ASTM-12 Change multiplicity of EnumType.enumLiterals from 1..* (i.e., '+') to 0..* ASTM 1.0b1 ASTM 1.0 Resolved closed

Issues Descriptions

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

  • Key: ASTM-50
  • Legacy Issue Number: 12983
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 04:50 GMT

Section: Section 3.1.9, Figure 41

  • Key: ASTM-49
  • Legacy Issue Number: 12984
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

    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".

  • Reported: ASTM 1.0b1 — Thu, 23 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Section: 1.7 editorial

  • Key: ASTM-35
  • Legacy Issue Number: 12971
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page: botton of 19 Something is missing between "SAST" and "GAST".

  • Key: ASTM-34
  • Legacy Issue Number: 12970
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page: top of 19 Pluralize "model" in the second line

  • Key: ASTM-33
  • Legacy Issue Number: 12969
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    Pluralize "model" in the second line

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Section 3.1.9, Figure 34 - operators "Negate" and "Not"

  • Key: ASTM-32
  • Legacy Issue Number: 12965
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Section 3.1.6, Figure 19 - Introduce different FormalParameterDeclaration

  • Key: ASTM-31
  • Legacy Issue Number: 12964
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Section 3.1.9, Figure 41 - Introduce attribute "EvaluateAllCases" of type Boolean in the object "SwitchCase"

  • Key: ASTM-30
  • Legacy Issue Number: 12963
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Section 3.1.9 - Introduce the missing expression "CollectionExpression"

  • Key: ASTM-29
  • Legacy Issue Number: 12962
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Section 3.1.6, Fig. 20 - Introduce "EnumTypeDefinition" as a subclass of "TypeDefinition"

  • Key: ASTM-28
  • Legacy Issue Number: 12961
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Section 3.1.9, Fig. 38 - Introduce "EnumLiteral" as a subclass of "Literal"

  • Key: ASTM-27
  • Legacy Issue Number: 12960
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Section 3.1.4, Fig. 17 - CompilationUnit

  • Key: ASTM-26
  • Legacy Issue Number: 12959
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Section 3.1.6, Fig. 23: Association "file" between "IncludeUnit" and "SourceFile"

  • Key: ASTM-25
  • Legacy Issue Number: 12958
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

    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"

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Section 3.1.6, Figure 23

  • Key: ASTM-24
  • Legacy Issue Number: 12957
  • Status: closed  
  • Source: TCS ( Ravindra Naik)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent naming of FunctionMemberAttribute

  • Key: ASTM-23
  • Legacy Issue Number: 12613
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    Inconsistent naming of FunctionMemberAttribute. Sometimes called FunctionMemberAttributes

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change OpenScope to opensScope in footnote 12

  • Key: ASTM-22
  • Legacy Issue Number: 12612
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    Change OpenScope to opensScope in footnote 12

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Footnote 11 is not clear

  • Key: ASTM-21
  • Legacy Issue Number: 12611
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    Footnote 11 is not clear

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change the word OpenScope to opensScope in footnote 5

  • Key: ASTM-20
  • Legacy Issue Number: 12610
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    Change the word OpenScope to opensScope in footnote 5.

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

There is no Section 4.

  • Key: ASTM-48
  • Legacy Issue Number: 13079
  • Status: closed  
  • Source: The Software Revolution ( Philip Newcomb)
  • Summary:

    1.1 Overview of the ASTM Specification

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

  • Reported: ASTM 1.0b1 — Fri, 14 Nov 2008 05:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Table of Contents, Table of Figures and Tables

  • Key: ASTM-47
  • Legacy Issue Number: 13078
  • Status: closed  
  • Source: The Software Revolution ( Philip Newcomb)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Thu, 13 Nov 2008 05:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 5.8.4

  • Key: ASTM-46
  • Legacy Issue Number: 12982
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 5.8.2 The inclusion of "PureVirtual" as a "VirtualSpecification" is also C++-centric

  • Key: ASTM-45
  • Legacy Issue Number: 12981
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

  • Key: ASTM-44
  • Legacy Issue Number: 12980
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Thu, 23 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 5.8.3 attribute for "includedUnit" only works for C and C++

  • Key: ASTM-43
  • Legacy Issue Number: 12979
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

  • Key: ASTM-42
  • Legacy Issue Number: 12978
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 5.8.2 In DeclarationDefintion

  • Key: ASTM-41
  • Legacy Issue Number: 12977
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    "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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

  • Key: ASTM-40
  • Legacy Issue Number: 12976
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Doesn't "DataDefinition" need a type attribute?

  • Key: ASTM-39
  • Legacy Issue Number: 12975
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    Doesn't "DataDefinition" need a type attribute?

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 5.8 editorial issue

  • Key: ASTM-38
  • Legacy Issue Number: 12974
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 5.7 second para -- editorial issue

  • Key: ASTM-37
  • Legacy Issue Number: 12973
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page: botton of 19 section 5.2

  • Key: ASTM-36
  • Legacy Issue Number: 12972
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    First sentence: change "is" to "as“

  • Reported: ASTM 1.0b1 — Wed, 22 Oct 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Describe the behavior of BitRightShift.

  • Key: ASTM-4
  • Legacy Issue Number: 12594
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Describe the behavior of Modulus

  • Key: ASTM-3
  • Legacy Issue Number: 12593
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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)

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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).

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Describe the behavior of ConditionalExpression

  • Key: ASTM-2
  • Legacy Issue Number: 12592
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Describe behavior of BinaryExpression

  • Key: ASTM-1
  • Legacy Issue Number: 12591
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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
  • Updated: Fri, 6 Mar 2015 20:57 GMT

relative ordering of Float, Double and LongDouble

  • Key: ASTM-11
  • Legacy Issue Number: 12601
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

relative ordering of Character and WideCharacter

  • Key: ASTM-10
  • Legacy Issue Number: 12600
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

relative ordering of ShortInteger, Integer and LongInteger

  • Key: ASTM-9
  • Legacy Issue Number: 12599
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

  • Key: ASTM-8
  • Legacy Issue Number: 12598
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change multiplicity of FunctionDefinition.returnType

  • Key: ASTM-7
  • Legacy Issue Number: 12597
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Remove square brackets surrounding Scope.childScope

  • Key: ASTM-6
  • Legacy Issue Number: 12596
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add description of square brackets to ABNF Notation

  • Key: ASTM-5
  • Legacy Issue Number: 12595
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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".

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change the word before to after in the description of ForCheckAfterStatemen

  • Key: ASTM-19
  • Legacy Issue Number: 12609
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    Change the word before to after in the description of ForCheckAfterStatement

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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>.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change IntegerlLiteral to IntegerLiteral

  • Key: ASTM-18
  • Legacy Issue Number: 12608
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    Change IntegerlLiteral to IntegerLiteral

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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>.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Document version (1.3.2) does not match last entry in Revision History (1.6

  • Key: ASTM-17
  • Legacy Issue Number: 12607
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change ActualParameterE to ActualParameter

  • Key: ASTM-16
  • Legacy Issue Number: 12606
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    Change ActualParameterE to ActualParameter

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    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>.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Consider removing the attribute language from CompilationUnit

  • Key: ASTM-15
  • Legacy Issue Number: 12605
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No change is recommended in the specification

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Consider changing SourceFile.pathName to SourceFile.path

  • Key: ASTM-14
  • Legacy Issue Number: 12604
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Consider changing the name of SourceLocation

  • Key: ASTM-13
  • Legacy Issue Number: 12603
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

    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.

  • Reported: ASTM 1.0b1 — Mon, 28 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

  • Key: ASTM-12
  • Legacy Issue Number: 12602
  • Status: closed  
  • Source: Hewlett-Packard ( Faron Dutton)
  • Summary:

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

  • Reported: ASTM 1.0b1 — Sun, 27 Jul 2008 04:00 GMT
  • Disposition: Resolved — ASTM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT