Issues for Mailing list of the ADM Knowledge Discovery 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 9911: Section: 10.3, 10.4
Issue 9912: Section: 10.5
Issue 9965: Section: 11.3
Issue 9966: Section: 11.4
Issue 9967: Section: 9.4
Issue 9968: Section: 9.5
Issue 9969: Section: 9.7.1
Issue 9970: Section: 9.7.1 (issue # 2)
Issue 9971: Section: 12.5
Issue 9972: Section: 12.6.1
Issue 9973: Section: 12.6.6
Issue 9974: Section: 12.7
Issue 9975: Section: 12.7 (iisue # 2)
Issue 9976: Section: 12.8
Issue 9977: Section: 12.6
Issue 9978: Section: 12.8
Issue 9979: Section: 12.10
Issue 9980: Section: 12.10 (issue # 2)
Issue 9981: Section: 12.10 (issue # 3)
Issue 9982: Section: 12.10
Issue 9983: Section: 12.11
Issue 9984: Section: 12.11 (02)
Issue 9985: Section: 12.12
Issue 9986: Section: 12.12 (02)
Issue 9987: Section: 12.12-12.17
Issue 9988: Section: 12.16
Issue 9989: Section: 12.18
Issue 9990: Section: 9.6.1
Issue 9991: Section: 12.18
Issue 9992: Section: 12.21
Issue 9993: Section: 12.19-12.20
Issue 9994: Section: 9.6.1
Issue 9996: Section: 19 (02)
Issue 9998: Section: 19.6
Issue 10100: Section: 9.7
Issue 10102: Section: 12.17
Issue 10103: Section: 12,13
Issue 10104: Section: 12.9
Issue 10105: Section: 12.23
Issue 10106: Section: 12.24
Issue 10107: Section: 12
Issue 10108: Section: 12.14
Issue 10109: Section: 12.14
Issue 10110: Section: 11.4.1
Issue 10111: Section: 12.19
Issue 10115: Section: 9.7 page 23
Issue 10116: Section: 9.7 page 23 (TaggedValue)
Issue 10117: Section: 10.5 page 34
Issue 10118: Section: 12.13 page 59
Issue 10119: Section: 13 pages 75 - 95
Issue 10120: Section: 13.7 page 85
Issue 10121: Section: 13.7 page 85 Creates relationship
Issue 10122: Section: 13.3 page 76
Issue 10124: Section: 12.17 page 65
Issue 10125: Section: 15.3
Issue 10132: Section: 14
Issue 10136: Unnecessary abstract classes for relationships in Platform package
Issue 10137: Section: 19.11
Issue 10148: Section: 21.4
Issue 10149: Section: 22.4
Issue 10283: Section: 12.18
Issue 10284: Section: 12
Issue 10285: Section: 12 (02)
Issue 10286: Section: 12, page 41-74
Issue 10287: Section: 12, page 41-74 (02)
Issue 10289: Section: 12, page 41-74 (04)
Issue 10290: Section: 13.4
Issue 10292: Section: 17
Issue 10295: Section: 18
Issue 10296: Section: 18 pages 137 - 148
Issue 10298: Section: 18 pages 137 - 148 (03)
Issue 10299: Section: 18 pages 137 - 148 (04)
Issue 10300: Section: 18 pages 137 - 148 (05)
Issue 10301: Section: 18 pages 137 - 148 (06)
Issue 10302: Section: 18 pages 137 - 148 (07)
Issue 10303: Section: 18 pages 137 - 148 (08)
Issue 10304: Section: 18 pages 137 - 148 (09)
Issue 10305: Section: 18 pages 137 - 148 (10)
Issue 10307: Section: 20 pages 171 - 183
Issue 10308: Section: 20 pages 171 - 183 (02)
Issue 10309: Section: 19
Issue 10310: Section: 19 pages 149 - 169
Issue 10311: Section: 19 pages 149 - 169 (02)
Issue 10312: Section: 19 pages 149 - 169
Issue 10313: Section: 19 pages 149 - 169 (02)
Issue 10314: Section: 19 pages 149 - 169 (03)
Issue 10315: Section: 19 pages 149 - 169 (04)
Issue 10316: Section: 19 pages 149 - 169 (05)
Issue 10317: Section: 19 pages 149 - 169 (06)
Issue 10318: Section: 19 pages 149 - 169 (07)
Issue 10320: Section: 19 pages 149 - 169 (09)
Issue 10322: Section 93.
Issue 10323: Section: 9.6.1
Issue 10324: Section: 9
Issue 10325: Section: 10.3
Issue 10326: Section: 10.4
Issue 10327: Section: 10.4 page 32
Issue 10328: Section: 9
Issue 10329: Section: 12
Issue 10330: Section: 12.4
Issue 10331: Section: 12
Issue 10332: Section: 12.9
Issue 10333: Section: 12.13
Issue 10334: Section: 12.17
Issue 10335: Section: 13
Issue 10337: Section: 13
Issue 10338: Section: 17
Issue 10408: Section: 21.3
Issue 10412: Section: 9
Issue 10450: Insufficient specification of KDMAggregatedRelationship class
Issue 10451: Need additional attribute for SourceFile element to specify encoding
Issue 10452: Wrong text for 12.10.2 TemplateParameter Class
Issue 10453: Wrong text for DerivedTypeElement class
Issue 10454: Wrong text for ControlFlow class
Issue 10455: Wrong text for EntryFlow class
Issue 10456: Wrong text for ControlFlow class
Issue 10457: Wrong text for ControlFlow class (02)
Issue 10458: Wrong text for ControlFlow class (03)
Issue 10459: Wrong text for ControlFlow class (04)
Issue 10460: Missing specification detail for ControlFlow class
Issue 10461: Wrong text for CallableRelations class
Issue 10462: Wrong text for Calls class
Issue 10463: Wrong text for UsesCallable class
Issue 10464: Wrong text for DataRelation class
Issue 10465: Wrong text for PrototypeRelation class
Issue 10466: Section: 15.10
Issue 10468: Remove several remaining backward navigable links to groups
Issue 10652: Lack of fidelity for advance flow analysis
Issue 10653: Allow multiple SourceRef elements for a given Code element
Issue 10654: Missing attribute length for all StorableElements
Issue 10708: Make ValueElement a subclass of StorableElement
Issue 10709: Change name of attribute in Annotation from "note" to "text" to reflect sem
Issue 10710: ActionElements can not be added directly to CodeModel
Issue 10711: Allow ActionElement to own storable elements
Issue 10712: Make AggregatedRelationship a subclass of KDMRelationship
Issue 10713: Add optional kind attribute to StorableUnit VariableKind
Issue 10714: add type attribute to CallableUnit
Issue 10715: Remove prototype unit
Issue 10716: Rename CodeAssembly to Package
Issue 10730: StorableElement should be able to own actions
Issue 10767: Section: 10
Issue 10791: Section: 11
Issue 10792: Section: 13.6
Issue 10793: Section: 12
Issue 10794: Section: 12.8
Issue 10795: Section: 12
Issue 10796: Section: 10
Issue 10797: Section: 12

Issue 9911: Section: 10.3, 10.4 (kdm-ftf)

Missing example of KDM Framework as KDM Instance 

resolved, see ptc/2007-03-04 page 240 - 241

Missing example of usage of the Audit element

Discussion:
Illustrated in the KDM Framework example (issue 9911). Merged with 9911.
Disposition: Duplicate or merged

Missing example of SourceRef element as a KDM instance

Discussion:
Illustrated in the KDM HelloWorld example (issue 9977). Merged with 9977.
Disposition: Duplicate or merged

Missing example of SourceRegion element as a KDM instance. It would be good to illustrate alternative organization with and without the BuildModel for representing files, as well as various overrides for language attribute

Discussion:
Illustrated in the KDM Framework example (issue 9911). Merged with 9911.
Disposition: Duplicate or merged

KDM requires navigabable associations from KDMEntity to KDMRelationship (in the Core KDM these are named outbound and inbound, see Figure 9.2). While useful for certain type of cross-referencing queries (e.g. who is using the given entity), these associations make KDM instance XMI extremely inflexible and hard to modify (as information abut relations is essentially duplicated). It is better to eliminate these associations, and leave only the from and to associations in the KDMRelationship element. The outbound and inbound associations can be changed into operations, or implemented internally by particular KDM tools, if needed.

resolved see ptc/2007-03-04 page 71 - 96 for details

KDM requires navigabable associations from KDMEntity to KDMAggregatedRelationship (in the Core KDM these are named inAggregated and outAggregated, see Figure 9.3). While useful for certain type of cross-referencing queries (e.g. who is using the given entity), these associations make KDM instance XMI extremely inflexible and hard to modify (as information abut relations is essentially duplicated). It is better to eliminate these associations, and leave only the from and to associations in the KDMAggregatedRelationship element. The inAggregated and outAggregated associations can be changed into operations, or implemented internally by particular KDM tools, if needed.

resolved see ptc/2007-03-04 page 43/44 for deails

Missing example of KDM Stereotype as KDM instance (with tag definitions, as part of an Extension family).

resolved, see ptc/2007-03-04, page 356 - 357

KDM requires a named association from Stereotype to the ModelElement (called extendedElement in Figure 9.5). While useful for certain cross-referencing queries (usage of a given stereotype), this feature makes KDM instance XMI very inflexible and complicated (as information is essentially duplicated). Suggestion to define this as an operation, or remove to be implemented internally to KDM tools, if needed

resolved see ptc/2007-03-04 page 45/46 for deails

KDM defines unnecessary abstract classes for relations, for example, CodeRelationship, PrototypeRelationship, Interfacerelationship, TypeRelationship, TemplateRelationship (figure 12.3). This is a consistent pattern, repreated at other packages. The intention was to provide additional extension points, however, these relationships are defined as abstract classes, so they cannot be instanciated. They cannot be made concrete either for the reasons of compatibility with EMF. They make the metamodel unnecessary complex without adding any value. They do not affect the KDM instance XMI. The suggestion is to simplify the metamodel by removing these unnecessary relations. This suggestion was also given by ASG representative.

KDM can be improved by eliminating several unnecessary abstract classes, that are
defined as subclasses of CodeRelationship at diagram CodeRelations. Several other
diagrams need to be corrected. As the result, the diagram CodeRelations becomes
redundant, so the CodeRelations element can be moved into the CodeInheritances
diagram. The only needed abstract subclasses of KDMRelationship are those that are
used to represent ownership of relations, such as CodeRelationship.
This change does not affect the KDM XMI.
Delete CodeRelations class diagram (Figure 12.3).
Delete section 12.5, page 46-47.
Modify CodeInheritances class diagram (Figure 12.1) by moving CodeRelationship class
into it (changes are indicated by red color):    (Added text is indicated by underlining)
Add “CodeRelationship” into the list of classes defined at the CodeModel diagram
(section 12.4 page 42, after CodeElement item):
.. CodeRelationship – a class representing an abstract parent for all KDM
relationships that can be used to model code.
Add new section after section 12.4.2 CodeElement, describing CodeRelationship class
(as it was moved from CodeRelations diagram to CodeInheritances diagram):
12.4.3. CodeRelationship Class (abstract)
The CodeRelationship is an abstract class representing any relationship determined by a
programming language.
Superclass
KDMRelationship
Constraints
Semantics CodeRelationship is an abstract class that is used to constrain the subclasses of
KDMRelationship in the Code model.Modify Prototype class diagram (Figure 12.6 page 51) to change PrototypeRelations into
CodeRelationship (changes are indicated by red color):
Modify superclass of PrototypedBy class in the text (section 12.8.2, page 52):
Superclass
CodeRelationship
Modify TemplateRelations class diagram (Figure 12.9, page 56) to change
TemplateRelationship into CodeRelationship: Modify superclass of Instantiates class in the text (section 12.11.1, page 56):
Superclass
CodeRelationship
Modify superclass of InstanceOf class in the text (section 12.11.2, page 56):
Superclass
CodeRelationship
Modify InterfaceRelations class diagram (Figure 12.18, page 68) to change
InterfaceRelationship into CodeRelationship: Modify superclass of Implements class in the text (section 12.20.1, page 68):
Superclass
CodeRelationship
Modify superclass of ImplementationOf class in the text (section 12.20.2, page 69):
Superclass
CodeRelationship
Modify TypeRelations class diagram (Figure 12.19, page 70) to change TypeRelationship
into CodeRelationship: Modify superclass of HasType class in the text (section 12.21.1, page 70):
Superclass
CodeRelationship
Modify ClassRelations class diagram (Figure 12.20, page 71) to change
TypeRelationship into CodeRelationship: Modify superclass of Extends class in the text (section 12.22.1, page 72):
Superclass
CodeRelationship
Modify Visiblity class diagram (Figure 12.22, page 73) to change PrototypeRelationship
into CodeRelationship: Modify superclass of VisibleIn class in the text (section 12.24.1, page 74):
Superclass
CodeRelationship
Modify PrototypeRelations class diagram in the Action package (Figure 13.6, page 90) to
change PrototypeRelationship into CodeRelationship: Modify superclass of UsesPrototype class in the text (section 13.18.1, page 90):
Superclass
CodeRelationship
Modify TypeRelations class diagram in the Action package (Figure 13.8, page 93) to
change TypeRelationship into CodeRelationship: Modify superclass of UsesType class in the text (section 13.10.1, page 93):
Superclass
CodeRelationship
Modify TypeRelations class diagram in the Action package (Figure 13.8, page 93) to
change TypeRelationship into CodeRelationship: Modify superclass of Imports class in the text (section 13.9.2, page 92):
Superclass
CodeRelationship
Modify MacroRelations class diagram in the Action package (Figure 13.9, page 94) to
change MacroRelationship into CodeRelationship:  Modify superclass of Expands class in the text (section 13.11.1, page 94):
Superclass
CodeRelationship
Modify PlatformInterfaces class diagram in the Platform package (Figure 19.6, page 158)
to change InterfaceRelationship into PlatformRelationship (since InterfaceRelationship
has been removed): Modify superclass of CompliesTo class in the text (section 19.8.1, page 158):
Superclass
PlatformRelationship
Modify EventRelations class diagram in the Events package (Figure 17.4, page 133) to
change MacroRelationship into CodeRelationship: Modify superclass of HasSignature class in the text (section 13.11.1, page 94):
Superclass
EventRelationship

KDM text mentions incorrect superclass for CallableUnit, BlockUnit, MethodUnit, (KDM text describes this a CodeElement, while it is in fact CallableElement, as defined in Figure 12.4).

(Changed text indicated by underlining)
Pg. 48, section 12.6.2 CallableUnit class
Superclass
CallableElement
Pg.49, section 12.6.3 BlockUnit class
Superclass
CallableElement
Pg/ 49, section 12.6.4 MethodUnit Class
Superclass
CallableElement

KDM defines OperatorUnit as a special subclass of CallableElement, together with CallableUnit, BlockUnit, MethodUnit and ConstructorUnit. There is little value in this element compared to a regular CallableUnit or a MethodUnit. The difference seems more syntactic. Suggestion - to eliminate this element in order to simplify the metamodel.

The intention of KDM is to represent behavior and dependencies, especially across
compilation units. KDM is more about functionality than about syntax.
The rationale of CallableElement family and the corresponding action relations (like
Calls, Invokes, Uses, etc.) is to:
- represent dependency between containers
- provide the capability to track scenarios through calls
- identify packaging at the to-endpoint (what is being invoked)
- identify the ways how things are being invoked (at the from-endpoint)
Based on this, the current design is not balanced, as it provides too much differentiation
for the to-endpoint (in particular, there are special entities for Methods, Constructors and
Operators), but is generic enough at the from-endpoint (in particular, there are no entities
for various invocation kinds, like procedure calls, function call inside and expression,
constructor call, destructor call, and operator call).
According to the general guidelines, we decided to resolve the issue by reducing the
variation at the to-endpoint from OperatorUnit, ConstructorUnit and MethodUnit to
simply MethodUnit with an additional attribute to distinguish between regular methods,
constructors, destructors, and operators.
Related issues are 9976 (PrototypeUnit should be able to be owned by ClassUnit) and
10102 (ClassUnit should be flattened).
Changes:
Modify CallableUnits class diagram (Figure 12.4, page 48) by removing classes
OperatorUnit and ConstructorUnit, and adding an attribute “kind:MethodKind” to
MethodUnit and new enumeration MethodKind:    Delete sections 12.6.5 and 12.6.6. (page 49).
Add text describing the attribute “kind:MethodKind” to section 12.6.4, page 49:
The MethodUnit represents member functions owned by a ClassUnit, including userdefined
operators, constructors and destructors.
Attributes
kind:MethodKind Indicator of the kind of the method represented by this element
Add section describing enumeration MethodKind after section 12.6.4:
12.6.5. MethodKind (enumeration)
MethodKind enumeration defines additional specification of the kind of method, defined
by a MethodUnit model element.
Literal Values
method the MethodUnit represents a regular member function
constructor the MethodUnit represents a constructor destructor the MethodUnit represents a destructor
operator the MethodUnit represents an operator
unknown the kind of the MethodUnit is none of the above
Modify ClassTypes class diagram (Figure 12.15, page 65) by removing references to
classes OperatorUnit and ConstructorUnit

KDM defines Module (and its subclasses) as a subclass of CodeContainer, which means they inherit SourceRef association. However, this element is not defined at this level. It is only applicable to individual elemetns inside the Module.

Discussion:
Add semantic constraint to the Module element that it cannot have a SourceRef element.
Add constraint to section 12.7.1:
Constraints
.. Module class and its subclasses should not own SourceRef elements
Disposition: Resolved

KDM defines Module (and its subclasses) as a subclass of CodeContainer, which does not enforce that semantically all individual code elements are supposed to be owned by some module. Suggestion - change the inheritance hierarchy Figure 12.5 and 12.2

resolved see ptc/2007-03-04 page 158 - 160 for details

KDM defines PrototypeUnit as CodeResource. However it should be moved into the TypeElement hierarch, so that it can be owned by ClassUnits. Figure 12.6

resolved see ptc/2007-03-04 page 34 for deails

Missing examples of various CallableElements as KDM instances

resolved, see ptc/2007-03-04 page 242 - 243

Missing examples of PrototypeUnit and its usages as KDM instance

Discussion:
Illustrated in the KDM data type examples (issue 9987). Merged with 9987.
Disposition: Duplicate or merged

KDM defines TemplateParameter as a subclass of CodeResource, but it should be a subclass of TypeElement in order to get correct usage relations. Figure 12.8. 

resolved see ptc/2007-03-04 page 35 for deails

Association templateElement between TemplateUnit and CodeResource at Figure 12.8. is too general. It says 0..*, but TemplateUnit can contain a single class or method. 

resolved see ptc/2007-03-04 page 36 for deails

TemplateParameterowned by TemplateUnit should be ordered

resolved see ptc/2007-03-04 page 37 for deails

Missing example of a TemplateUnit for class and method as KDM instance. Related to Figure 12.8

resolved, see ptc/2007-03-04, page 349 - 353

Element TemplateInstance is redundant, as TemplateUnit can contain only a single class or method. The instance of the template therefore consists of that class or method (properly instanciated), and no additinal housekeeping is required. The instance can be the endpoint for the "Instantiates" relation. Suggestion - remove this element to simplify the metamodel, and correct model for instantiates relation to go from CodeResource to TemplateUnit at Figure 12.9. This also elimintaes the need to distinguish between InstanceOf and Instanciates relationships. Relationship InstanceOf can be elimitated to further simplify the metamodel.

resolved see ptc/2007-03-04 page 38/39 for deails

Element TemplateInstance is redundant, as TemplateUnit can contain only a single class or method. The instance of the template therefore consists of that class or method (properly instanciated), and no additinal housekeeping is required. The instance can be the endpoint for the "Instantiates" relation. Suggestion - remove this element to simplify the metamodel, and correct model for instantiates relation to go from CodeResource to TemplateUnit at Figure 12.9. This also elimintaes the need to distinguish between InstanceOf and Instanciates relationships. Relationship InstanceOf can be elimitated to further simplify the metamodel

Missing general description of type representation in KDM, embracing sections 12.12-12.22

Discussion:
Add the following text:
Data item representation of KDM is aligned with ISO/IEC 11404 (Language-Independent
datatypes) standard. KDM provides distinct meta-model elements for “data items” (for example,
global and local variables, constants, record fields, parameters, class members, array items and
pointer base elements) and “datatypes”. Each data item has an association “type” to its datatype.
KDM distinguishes primitive datatypes (for example integer, Boolean), complex user-defined
datatypes (for example, array, pointer, sequence) and named datatypes (for example, a class, a
synonym type). KDM meta-model elements corresponding to datatypes are subclasses of a
generic class Datatype. KDM meta-model elements corresponding to data items are subclasses
of a generic class StorableElement.
KDM model elements represent existing artifacts determined by a programming language. KDM
meta-model elements provide sufficient coverage for most common datatypes and data items,
common to programming languages. KDM also provides several powerful generic extensible
elements that can be further used with stereotypes to represent uncommon situations.
In addition to the type association, KDM relationship “HasType” is used to track named data
types. Anonymous data types are owned by the data item that uses it.
Concrete examples of datatypes, data items and the use of the type association and the HasType
relationship are provided further in the text of the specification.
Disposition: Resolved

Need new subclass of DerivedTypeElement to represent "synonym types", for example, in C: typedef int x; 

This issue is resolved as part of the resolution to issue 9994 by introducing the so-called
DefinedTypes.
Disposition: Duplicate or merged

Missing examples of data types and their representations as KDM instances

resolved, see ptc/2007-03-04 page 244 - 254

CompositeTypeElement should own an ordered list of fields. {ordered} is now missing in Figure 12.14

This is an oversight. The text of the specification mentions that both
CompositeUnit and UnionUnit define an “ordered collection” of types (fields and
variants, respectively).
Pg. 64, Figure 12.14 (changes indicated using a red pen)
Pg. 64, section 12.16.1 (added text is underlined)
Associations
Field:TypeElement[0..*] {ordered}
Disposition: Resolved

Signature should have an (optional) association to the returned type, instead of ownership, since returned types are defiend elsewhere, and signature does not define a special name for it.

Discussion:
This issue is resolved as part of the resolution to a more general issue 9994 related to
representation of data items and distinction between data items (like variables) and data
types. In the resolution to 9994, formal parameter of a signature have uniform references
to their corresponding datatypes, instead of ownership.
Disposition: Duplicate or merged

Move InstanceKind enumeration data type from Core package to Code package, since it is only used in Code package. This will simplify development of class factories per each package.

resolved see ptc/2007-03-04 page 40 - 42 for deails

Missing example of CallableElements and their Signatures as KDM instance, illustrating corresponding KDM relations.

Discussion:
Illustrated in the KDM data type examples (issue 9987). Merged with 9987.
Disposition: Duplicate or merged

Missing example of HasType relation as KDM instance

Discussion:
Illustrated in the KDM data type examples (issue 9987). Merged with 9987.
Disposition: Duplicate or merged

Missing example of Interface and corresponding relations as KDM instance

resolved, see ptc/2007-03-04, page 354 - 355

Representation of data types and storable elements in KDM (aka "compressed data type representation") has a disadvantage: it is difficult to implement a query that lists all variables in a Code Model. KDM does not explicitly represent varibles. Instead, it represented various typeUnits with a additional kind attribute (of InstanceKind data type) that distinguishes for example, global variable, local variables, fields of a record, members of a class, formal parameters of a procedure, etc. In order to get the list of variables, one needs to iterate over all subtypes of a TypeElement (quite a few), and check the kind attribute. Suggestion: to "uncompress" the representation a little, by introducing an explicit StorableUnit element with attribute type that provides a reference to the corresponding type. This will still satisfy most of the goals of the "compressed representation", for example, low cost of representing complex derived types, and not tracking usages to predefined types through KDM relations (only relations to NamedTypes). This suggestion originates from an external reviewer, who is implementing KDM.

resolved see ptc/2007-03-04 page 169 - 194 for details

Need to relate platform activations and bindings to UI triggers

Discussion:
This issue is a duplicate of 10310. It refers to the same submitters issue id 2610200507.
Disposition: Duplicate or merged

DataResource is the same as DataManager, Figure 19.4

resolved, see ptc/2007-03-04 page 321 - 328

Move Extension and Annaotation diagrams from Core to Kdm package. Management of KDM packages can be optimized, if the Extension and Annotations diagrams are moved from the Core package into the Kdm package. This way, the Core package will contain abstract classes that define the meta-level facilties of KDM, and determine the meta-level API to KDM instances. The Kdm package, on the other hand, will contain concrete classes that are part of each KDM instance.

This change rationalizes the use of KDM packages, and does not affect the KDM XMI.
Move diagram, represented at Figure 9.5 at page 23 (classes KDMExtensionFamily,
Stereotype, TaggedValue, TagDefinition) and diagram, corresponding to Figure 9.6, page
26 (classes Attribute and Annotation) from Core package to kdm package.
Move section 9.7 after section 10.5. Move section 9.8 at the end of chapter 10.

Definition of ClassUnit should be flattened. Definition of ClassUnit (Figure 12.15) should be flattened, so that ClassUnit contains a single association to CodeResource. This will make Classunit more generic, for example, allow to use PrototypeUnit as a contained element, and will allow to make contents of ClassUnit ordered

resolved see ptc/2007-03-04 page 47/48 for deails

Improve encapsulation of KDM models by associating KDM relationships with the from-endpoint. Encapsulation of KDM models can be improved by placing most KDM relationships into the elements that are the from-endpoints of these relationships, instead of associating these relationships with the whole model. Particularly, ActionRelationships should be owned by ActionElements; CodeRelationships should be owned by CallableElements. Currently, only FlowRelationships follow this principle (they are already owned by CallableElements). This will significantly reduce the number of KDM relationships that are contained directly by the each KDM model. The proposed revision will dramatically improve the readability of KDM instances in XMI (otherwise, each model is "flooded" by a flat set of KDM relationships). 

resolved see ptc/2007-03-04 page 100 - 110 for details

Missing example of MacroUnit and its usages in section 12.9 

resolved, see ptc/2007-03-04, page 341 - 346

Missing example of CommentUnit and its usages in section 12.23 

resolved, see ptc/2007-03-04, page 347 - 348

Missing example of Visibility relationship in section 12.24 

Discussion:
Example is merged with Comments (see issue 10105).
Disposition: Duplicate or merged

Need special modeling element to represent initialization of data items. Currently there is no special special modeling element for initialization. This can be represented by ActionElements and Initializaes relationship. However, this solution proves to be not particularly readable and rather verbose. Introducing a special element for initialization will improve readability of KDM XMI instances. 

This is resolved as part of the resolution to issue 9994
Disposition: Duplicate or merged

Need special attribute to ArrayUnit to represent the size of the array. Currently there is no special special modeling element for representing size of the array as it may be declared in the existing source code artifact. This gap has to be mitigated, for example, by introducing a special attribute for representing the size of the array. This information is required in several queries against KDM models and is required for transformations of existing systems. 

Discussion:
This issue is resolved as part of the resolution to issue 9994.
Disposition: Duplicate or merged

Need special attribute to RefinementUnit to represent the actual refinement. Currently there is no special special modeling element for representing the actual refinement of a data type (for example, the actual range in Ada) as it may be declared in the existing source code artifact. This gap has to be mitigated, for example, by introducing a special attribute for representing the refinement in RefinementUnit. This information is required in several queries against KDM models and is required for transformations of existing systems. 

Discussion:
This issue is resolved as part of the resolution to issue 9994.
Disposition: Duplicate or merged

Missing description of additional properties for SourceRef in SourceRegion diagram Section 11.4.1. SourceRegion class Diagram misses description of additional properties that are defined for class SourceRef (association from SourceRef to SourceRegions). 

Add section 11.4.2 SourceRef (additional properties)
11.4.2 SourceRef (additional properties)
This association links a particular SourceRef element to the list of SourceRegion elements,
Associations
region:SourceRegion[0..*] {ordered} The list of SourceRegion elements that provide the physical
links to portions of the source code, corresponding to the SourceRef.
Semantics

Rename Interface class to InterfaceUnit. Section 12.19, page 67 defines class Interface. However the rest of the specification uses suffix xxxUnit for concrete model elements. Suggestion to rename Interface to InterfaceUnit

resolved see ptc/2007-03-04 page 50/51 for deails

Allow multiple stereotypes for ModelElement Currently Figure 9.5 allow not more than one stereotype to be associated with each ModelElement. It is more convenient to have multiple stereotypes, so that extension can be split. This will avoid duplication in defining extensions. To resolve, corresponding multiplicty has to be changed from 0..1 to 0..* 

resolved see ptc/2007-03-04 page 52 for details

Allow TaggedValue that can refer to other KDM ModelElements Currently Figure 9.5 allow only TaggedValues with a String value. For some extensions it is convenient to add TaggedValues that contain a reference to other ModelElements. Resolution suggestion: introduce a supertype with two sublclasses, one - current TaggedValue with String value, another one, for example TaggedRef, with an association to ModelElement

resolved see ptc/2007-03-04 page 161 - 163 for details

Typo in the attribute author of Audit class Spelled "duthor" instead of "author" 

resolved see ptc/2007-03-04 page 53 for details

Need to add void type to PredefinedTypeElement. This is needed to represent C/C++ casting to void*, and also will make signature more uniform 

resolved see ptc/2007-03-04 page 53 for details

Merge UsesType, UsesCallable and UsesData into a single more generic relationship Uses. This relationship is sufficient for tracking dependencies between components, without making fine distinction between the exact semantics of the usage, which can be further derived from the kind of the entity at the to-endpoint. There is not need to duplicate this information in the kind of the relationship

resolved see ptc/2007-03-04 page 118 - 120 for details

Destroys relationship is not needed since it is simply a call to a destructor method. It should be removed from Figure 13.5 

This is the consequence of consolidating constructors and regular methods. Now there is no need
for a special relation to a destructor. A regular Calls relation should be used instead.
Remove class “Destroys” from Figure 13.5, page 88. (See diagram in proposed resolution for
issue 10121).
Remove section 13.7.5 Destroys class, page 90.
Disposition: Resolved

Creates relationship is is a relationship to a TypeElement (ClassUnit), rather than to a variable of that class. This is also different from the call to a particular constructor of that class. Example (C++): A x=new A(1); Pseudo KDM (ClassUnit name="A" id=id0 MethodUnit name="A" id=id3)) (IntegerUnit name="1" kind=constant id=id1) (NamedClassUnit name="x" kind=variable id=id4) (HasType from=id4 to=id0) (ActionElement id=id2) (Creates from=id2 to=id0) (Reads from=id2 to=id1) (Calls from=id2 t=id3) (Writes from=id2 to=id4) 

resolved see ptc/2007-03-04 page 57-58 for details

Unnecessary abstract classes for relationships in Action package. Action package defines 4 unnecessary asbstract relationships: CallableRelationship, MacroRelationship, ImportRelationship and DataRelationship. Originally they were introduced as potential extension hotspots, but later they were made abstract because of the overall KDM pattern and CMOF, so they are now completely redundant. Removing them will simplify KDM. This does not affect existing KDM XMI. Recommendation to promote CallableRelationship and DataRelationship to ActionRelationship and other two - to CodeRelationship (with the possibility for their from-endpoint to own them in order to achieve better encapsulation of the model). 

resolved see ptc/2007-03-04 page 59 -  61 for details

Need better support for virtual methods. Recommendation: special call action and a special MethodKind 

resolved see ptc/2007-03-04 page 164 for details

abstract element ProgramElement should be subclassed by DataElement and CodeElement (rather than only CodeResource), since it is necessary to allow ActionElement to be included into definition of ConceptualGroup 

resolved see ptc/2007-03-04 page 62 - 63 for details

Missing example(s) for the Build package illustrating extraction of various elements and their representation as KDM XMI instances

Discussion:
Example is provided as part of the resolution to issue 10179
Disposition: Duplicate or merged

Unnecessary abstract classes for relationships in Platform package. Platform package defines 3 unnecessary abstract classes for KDM relationships: TechnologyRelationship, ExternalRelationship and ResourceRelationship. Originally, these classes were introduced as potential extension hotspots. However they are required to be abstract, so they became unnecessary. Recommendation: to remove these unnecessary classes to simplity the KDM metamodel. This does not affect KDM XMI. Usages of these relationships should be promoted to PlatformRelationship class.

resolved see ptc/2007-03-04 page 64 - 69 for details

Missing description of the class UsesResource in section 19.11 (correspondign to Figure 19.9

Add section between 19.11.6 and 19.11.7:
19.11.7. UsesResource Class
UsesResource relationship is a met-model element that represents various platform-specific
relations between platform services and individual resource instances.
Superclass
PlatformRelationship
Associations
from:PlatfromService[1]
to:ResourceInstance[1]
Constraints
Semantics
Disposition: Resolved

Inability to create relationships between ConceptualElements. This issue manifests itself in a context of transferring information from a code mining tool to a rules management (analysis) tool. Mining tool has information on mapping (e.g. based on computational dependency) between ConceptualElements (i.e. TermUnits and FactUnits). This is vital information for an analyst working with rules management tool that helps to determine whether a specific TermUnit or FactUnit has business significance and to define the correspondent Term or Fact in the Business Rules Model. However, KDM does not provide means to define a relationship between ConceptualElements. 

Discussion:
Merged with issue 10149.
Disposition: Duplicate or merged

Inability to create relationships between BehaviorElements and ConceptualElements. This issue manifests itself in a context of transferring information from a code mining tool to a rules management (analysis) tool. Mining tool has information on mapping from BehaviorElement (e.g. RuleUnit) to ConceptualElements (i.e. TermUnits and FactUnits). This is vital information for an analyst working with rules management tool that helps to determine whether a specific RuleUnit has business significance and to define the correspondent Rule in the Business Rules Model. However, KDM does not provide simple means to define a relationship between BehaviorElements and ConceptualElements. 

resolved, see ptc/2007-03-04 page 267 - 279

Issue 0510200504 for submitters database Originally raised by Larry Hines (EDS) Distinguish parameter passing variants Add attributes to Signature parameters, like ParameterKind with values ByName, ByValue. This will provide a capability to distinguish various forms of parameter passing. 

Discussion:
This issue has been resolved as part of the resolution for the issue 9994. Special
StorableElement called ParameterUnit was introduced to represent formal parameters of
signatures. It has a kind attribute with type enumeration ParameterKind (byname,
byValue, byReference, return).
Disposition: Duplicate or merged

Issue 0308200503 from submitters database Originally raised by Mike Smith (EDS) Add a general "depends" relationship between two CodeEntities

This issue is merged with 10330 and 10322 and the resolution will be provided in 10322.

Issue 1309200505 from submitters database Originally raised by Nick Mansourov consistency of models wrt source ref in case of macros (links to fully expanded macro and source of macros). 

resolved, see ptc/2007-03-04 page 257 - 266

Issue 2009200501 from submitters database Originally raised by Nick Mansourov representation of variants (conditional compilation

Discussion:
The resolution to this issue is consolidated with the resolution to issue 10285.
Disposition: Duplicate or merged

Issue 0602200602 from submitters database Originally raised by Adam Neal (Klocwork) Role names "class", 'interface' and 'package' are reserved Java keywords. They introduce conflicts during JMI generation 

Discussion:
This issue has been already resolved in KDM 1.0.
Disposition: Closed, no change

Issue 1703200603 from submitters database Originally raised by Nick Mansourov Review the semantics and usages of CodeGroup. Missing examples of the usage of CodeGroup. 

resolved see ptc/2007-03-04 page 132 - 133 for details

Issue 0302200602 from submitters database Originally raised by Nick Mansourov Action Containers are missing

resolved see ptc/2007-03-04 page 134 - 135 for details

Issue 1410200505 from submitters database Originally raised by Nick Mansourov introduce precise actions for triggering

resolved, see ptc/2007-03-04 page 314 - 320

Issue 1410200504 from submitters database Originally raised by Nick Mansourov introduce precise actions for UI 

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the UI package will have
more clear Resources and ResourceActions, with a clear separation from the Program Elements
layer. Resolution to this issue is provided in the consolidated issue 10301
Disposition: Duplicate or merged

Issue 1703200601 from submitters database Originally raised by Nick Mansourov DisplayUnits should be groups for Triggers 

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10301
Disposition: Duplicate or merged

Issue 1703200604 from submitters database Originally raised by Pete Rivett (Adaptive) UIContainer should be a Group for triggers

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10301
Disposition: Duplicate or merged

Issue 1703200605 from submitters database Originally raised by Nick Mansourov Change CallableElement to ActionElement in Displays relation in UI package

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10301.
Disposition: Duplicate or merged

Issue 1703200606 from submitters database Originally raised by Nick Mansourov Add capability to represent receiving data from DisplayUnits

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10301.
Disposition: Duplicate or merged

Issue 1703200607 from submitters database Originally raised by Nick Mansourov Endpoint of Displays relation is like a resource instance in Platform; needs review

resolved, see ptc/2007-03-04 page 308 - 313

Issue 1703200610 from submitters database Originally raised by Nick Mansourov Consider DisplayUnit as a group for its data, rather than a relationship to data: in BMS the data definition is autogenerated as a copybook, with two parts, one suffixed with "I" for input and another - with "O" for output; In Visual Basic Control elements are objects with data fields In Web there is a JavaBean 

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10301.
Disposition: Duplicate or merged

Issue 1903200605 from submitters database Originally raised by Nick Mansourov UI package should define its own Event UIEvent

Discussion:
This was already achieved in the KDM 1.0
Disposition: Closed, no action

Issue 2103200601 from submitters database Originally raised by Nick Mansourov UI package should define actions corresponding to UI things

Discussion:
This issue is a duplicate of issue 10295.
Disposition: Duplicate or merged

Issue 2103200602 from submitters database Originally raised by Nick Mansourov UI package should define code elements corresponding to UI things 

Discussion:
This issue is a duplicate of the issue 10295
Disposition: Duplicate or merged

Issue 1211200508 from submitters database Originally raised by Nick Mansourov Review role names for Machine and DeployedComponent and DeployedResource, and the need for backward navigability

Discussion:
As the result of the L1 resource layer reform, the Runtime package was merged with the Platform
package. This issue is resolved as part of the resolution to the issue 10310. As the result of the
unification of L1 packages based on the common L1 resource pattern, the Runtime package
became very similar to the Platform package. As the result of the merger, the representation of
the situations involving both the platform resources and the runtime deployment, becase more
straightforward. The combined platform/runtime package now has clear Resources and
ResourceActions, with a clear separation from the Program Elements layer.
See resolution to issue 10310.
Disposition: Duplicate or merged

Issue 1211200517 from submitters database Originally raised by Nick Mansourov Rename RunTimeRelations to RunTimeRelationship so that its name is uniform with other generic relation elements

Discussion:
This issue has been already resolved in KDM 1.0.
Disposition: Closed, no change

Issue 0410200501 from submitters database Originally raised by Mike Smith (EDS) Environment relations should be related to triggers, dataports, etc.

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10310.
Disposition: Duplicate or merged

Issue 2610200507 from submitters database Originally raised by Howard Hess (IBM) relate platform activations and bindings to UI triggers This is similar to issue 1901200601 review platform element as a special form of binding; maybe need a more generic mechanism to support integration of models. 

resolved, see ptc/2007-03-04 page 296 - 307

Issue 3110200504 from submitters database Originally raised by Nick Mansourov DataManager is a deployment resource. Should it be moved to RunTime view? Missing association to Data model elements 

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10310.
Disposition: Duplicate or merged

Issue 1211200501 from submitters database Originally raised by Nick Mansourov Review backward navigation from ResourceInstance to ResourceElement 

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10310.
Disposition: Duplicate or merged

Issue 1211200502 from submitters database Originally raised by Nick Mansourov Optional ownership of ResourceElement & ResourceInstance by ResourceType

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10310.
Disposition: Duplicate or merged

Issue 1211200506 from submitters database Originally raised by Nick Mansourov inverse platform activations relations

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10310.
Disposition: Duplicate or merged

Issue 1211200523 from submitters database Originally raised by Nick Mansourov Consider renaming PlatfromRelations to ResourceRelation

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10310.
Disposition: Duplicate or merged

Issue 1903200602 from submitters database Originally raised by Nick Mansourov relation or group association from external actor to triggers

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10310.
Disposition: Duplicate or merged

Issues 1211200518,1211200519,1211200520 from submitters database Originally raised by Nick Mansourov Rename Activation to ActivationService Rename Registration to NamingService Rename MarshalledCall to MarshalledService

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10310.
Disposition: Duplicate or merged

Issue 1211200521 from submitters database Originally raised by Nick Mansourov Introduce strongly typed MarshalledCall relation between MarshalledService and instance of MarshalledResource

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10310.
Disposition: Duplicate or merged

Issue 1910200501 from submitters database Originally raised by Nick Mansourov Need to perform unification of triggers and platform bindings

Discussion:
This issue is a duplicate of the issue 10310.
Disposition: Duplicate or merged

Suggestion to make diagram at figure 9.1 more "balanced" (mutually exclusive subtypes) by introducing an extra subclass "KDMElement" as a subtype of KDMEntity and changing other diagrams accordingly

resolved see ptc/2007-03-04 page 195 - 211 for details

add more elements to the InstanceKind: -member -signature -unknown

Discussion:
This issue is made obsolete as the InstanceKind is removed due to a new representation
of the data items, described in the resolution to issue 9994.
Disposition: Duplicate or merged

Add an entity id into the Core model, to be used in reasoning about KDM entities, for example, to make a statement that two variables are the same

Discussion:
Management of the identity of the model elements is an implementation concern.
Disposition: Closed, no change

Move association "Segements" from Root to ModelRoot, so that Segements can contain Segments, and kdm framework is more flexible.

resolved see ptc/2007-03-04 page 165 for details

Try to decouple kdm package from other packages, for example by introducing "extensible" kdm model and removing explicit associations with models. Complexity of queries needs to be taken into consideration

Discussion:
Explicit KDM models determine queries to KDM models and is essential for efficient
management of models. Introducing “reflection” will make queries more complex.
Disposition: Closed, no change

Add capability to add Stereotypes to Models (currently, Stereotypes can only be added to ModelElements, not to Elements, since ModelElements represent artifacts of existing systems, and Elements are part of the metamodel infrastructure).

Discussion:
This issue is merged with related issue 10325 (other modifications to the Framework
diagram). Resolution to issue 10327 consists of direct ownership of KDMModel by
KDMSegments and change of the superclass of the KDMFramework from Element to
ModelElement to allow stereotypes to KDMModels and KDMSegments.
Disposition: Duplicate or merged

Need generic extensible entity and relationship. Currently, this is somewhat limited because of abstract classes tat can not be instanciated. 

resolved see ptc/2007-03-04 page 98 - 99 for details

Add model elements to represent exceptions (try blocks, exception types, catch with formal parameters, throw), for example in Java and in C++. 

resolved, see ptc/2007-03-04 page 229 - 234

CodeContainer is redundant, since it can not be instanciated

This issue is merged with 10330 and 10322 and the resolution will be provided in 10322.

Missing {ordered} specifications for some elements, such as CodelElement in CallableElement, in MacroUnit; TemplateParameters, EnumeratedLiterals in EnumeratedUnit, ActionRelations, fields in CompositeUnit, all members in ClassUnit 

resolved see ptc/2007-03-04 page 113 - 117 for details

Missing parameters to the MacroUnit

Discussion:
This information has not been included into the adopted specification. We did not address any
relations between the macro arguments and their replacement code. We don’t recall ever needing
this information. When the macro expansion is processed, we obviously have to do the
replacements and we are temporarily aware of this relation, but we do not know any situations,
when this information has been used for any further analysis.
Disposition: Closed, no change

Consider adding a special extensibility attrbiute to Predefined classes (since they have to be extended in most cases by adding more precise language specific constraints). This will be a shortcut to adding a Stereotype

Discussion:
This issue is resolved as part of the resolution to the issue 9994. The resolution involves
adding an attribute Ext:String to Storable elements where particular datatype
specification strings can be stored. These strings are uninterpretable within the KDM
models.
Disposition: Duplicate or merged

Add attribute {public, private, etc.} to members of the class

resolved see ptc/2007-03-04 page 167 for details

Consider adding (an optional) ActionRelation for detailed tracking of the usages of operations in the language (like "+", "*", etc.). Size of the model needs to be taked into consideration. 

Discussion:
In principle, this information can be represented using the Calls relationship to an external
CallableUnit, placed into a LanguageUnit. However, this does not seem to add extra value to
KDM models (but does add significant overhead in terms of relationships). Moreover, this does
not address the issue of more precise analysis of KDM models (see issue 10652). This should be
addressed in a different way as part of the “micro-KDM” as outlines in issue 10652.
Disposition: Duplicate or merged

Consider optimizing the usage of Flow relations by making them {ordered}. This would lead to more efficient handling of the basic blocks, and Flow relation will be only needed for goto constructs. The xmi file will remain very readable. 

Discussion:
The issue is about the Flow relations between ActionElements. A common situation is for
two ActionsElement to be part of the same basic block (for example, a sequence of
statements). In this situation, the Flow relation in quote straightforward (from the first
ActionElement to the second ActionElement). The recommendation suggests implicit
Flow relations, by making ActionElement {ordered}. This can potentially reduce the size
of KDM models.
KDM is about making knowledge about existing software EXPLICIT, so explicit Flow
relations satisfy this design goal. Also, this optimization will make navigation through
KDM models more complicated.
Disposition: Closed, no change

Add state as an explicit entity (suggested by Larry Hines in Boston) 

Discussion:
This issue is merged into the issue 10292 which describes the implementation of the common L1
resource layer pattern by the Event package. The contribution of resolution related to this issue is
to add two specific KDM entities for representing “states” and “transitions” between states. See
also resolution to issue 10310, for the description of the common L1 resource layer pattern.
Disposition: Duplicate of merged

The diagram in the Figure 21.2 incorrectly shows that ConceptualElement is a specialization of KDMGroup (from Core). It is also inconsistent with the diagram in the Figure 22.2 (Behavior Package). The correct way to show Conceptual Inheritances is: ConceptualGroup is a specialization of KDMGroup (from Core) and ConceptualElement is a specialization of KDMGEntity (from Core)

resolved see ptc/2007-03-04 page 111 - 112 for details

This is another occurence of "backward navigation" references in the KDM Core. KDM requires navigable associations from KDMEntity to KDMGroup (in the Core KDM this association is named group, see Figure 9.1). While useful for certain type of cross-referencing queries (e.g. to which groups does the given entity belong), these associations make KDM instance XMI extremely inflexible and hard to modify (as information abut relations is essentially duplicated). Also, as this element is subsetted by various groups, children of KDMEntity get funny collections of such associations (e.g. UIGroup, CodeGroup associations, etc). It is better to eliminate all these associations, and leave only the association from the KDMGroup to the KDMEntity element. The group association can be changed into an operation, and implemented internally by particular KDM tools. 

resolved see ptc/2007-03-04 page 121 - 131 for details

Section 9.5.1
Severity: minor
Nature: clarification

9.5.1 KDMAggregatedRelationship Class The KDMAggregatedRelationship represents the set of aggregated relationships of the given entity. The set of derived relationships consists of the primitive relationships of the current entity and of all primitive relationships of the entities that are recursively contained in the current entity. 
	What is the difference between aggregated and derived relationships?
	Can you shed light with an example on the recursive nature of relationship, is this related to group and container type entities?

resolved see ptc/2007-03-04 page 136 - 137 for details

Section 11.4
Severity: minor
Nature: clarification

KDM assumes that a source file is a sequence of lines, identified by a linenumber. Each line is a sequence of characters, identified by a position within the line. Whitespace characters like tabulation are considered to be a single character. 

	What is the definition of character in regards to the KDM? Is it a byte, 2 bytes, UTF-8 or ????, What about special characters such as in Java \u0234. How should that work?
	Are both line numbers and position, 1 based?

An additional attribute to specify encoding is needed for the element SourceRegion and SourceFile.

resolved, see ptc/2007-03-04 page 255 - 256

Section 12.10.2
Severity: minor
Nature: clarification

12.10.2 TemplateParameter Class The TemplateParameter is a CodeElement  and is a parameter for TemplateUnit. 
In the KDM, TemplateParameter is a specialization of TypeElement more specifically.
The text mentions CodeElement, while the diagram mentions CodeResource.

Change the text of section 12.10.2, page 54.
TemplateParameter is a modeling element that represents parameters of a TemplateUnit.
In the meta-model, TemplateParameter is a subclass of TypeElement.
Superclass:
TypeElement
Disposition: Resolved

Section 12.14.1
Severity: minor
Nature: clarification

12.14.1 DerivedTypeElement Class The DerivedTypeElement is a meta-model element that represents user-defined types that are derived from a certain base type. In the meta-model the RefinementType  is a subclass of TypeContainer. It is associated with the corresponding base type. This class is subclassed by several more specific KDM classes. 

The text mentions RefinementType, but the diagram mention DerivedType.

Discussion:
Change the text in section 12.14.1:
The DerivedTypeElement is a modeling element that represents user-defined data types
that are derived from a certain base type. In the meta-model the DerivedTypeElement is a
subclass of TypeContainer. It is associated with the corresponding base type. This class is
subclassed by several more specific modeling elements. DerivedTypeElement class could
be used to represent programming constructs that are not covered by any of the specific
subclasses.
Add constraint:
DerivedTypeElement class should always be used with a stereotype.
Disposition: Resolved

Section 13.5.1
Severity: minor
Nature: clarification


13.5.1 ControlFlow Class The ControlFlow is an association class representing the control flow between ActionElements. 
Superclass ActionRelationship 
	Doesn't look like the right superclass, believe it should be FlowRelationship

Change the text of section 13.5.1:
The ControlFlow is a modeling element that represents control flow relation between
ActionElements. In the meta-model ControlFlow is a subclass of FlowRelationship. It is
further subclassed with more specific modeling elements. ControlFlow class could be
used to represent programming constructs that are not covered any of the specific
subclasses.
Add constraint:
ControlFlow class should always be used with a stereotype.
Disposition: Resolved

Section 13.5.2
Severity: minor
Nature: clarification

13.5.2 EntryFlow Class
The ControlFlow is an association class representing the control flow between ActionElements.
Superclass ActionRelationship 

	Doesn't look like the right description and superclass (believe it should be FlowRelationship)?

Discussion:
Change the text for section 13.5.2:
The EntryFlow is a modeling element that represents an initial flow of control inside a
CallableElement into the first ActionElement of the CallableElement. In the meta-model
the EntryFlow is a subclass of FlowRelationship.
Add constraints:
.. Each CallableElement or its subclass such that it owns one or more
ActionElement should have a corresponding EntryFlow relationship in which the
“from” attribute is the CallableElement
.. The “to” attribute of an EntryFlow element should be an ActionElement that is
owned by the CallableElement that is the “from” attribute of the EntryFlow

Section 13.5.5
Severity: minor
Nature: clarification

13.5.5 Flow Class (abstract) The ImportRelationship class represents the family of relations corresponding to import of declarations between modules. 
Superclass ActionRelationship 
	wrong description, not abstract and their superclass is ControlFlow

Discussion:
Change title of section 13.5.5 to “Flow class” (remove the words abstract).
Change text of the section 13.5.5:
The Flow class is a modeling element that represents control flow relationship between
two ActionElements such that the the ActionElement that corresponds to the “to”
attribute of the Flow is a successor of the ActionElement that corresponds to the “from”
attribute of the Flow.
Add semantics:
If there exists two or more Flow element, such that they share the same ActionElement as
the “from” attribute, they represent an unspecified flow of control.
Disposition: Resolved

Section 13.5.6
Severity: minor
Nature: clarification

13.5.6 TrueFlow Class (abstract)
The ImportRelationship class represents the family of relations corresponding to import of declarations between modules.
Superclass
ActionRelationship
	wrong description, not abstract and their superclass is ControlFlow

Discussion:
Change title of section 13.5.6 to “TrueFlow class” (remove the words abstract).
Change text of the section 13.5.6:
The TrueFlow class is a modeling element that represents control flow relationship
between two ActionElements such that 1) the ActionElement that corresponds to the
“from” attribute of the TrueFlow represents the logical condition; and 2) the
ActionElement that corresponds to the “to” attribute of the TrueFlow is a successor of the
ActionElement that corresponds to the “from” attribute of the TrueFlow when the value
of the condition is true.
Add constraint:
If there exists a TrueFlow element, there should be a corresponding FalseFlow element
such that the both the TrueFlow and the FalseFlow elements has the same ActionElement
as the “from” attribute; and there are no other relationship elements that are subclasses of
FlowRelationship that have the same ActionElement as the “from” attribute.
Disposition: Resolved

Section 13.5.7
Severity: minor
Nature: clarification

13.5.7 FalseFlow Class (abstract)
The ImportRelationship class represents the family of relations corresponding to import of declarations between modules.
Superclass
ActionRelationship
wrong description, not abstract and their superclass is ControlFlow

Discussion:
Change title of section 13.5.7 to “FalseFlow class” (remove the words abstract).
Change text of the section 13.5.7:
The FalseFlow class is a modeling element that represents control flow relationship
between two ActionElements such that 1) the ActionElement that corresponds to the
“from” attribute of the FalseFlow represents the logical condition; and 2) the
ActionElement that corresponds to the “to” attribute of the FalseFlow is a successor of
the ActionElement that corresponds to the “from” attribute of the FalseFlow when the
value of other conditions are not satisfied. FalseFlow represents the “default” control
flow branch in representing conditional statements and switch statements. FalseFlow is a
specific modeling element that is used in combination with either TrueFlow or
GuardedFlow.
Add constraint:
If there exists a FalseFlow element, there should be either 1) a corresponding TrueFlow
element such that the both the TrueFlow and the FalseFlow elements has the same
ActionElement as the “from” attribute; or 2) one or more GuardedFlow elements that
have the same ActionElement as the “from” attribute; and 3) there are no other
relationship elements that are subclasses of FlowRelationship that have the same
ActionElement as the “from” attribute;

Section 13.5.8
Severity: minor
Nature: clarification

 13.5.8 GuardedFlow Class (abstract)
The ImportRelationship class represents the family of relations corresponding to import of declarations between modules.
Superclass
ActionRelationship
	wrong description, not abstract and their superclass is ControlFlow

resolved see ptc/2007-03-04 page 146 - 147 for details

Section 13.5.8
Severity: minor
Nature: clarification

Missing specification on how to represent default flow when representing a switch construct using GuardedFlow. The semantics of FalseFlow should be made more generic as a default case, then it can be used to represent both the conditional flows as wells as GuardedFlows

This issue has been resolved as part of the resolution for the issue 10459.

Section 13.6
Severity: minor
Nature: clarification

13.6 CallableRelations Class Diagram 
	

The CallableRelations  diagram describes the following types: o CodeRelationship - an association class subtyping KDMRelationship. 
 
o Calls - an association class representing a call type relationship between an ActionElement and a CallableInterface . 
		
CallableInterface should be CallableElement

Discussion:
Change text of section 13.6
Calls – is a modeling element that represents a call-type relationship between an
ActionElement and a CallableElement or one of its subclass elements, in which the
ActionElement represents some form of a call statement, and the CallableElement
represents the element being called.
Invokes – is a modeling element that represents an invocation-type of relationship
between an ActionElement and a data item, in which the ActionElement represents some
form of a method invocation, and the data item represents a specific object instance,
which owns the method being called.
Add constraint:
Invokes relationship should have a corresponding Calls relationship, such that the “from”
attribute refers to the same ActionElement.
Disposition: Resolved

Section 13.6.1
Severity: minor
Nature: clarification

13.6.1 Calls Class The Calls class is a subtype of CodeRelationship  and provides linkages between ActionElement and CallableInterface  for the situations when an ActionElement performs a call to the CallableElement. 

Discussion:
Change text of section 13.6.1
Calls is a modeling element that represents a call-type relationship between an
ActionElement and a CallableElement or one of its subclass elements. The
ActionElement represents some form of a call statement, and the CallableElement
represents the element being called. In the meta-model the Calls element is a subclass of
ActionRelationship.
Change related text of section 13.6.3
Invokes is a modeling element that represents an invocation-type of relationship between
an ActionElement and a data item. The ActionElement represents some form of a method
invocation, and the data item represents a specific object instance, which owns the
method being called. In the meta-model the Invokes class is a subclass of ActionElement.
Add constraint to section 13.6.3:
Invokes relationship should have a corresponding Calls relationship, such that the “from”
attribute refers to the same ActionElement.
Disposition: Resolved

Section 13.6.2
Severity: minor
Nature: clarification

13.6.2 UsesCallable Class
The UsesCallable is an association class to provide linkages between ActionElement and CodeElement for any references
to a CallableElement, other than performing a call.
	Should talk about UsesCode instead

Discussion:
This issue has been already addressed as part of the resolution to issue 10119.
Disposition: Closed, no change

Section 13.7
Severity: minor
Nature: clarification

13.7 DataRelations Class Diagram The DataRelations class diagram collects together classes and associations of the Action package. They provide basic meta-model constructs to define data specific CRUD like relationships between ActionElement and DataInterface. 
	What is a DataInterface and where is it defined?

This should be StorableElement.

Discussion:
Change text of section 13.7:
The DataRelations class diagram groups together modeling elements that represent dataspecific
CRUD-like relationships (Create-Read-Update-Delete). The “from” endpoint of
DataRelations is some ActionElement that represents some form of a data-related
statement. The “to” endpoint is some data item, represented either by some subclass of
StorableElement, or in some cases by some subclass of TypeElement.
Disposition: Resolved

Section 13.8
Severity: minor
Nature: clarification

13.8 PrototypeRelations Class Diagram The PrototypeRelations class diagram defines basic meta-model constructs to model prototype relationships between ActionElement and CodeElement.  
Diagram shows extension of PrototypeRelationship, KDM shows extension of CodeRelationship

CodeElement should be a PrototypeUnit

Discussion:
Change text of section 13.8:
The PrototypeRelations class diagram defines some basic modeling elements to represent
relations between ActionElement and PrototypeUnit (for example, to represent the fact
that some call statement uses a certain declaration of a procedure, as opposed to the usage
of a definition of the same procedure).
Disposition: Resolved

Collision of the role name "attribute" in Data package This issue has been raised by Alain Picard from Benchmark Consulting. The role name "attribute" of the association between class XMLComplexType and SimpleTypeElement (from Code) (in the Data package) collides with the role name of the association between class Element and class Attribute. Recommendation is to rename the role in the Data package to "xmlAttribute"

resolved see ptc/2007-03-04 page 152 - 153 for details

Remove several remaining backward navigable links to groups Several backward navigation links have been left unnoticed in the resolution to issue 10412; and need to be removed. StructureGroup -> CodeResource ResourceDefinition -> CodeResource DeployedSoftwareSystem -> SoftwareSystem DeployedComponent -> CodeAssembly DeployedResource -> ResourceElement DeployedResource -> ResourceInstance DeployedResource -> ResourceProvider "Backward navigability" should be removed

resolved see ptc/2007-03-04 page 154 - 156 for details

The current KDM allows for the representation of flow information through various action elements, but the current representation is too vague and lacks the full fidelity needed to provide detailed static analysis “grade” representations, especially when we are being asked to produce this in a standard compliant fashion. Currently, an action element is underspecified: it can be one statement, or more than one statement, or less than one statement. If it is too coarse grained, we are loosing precision regarding the semantics of the Reads and Writes and operations performed and access to complex data structures. What we need is either a finer-grained model or at least a specification that would standardize the way the current elements should be used in order to create a compliant KDM model with “instruction-level” fidelity. Maybe this new “micro-KDM” compliance point becomes part of the optional L1 categories, so that we at least can all agree and understand how to process this kind of information.

resolved, see ptc/2007-03-04 page 280 - 295

Allow multiple SourceRef elements for a given Code element

resolved see ptc/2007-03-04 page 212 for details

Missing attribute length for all StorableElements (as used in the Data item representation examples)

resolved see ptc/2007-03-04 page 213 - 214 for details

ValueElement has to be compatible with StorableElement in order for Reads relationship to work Suggestion: Make ValueElement a subclass of StorableElement. This is a bit of an overspecialization, so we need to add some constraints. Add constraint to ValueElement that it can not have owned elements; it can only be the target of Reads relationship (and not of Addresses, Writes or Initializes). add constraint to Writes, Addresses, Initializes relationships that it can not use ValueElement as target. 

resolved see ptc/2007-03-04 page 215 - 216 for details

Change name of attribute in Annotation from "note" to "text" to reflect semantics

resolved see ptc/2007-03-04 page 217 - 218 for details

ActionElements can not be added directly to CodeModel. Currently CodeModel allows ActionElements (for example, to represent scripts), but does not allow Flow relations. Suggestion to disallow free standing ActionElements, and to use BlockUnit instead, because BlockUnit is a CallableElement, and therefore allows FlowRelations. In order to implement, modify owned elements of CodeModel to become Module

Discussion:
The tentative solution provided in the issue statement is incorrect, as it will violate the
KDM pattern that any KDM element is owned by a KDM model (there used to be a
direct ”backward” navigation link from any KD model element back to the corresponding
model that own this element, but now there is a an API method getModel(), determined
by the derived association in the CoreEntities. Restricting owned elements of CodeModel
to Module will complicate the above pattern.
This is also consistent with the resolution to 9975.
Semantic constraints to the meta-model have already been added as part of 9975.
Disposition: Closed, no change

Allow ActionElement to own storable elements (for example, for temporary variables and values).

resolved see ptc/2007-03-04 page 219 - 220 for details

Make AggregatedRelationship a subclass of KDMRelationship so that they can occur in KDM XMI, add a concept of an AggregatedRelationship Filter (as a set of relationship type names or "all" ) and add a filter attribute to Aggregated relationship

resolved, see ptc/2007-03-04, page 358 - 359

Add optional kind attribute to StorableUnit VariableKind with values {global, local, static, unknown}

resolved see ptc/2007-03-04 page 221 - 223 for details

add type attribute to CallableUnit, to specify Signature to be consistent with ISO Lnaguage Independent datatypes and with StorableElement

resolved see ptc/2007-03-04 page 224 for details

Remove prototype unit, since it is not an independent model element, but either a signature or callable unit or a storable unit with external is true. If later it is substituted with a real definition, the calls or reads/writes relations will go to the internal definition, and UsesPrototype relationship will go to the external one. The internal definition is related to the external one by PrototypedBy relationship. Usually the external definition lives in a SahredUnit. This should be clarified in the spec. Note, there exists an issue about example ralated to this.

resolved see ptc/2007-03-04 page 225 - 227 for details

Rename CodeAssembly to Package and use it to represent logical containers for code elements

resolved, see ptc/2007-03-04 page 329 - 331

StorableElement should be able to own actions. This is required for initialization purposes, according to the Datatype reform. Currently the ownership is restricted to Datatype. Constraint should be added, restricting ownership to Datatype and Action.

Discussion:
Currently StorableElement owns only Datatype in order to represent anonymous datatypes used
in the definition of the data item. The suggested solution (StorableElement owns Action that
represents initialization) does not solve high fidelity semantic representation of the source code,
since it does not address the correct Flow relations between the initialization actions and the rest.
This can be especially complex in case of initializations of global and static variables.
It is better to use existing machinery of BlockUnits and entry flows to represent initializations.
Initialization is still a special action that reads data items and writes to the storable element beign
initialized. This is a rather generic solution.
Besides, there is no need for a special DataRelationship called Initializes. It should be removed.
No further changes. One of the examples will illustrate the pattern for representing initializations.
Summary of changes:
Remove class Initializes from DatRelationship class diagram, and the corresponding text.
Disposition: Resolved

Make extensibility mechanism more general by changing the from-endpoint of the extended relation to the most generic element in the model (currently it is at the extended element).

resolved, see ptc/2007-03-04 page 236 - 239

Inventory model as part of the Source package instead of Build There is one flaw in the current architecture of KDM: SourceRegion elements are part of the L0 compliance point, however the SourceFiles are defined in Build package, which is in L1. It would be much better to consolidate SourceFile elements and alike into a special “Inventory model” (the list of elements representing all artifacts as first class KDM citizens), right in the L0, for example as part of the Source package. In fact, all implementers so far are doing just that: they are aiming at supporting L0 with “limited support for Build”. Everybody seems to have an inventory model, and it makes perfect sense to have it right in the L0. The Build package makes sense on its own right as the place where we represent the “Engineering view” of the software system, i.e. the transformations between the artifacts (for example, files A.c, B.c, and C.c as well as the library GGG.lib are compiled into the executable XYZ.exe, where file A.c is provided by supplier S1, and the GGG.lib is provided by supplier S1, and the transformation requires tool T1 and is described in file “makefile”). 

resolved, see ptc/2007-03-04, page 360 - 368

Some corrections are required to the CallableRelations to align with microKDM to differentiate between calls to static procedures and methods, regular methods, calls to procedures via pointers and calls to virtual methods. micro KDM provides operations to achieve this. More differentiation in the CallableRelations is required. “Invokes” relation conflicts with the ISO usage of the term. KDM uses “Calls” instead “Invokes’, leaving both will be confusing. “Invokes” can be changed into “Addresses” which can be generalized to work with a common parent of ControlElements and StorableElements

resolved, see ptc/2007-03-04 page 332 - 335

The clear separation of KDM into Infrastructure, Program Elements, Resources and Abstractions layers shows that the current design is overly complex. Currently each package defines own “abstractions” capabilities (an arbitrary container and group). I suggest concentrating all containers and groups in the Abstractions layer. In the long run, this makes the whole KDM architecture more consistent. 

Discussion:
Summary of changes:
Remove the overgenaralized group association from Program Elements and Resources.
Change diagrams CodeModel, DataModel, EventModel, PlatformModel.
Disposition: Resolved

Current KDM has duplication between prototype relations (UsesPrototype and PrototypedBy) and interface relations (Implements, ImplementationOf, and CompliesTo). I suggest removing the prototype relations and use Interface relations.

resolved, see ptc/2007-03-04 page 337 - 338

Diagram ExceptionFlow should be moved to Code package in order to comply to the encapsulated relations meta-model pattern in KDM. This is a Code relations, since the from-endpoint is a code element

Discussion:
Move the section ExceptionFlow from Action package to code package.
Change the superclass from FlowRelationship to CodeRelationship.
Disposition: Resolved

Corrections to the text of the KDM package section, clarifying semantics 

resolved, see ptc/2007-03-04, page 369 - 375

Currently the “encapsulated relationship” pattern requires that relationship are owned by the element which is the origin of the relationship. There is a constraint for that. However, the multiplicity of the owned relationship in the xxxModel diagrams is 0..1 (at the owner side) It should be tightened to 1 

Discussion:
Change the multiplicity of the owned relationship relation in xxxModel diagrams from 0..1 to 1.
Disposition: Resolved