p.101 (p.79) I don't see the use for the DateType Class. As ISO 11404 does, I suggest having only the TimeType Class
and removing 12.9.5 DateType Class. BTW, I like the addition of the Decimal class – I'm a little puzzled why ISO 11404
doesn't have it. For the most part, I would suggest being in total sync with 11404 should be the default and only in
selected (very rare) instances should there be deviations. Also, being in sync with the order and structure of chapters 8
and 10 of ISO 11404:2007 would be better, particularily when fast tracking this through ISO.

This issue has been closed in KDM RTF 1.3

This issue has been already closed by KDM RTF 1.3

p.85 (p.63) In the Constraints section of 12.3.5 and 12.3.6, the numbers are 2 and 3 instead of 1 (looks like Words
autonumbering feature is helping you)

This issue has been disposed in KDM RTF 1.3

This issue has been disposed as duplicate by KDM RTF 1.3, ballot 1.

p.32 (p.10), p.79 (p.57), and other places: "ISO/IEC 11404" should be "ISO/IEC 11404:1996" – you may even want to update
this to be "ISO/IEC 11404:2007" which is the latest version and for the purposes of this document would not likely be different.

This issue has been disposed in KDM RTF 1.3

This issue has been disposed as duplicate in KDM RTF 1.3, ballot 1.

from:KDMEntity[1] The source container of the relationships in the aggregated set. All relationships in
the aggregated set should originate from the source container or from some entity
that is contained directly or indirectly in the source container

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1.

to: KDMEntity[1] The target container of the relationships in the aggregated set. All relations in the
aggregated set should terminate at the target container or at some entity that is
contained directly or indirectly in the target container.

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1.

Related to clause: 3

See above. And if you want to refer OMG documents, write reference like:

IEC Std Template, IEC, available at http://www.iec.ch/tiss/templates.htm

Change format of the normative references and update versions

Change format of the normative references and update versions

In the ConceptualRelations Class Diagram in the KDM specification (see page 269) indicates that ConceptualFlow class has two associations socalled ‘to’ and ‘from’ on ConceptualContainer class. However in the section that explains the associations (in same page) indicates that they are ‘to’ and ‘from’ associations that have AbstractConceptualElement type (superclass of ConceptualContainer class).
”

Change model to generalize endpoints of ConceptualFlow to AbstractConceptualElement

Change model to generalize endpoints of ConceptualFlow to AbstractConceptualElement to match the specification text.

Currently RecordFile in DataModel owns ItemUnits. There is a need for a RecordType, so that we can define a StorableUnit, corresponding to a record, and use that RecordType for the Type attribute of that StorableUnit. We need the StorableUnit for Addresses, etc. It is important that the RecordFile owns the RecordType, because we want to have associations going to the RecordFile whenever its fields are used in the code.

Suggested resolution: generalize owned elements from ItemUnit to CodeItem.

Illustrate usage of owned ItemUnit as record fields

add microKDM kind "Assign"; add Reads and Writes to ItemUnits owned by files in twp action elements. Clarify the description of the example for RecordFile on page 236.

p.25 (p.3) Confusion: If L1 compliance implies full realization of L0, then what purpose does L2 serve? You
can have L0 compliance or L1 compliance, but wouldn't L2 compliance be the same as L1 compliance since
both imply L0 and L1 compliance? In short, I don't see what purpose L2 serves – maybe additional text is
needed on L2 in this section.

This issue has been disposed in KDM RTF 1.3

This issue has been already resolved in KDM RTF 1.3, ballot 1

"Constraints" sub-section in the descriptions seems to be rarely needed. That is not a problem, but I read through many
sections wondering what it was used for and why it appeared. Might be useful to enter a "None" beneath each one with
no constraints so it is clear that it is a placeholder and that there are no constraints for that section.

This issue has been disposed in KDM RTF 1.3

This issue has been disposed as duplicate in KDM RTF 1.3, ballot 1

Page number refers to the pdf page number as in "178/334." Page numbers in parenthsis refers to
the page number at the bottom of each page.

Already closed in KDM RTF 1.3

This issue has been already closed in KDM RTF 1.3, ballot 1

p.32 (p.10) "KDM is aligned with ISO/IEC 11404 Language-Independent Datatypes and SBVR" – spell out SBVR

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1

p.32 (p.10) "KDM is a MOF model" should be "KDM is a Meta-Object Facility (MOF) model"

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1.

p.31 (p.9) bottom of page – "Logically, KDM consists of 9 models." – is it 9 because the infrastructure layer elements
are not counted as models?

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1

p.42 (p.20) Constraints sub-section – item in that section should be numbered (e.g. "1. The set...") to be consistent with
other Constraint sub-sections. Same is true of other Constraint sub-sections, so the rest need to be checked.

This issue has been disposed in KDM RTF 1.3

This issue has already been disposed as duplicate in KDM RTF 1.3, ballot 1.

p.35 (p.13) "Small KDM core..." – need description or introduction as to what this is. Suggest going over and rewriting the section
on the core package in "Part 1"

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1.

p.34 (p.12) Bullet in section 8.2: "The Kdm package provides static context shared by all KDM models" should be "The kdm
package provides static context shared by all KDM models"

This issue has been disposed in KDM RTF 1.3

This issue has been already disposed as duplicate in KDM RTF 1.3, ballot 1

p.33 (p.11) "The Kdm package provides the..." should be "The kdm package provides the..."

p.33 (p.11) "the infrastructure. kdm package" should be "the infrastructure. The kdm package"

This issue has been disposed in KDM RTF 1.3

This issue has been disposed as duplicate in KDM RTF 1.3

The KDM documentation is missing a small documentation piece that should be:

12.3.7 Module Class (generic)

Describe top subclasses for each KDM model

Each KDM model should clearly define the main subclasses of the corresponding AbstractXXXElement. This should be clear both from diagrams as well as support text.

Section 12 – I like the examples (e.g. "An example of a choice datatype is a Pascal and Ada variant record, and a union in the
C programming language.") – maybe a new Example field could be added to the Superclass, Constraints, Semantics, etc. fields
for all parts of Section 12 – 12.11.3 already has this and I think it is the only entry that does.

Defered to KDM 1.5

Additional cycle will be required to evaluate the need for more examples

p.102 (p.80) Suggest calling FloatType RealType to be consistent with ISO 11404.

*Rename FloatType class into RealType *

Rename FloatType into RealType to align with ISO 11404.

Suggested resolution: Define this standard with "shall", "should" and "may".

Modify table 2.1 Compliance statement by adding phrase “Compliant tool shall: in each cell and
adding bullets to each requirement.
Make the following editorial changes:
L0 Import-Analysis:
Change:
support specified mapping between KDM and existing model in the tool;
into
implement mapping between KDM and existing internal representation of the tool;
Add word “support”:
extend operations of existing tool to support traceability to the physical artifacts of the application
from Source package.
Add word “demonstrate” in front to “L0 compliance”
In semantic sections – change “it is implementer’s responsibility” to “the implementer shall”
(below we only show the new version of the sentence with the changed phrase underlined):
Source package:
Page 45
The implementer shall arrange inventory elements into one or more inventory models. KDM import tools
shall not make any assumptions about the organization of inventory items into inventory models.
Page 47:
The implementer shall provide a mapping from concrete types of the physical artifacts involved in the
engineering of the existing software system into concrete subclasses of the InventoryItem. The
implementer shall map each artifact of the existing software system to some instance of KDM
InventoryItem.
Page 51:
The implementer shall capture certain aspects knowledge of the engineering process in the form of
“DependsOn” relations between inventory items.
Page 53:
The implementer shall provide adequate traceability links.
Code package The implementer shall arrange code elements into one or more code models.
Page 65
The implementer shall select an appropriate subclass of the Module element.
Page 66
The implementer shall add such files to the InventoryModel.
Page 110
Change “The implementer will have the choice to either”
into
The implementer shall either:
Page 112
Change “This is up to the implementer” into
The implementer may provide additional information using stereotypes.
Page 113
Change “KDM does not restrict implementers whether to clone the included code
elements or to reuse them and keep a single copy in the SharedUnit. However, many
KDM implementations will usually clone the elements of the SharedUnit. “ into
The implementer may either clone the included code elements or to reuse them and keep a single copy in
the SharedUnit. The recommended approach is to clone the elements of the SharedUnit.
Page 114
The implementer shall select a particular strategy to represent macro units
Page 116
The implementer shall identify and represent associations between MacroUnits, as well as a
MacroDirective and the corresponding MacroUnit according to the semantics of the preprocessor.
Page 119
The implementer shall identify and represent include relationships according to the semantics of the
particular preprocessor.
Page 120
The implementer shall identify and represent the variants and associations between the “generated” code
and the corresponding conditional directive according to the semantics of the preprocessor.
Page 121
The implementer shall identify and represent redefinitions of macro units according to the semantics of the
particular preprocessor.
Page 123
The implementer shall make an adequate decision on how to associate line comments with the surrounding
elements in the source code.
Page 127 The implementer shall identify and represent import directives and their targets according to the semantics
of the programming language of the existing software system.
Action package
Page 131
The implementer shall select the granularity of the action elements.
Page 131
The implementer shall map programming language statements and other descriptions of behavior into
KDM ActionElements.
Page 134
The implementer shall map control flow mechanisms of the given programming language into ControlFlow
meta-elements. The implementer shall adequately represent the control flows of the existing system by a set
of action elements and ControlFlow relationships between them.
Page 150
The implementer shall identify and represent these associations according to the semantics of the
programming language of the existing software system.
Micro actions
Page 154; constraint 1 “should” change into “shall”
Platform package
Page 165
The implementer shall arrange platform elements into one or more platform models.
Page 168
The implementer shall identify runtime resources used by the existing software system according to the
semantics of the platform used by the existing system, resource configuration files, and other appropriate
sources of information.
Page 175
The implementer shall correctly associate the platform resource with the corresponding logical definition of
this resource (usually a Signature, an Interface, or a Package).
UI package
Page 184
The implementer shall arrange user-interface elements into one or more UIModel containers.
Page 185
The implementer shall map specific user interface element types determined by the particular user-interface
system of the existing software system, into concrete subclasses of the AbstractUIElement. The
implementer shall map each user interface element into some instance of the AbstractUIElement.
Implementation elements are one or more ComputationalObjects or ActionElements from some
CodeModel that are represented by the current UI element. “Abstraction” actions may be used to represent
precise semantics of the UI Element. Page 185
The implementer shall map specific user interface association types determined by the particular userinterface
system of the existing software system, into concrete subclasses of the AbstractUIRelationship.
The implementer shall map each user interface association into some instance of the
AbstactUIRelationship.
Event package
Page 196
The implementer shall arrange event elements into one or more event models.
Data package
Page 208
The implementer shall arrange the instances of the data elements into one or more DataModels.
Build package
Page 285
The implementer shall capture the input build elements for a certain build step in the form of “Consumes”
relation.
Page 286
The implementer shall capture the output build elements for a certain build step in the form of “Produces”
relation.
Page 286
The implementer shall capture the required Tool elements for a certain build step in the form of
“SupportedBy” relation.
Page 287
The implementer shall capture the origin of build elements in the form of “SuppliedBy” relation.
Page 287
The implementer shall capture the description of a certain build step in the form of “DescribedBy” relation
to some BuildDescription element.

Related to clause: 7 last paragraph

Suggested resolution:

ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)

Make the following changes to the text:
Page 10
Change “KDM is aligned with ISO/IEC 11404 Language-Independent Datatypes and SBVR” into
KDM is aligned with ISO/IEC 11404 General-Purpose Datatypes and OMG Semantics of Business
Vocabularies and Business Rules (SBVR)
Page 57
Change “Data representation of KDM is aligned with ISO/IEC 11404 (Language-
Independent datatypes) standard.” Into
Data representation of KDM is aligned with ISO/IEC 11404 (General-Purpose Datatypes) standard.
Pages 76, 77, 79, 80, 81, 82, 83, 84, 85, 87, 88, 89, 90, 91, 93, 95
Change ISO/IEC 11404:1996 into ISO/IEC 11404
Page 77
Change “Data representation of KDM is aligned with ISO/IEC 11404 (Language-Independent datatypes)
standard.” Into
Data representation of KDM is aligned with ISO/IEC 11404 (General-Purpose Datatypes) standard.

Suggested resolution: All class constraints must be numbered.

Remove all empty Constraints sections
Add numbers to constraints in section 9.4.2, page 20
Add numbers to constraints in section 10.6.2, page 39
Add numbers to constraints in section 11.6.1, page 52
Add numbers to constraints in section 11.6.2, page 54
Add numbers to constraints in section 13.5.2, page 134
Add numbers to constraints in section 13.5.4, page 135
Add numbers to constraints in section 13.5.5, page 136
Add numbers to constraints in section 13.5.6, page 137
Add numbers to constraints in section 16.5.1, page 187
Add numbers to constraints in section 16.5.2, page 187

Related to clause: 6.3

Suggested resolution: Remove subclause 6.3.

According to the guidance from the OMG-ISO Liaison:
The acknowledgments should not be in a normative part of an ISO standard.
You could remove them or put them in an informative annex

Related to clause: Annex A

Suggested resolution: Annex A may be informative.

Annex A is normative.
Add the word (normative) to section title Annex A – Semantics of the Micro KDM Action Elements
(normative).
Add word normative to the first sentence of the section:
This normative annex defines..

p.45 (p. 23) The explanation of Figure 9.4 (paragraph) right after Figure 9.4 needs work. There are no arrows in the figure,
contrary to the explanation in the paragraph. Would be helpful to tie the paragraph more to the figure, e.g. instead of
"UML package symbols represent KDM Containers..." state "UML package symbols C1 and C2 represent KDM Containers..."
and instead of "Numbers at the ends of associations..." state "the numbers at the ends of associations, such as +2,..."

Also, "interpretation that UML multiplicity" needs fixing – not sure what the sentence should read.

Page 21 replace “AggregatedRelations are” into “AggregatedRelationship is”
Page 22 top, bullet 4, replace “AggregatedRelation” into “AggregatedRelatiopnship”
Page 22 Replace “The relation “x in* C” with “The relationship “x in* C”
Replace “For relation R … corresponding aggregated relation” with “For relationship R…
corresponding aggregated relationship”
Next line replace “relation R, let” into “relationship R, let”
Replace “C1 and C2 are related by the aggregated relation” with “C1 and C2 are related by the
aggregated relationship”
Change caption of Figure 9.4 into “AggregatedRelationships illustrated
Replace “Containers and aggregated relations” into “Containers and aggregated relationships”
Page 22, text after figure 9.4. replace “UML package symbols represent KDM containers” into
“UML package symbols C1 and C2 represent KDM containers”
Replace “Numbers at the ends of associations” into “The numbers at the ends of associations,
such as “+2” ”
Replace “relation (there should be at least one arrow; arrows at both ends indicate two relations,
one in each direction)” into “relationship, when there are no arrows at either end of the
association (as in the Figure 9.4), this indicates two relationships, one in each direction.”
Replace “The KDM density has a different interpretation that UML multiplicity” into “The KDM
density has a different interpretation than UML multiplicity”
Replace “the exact relations” into “the exact relationships”
Replace “Aggregated relations are collections of more primitive relations” into “Aggregated
relationships are collections of primitive relationships”
Line 2 from bottom replace “code relation” into “code relationship”
Page 23 line 1 replace “aggregated relation” into “aggregated relationship”
Line 2 replace “aggregated relation” into “aggregated relationship”
Line 3 “primitive relations” into “primitive relationships”
In createAggregation operation replace “aggregated relation” into “aggregated relationship”

p.43 (p.21) Might as well make the description for the following items identical except for source/target, terminate/originate, from/at
instead of rewording the second sentence to state the same meaning (e.g. "All relations" instead of "All relationships")

9.5.1. Associations, Page 21, “to:KDMEntity[1]” replace “relations” with “relationships”

p.41 (p. 19) The Semantics paragraph is simply a repeat of the one in the opening section (Part 1). Might be better to keep the
paragraph in Part 1 general and instead of repeating it, tailor it to the specific item being discussed, in this case the
KDMRelationship Class, and what being binary, for example, means to this class. The paragraph is too general to be in this
section. The semantics section in 9.4.3 is much more specifically tailored to the item being discussed and is much better.

Replace entire semantics paragraph with the following:
“KDMRelationship meta-model element is an abstract element. The concrete KDM relationships
between KDM entities in KDM views are instances of concrete subclasses of KDMRelationship.
Each instance of KDMRelationship has exactly one target and exactly one origin. Each concrete
subclass of KDMRelationship defines the acceptable types of the endpoints.”

p.32 (p.10) "Analyst is able to refactor the model..." bullet should be something like "KDM provides model refactoring capability
for analysts..." to be consistent with the other bullets (all of the other ones start with "KDM..."

Page 13 replace “Analyst is able to refactor the model (for example, by moving entities between
containers) and map changes in the model to changes in the software through traceability links””
into
“KDM provides model refactoring capabilities, for example, a KDM tool can support moving
entities between containers and map changes in the model to changes in the code through the
traceability links”.

p.31 (p.9) In bullets, "KDM Infrastructure Layer" should be "Infrastructure Layer" since the other 3 bulletted items
do not have "KDM" in them.

Page 6 replace “The KDM Infrastructure Layer” with “Infrastructure Layer”
Page 11. replace “KDM Infrastructure Layer” with “Infrastructure Layer”
Page 12 3rd paragraph, replace “KDM Infrastructure Layer” into “Infrastructure Layer”
Page 25 replace “KDM Infrastructure” with “Infrastructure Layer”
Page 13 (Part I) change title into “Infrastructure Layer”
1st paragraph replace “KDM Infrastructure Layer” with “Infrastructure Layer”
Change index “KDM Infrastructure Layer 10” into “Infrastructure Layer 10”

There were many instances of general information/comments that apply widely made in the detailed
(specific) descriptions. For instance, in the semantics section of 10.3.4, it is stated:
"The implementers of KDM import tools should not make any assumptions regarding the organization of the KDM models
into KDM segments."
This is a very general statement that applies widely. As such, it would be better to be put into a general introduction
section instead of in a specific section. Such general statements can be adapted to where they apply so they don't
read so general as in section 10.4.1:
"The implementers of KDM import tools should not make any assumptions regarding the content of the Audit element,
other than the “human-readable text.” It is expected that at least one Audit element is related to the origin of the model or
segment."
If possible, either adapt the statements so they are specific when in specific sections, or remove them to general (abstract)
sections.

Page 25, Add sentence after “the implementer shall provide … “ “On the other hand, the
implemented of KDM import tools should not make any assumptions about the
organization of KDM model elements in models or organization of models in segments.”
Page 28, delete “The implementers of KDM import tools should not make any assumptions regarding
the organization of the content into KDM models. “
Page 29, delete “The implementers of KDM import tools should not make any assumptions regarding
the organization of the KDM models into KDM segments.”

p.53 (p.31) Section 10.4.2 – should there be more of a description here? Maybe a reference to the KDMFramework (abstract)
section?

Add sentence to 10.4.2 before Associations:
“Audit elements can be owned by any subclass of the KDMFramework element, including
segment or model.”

p.52 (p.30) date:String and constraints both state the constraint on the date format. Since this is specific to the
date field, suggest removing it from the constraint sub-section.

resolved

p.25 (p.3) "In this case interoperability at this level would be viewed as correlation between tools to
complete knowledge puzzle that end user might need to perform a particular task." should be
"In this case interoperability at this level would be viewed as a correlation between tools to
the complete knowledge puzzle that the end user might need to perform a particular task."

Remove sentence page 3:
“This would be an additional reason why L0 interoperability (which at this level would be viewed as
information sharing between tools) is mandated. In this case interoperability at this level would be viewed
as correlation between tools to complete knowledge puzzle that end user might need to perform a particular
task. “

p.47 (p.25) Throughout the document, "kdm package" is also spelled as "Kdm package" – not sure which is correct
(I assumed it was kdm package until this section). Just need to go a global search and make it consistent, whichever
it should be.

p.48 (p.26) need a space between the dash and defines in the first line ("–defines" should be "– defines")

p.51 (p.29) Example section: there are extra blank lines in the Example that need to be removed.

resolved

p.65 (p.43) "KDM offers further two options:" should be "KDM offers an additional two options:"
p.66 (p.44) "such a SourceFile, an" should be "such as a SourceFile, an"

Section 11.1, page 43 replace "KDM offers further two options:" with "KDM
offers an additional two options:"

p.33 Figure 8.1 – "Actions" should be "Action"

see page 24 of ptc/2010-12-10

Related to 8.2, Part I

"Each KDM package defines several entity types representing specific abstractions related to a certain viewpoint on existing software systems."

The architectural viewpoints being employed should be made explicit, and defined as per ISO 42010

Add definitions of architecture viewpoints for each package that defines an architectural viewpoint:
Section 11.1 Page 43 Inventory architecture viewpoint
Concerns:
• What are the artifacts (software items) of the system?
• What is the general role of each artifact (for example, is it a source file, a binary file, an
executable or a configuration description)?
• What is the organization of the aritifacts (into directories and projects)?
• What are the dependencies between the artifacts?
Viewpoint language:
Inventory views conform to KDM XMI schema. The viewpoint language for the Inventory
architectural viewpoint is defined by the Source package. It includes an abstract entity
AbstractInventoryElement, several generic entities, such as InventoryItem and InventoryContainer, as well
as several concrete entities, such as SourceFile, BinaryFile, Image, Directory, etc. The viewpoint language
for the Inventory architectural viewpoint also includes DependsOn relationship, which are subclasses of
AbstractInventoryRelationship.
Analytic methods:
The Inventory architectural viewpoint supports the following main kinds of checking:
• What artifacts depend on the given artifact?
The Inventory viewpoint also supports check in combinations with other KDM architectural
viewpoint to determine the original artifacts that correspond to a given KDM element.
Construction methods:
• Inventory views that correspond to the KDM Inventory architectural viewpoint are
usually constructed by directory scanning tools, which identify files and their types.
• Construction of an Inventory view is determined by the particular development and
deployment environments of the existing software system
• Construction of an Inventory view is determined by the semantics of the environment as
well as the semantics of the corresponding artifacts, and it based on the mapping from the
given environment to KDM The mapping from a particular environment to KDM may produce additional information
(system-specific, or environment-specific, or extractor tool-specific). This information
can be attached to KDM elements using stereotypes, attributes or annotations
Change sentence: It represents the convergence between the KDM intermediate representation and the
application source it represents.
Into
It represents the association between the KDM model and the artifacts it represents.
Part II Program Elements Page 57 Code architecture viewpoint
Concerns:
• What are the computational elements of the system?
• What are the modules of the system?
• What is the low-level organization of the computational elements?
• What are the datatypes used by the computational elements?
• What are the units of behaviour of the system?
• What are the low-level relationships between the code elements, in particular what are the
control-flow and data-flow relationships ?
• What are the important non-computational elements?
• How computational elements and modules are related to the physical artifacts of the
system?
Viewpoint language:
Code views conform to KDM XMI schema The viewpoint language for the Code architectural
viewpoint is defined by the Code and Action packages. It includes several abstract entities, such as
AbstractCodeElement and CodeItem, several generic entities, such as Datatype, ComputationalObject and
Module, as well as several concrete entities, such as StorableUnit, CallableUnit, CompilationUnit and
ActionElement. The viewpoint language for the Code architectural viewpoint also includes several
relationships, which are subclasses of AbstractCodeRelationship and AbstractActionRelationship.
Analytic methods:
The Code architectural viewpoint supports the following main kinds of checking:
• Composition (for example, what code elements are owned by a CompilationUnit,
SharedUnit or a CodeAssembly; what action elements are owned by a CallableUnit)
• Data flow (for example, what action elements read from a given StorableUnit; what
action elements write to a given StorableUnit; what action elements create dynamic
instances of a given Datatype; what action elements address a particular StorableUnit;
what data element are being read as actual parameters in a call)
• Control flow (for example, what CallableUnit is used in a call; what action element is
executed after the given action element; what action elements are executed before the
given action element; what data element is used to dispatch control flow from a given
action element; what action element is executed after the given element under what
conditions; what is the exceptional flow of control; what action elements are executed as
entry points to a given module or a CallableUnit)
• Datatypes (for example, what is the datatype of the given storable unit; what is the base
datatype of the given pointer type; what is the base datatype of the given element of the
record type; what is the signature of the given CallableUnit)
Other kind of checking are related to the interfaces, templates and pre-processor. All
relationships defined in the Code model are non-transitive. Additional computations are
required to derive, for example, all action elements that can be executed after the given action
element, or all CallableUnits that a given action element can dispatch control to. The KDM mechanism of aggregated relationship is used to derive relationships between
KDM elements that own or reference various Code elements (usually, Module and
CodeAssembly) based on the low-level relationship between individual Code elements
Construction methods:
• Code views that correspond to the KDM Code architectural viewpoint are usually
constructed by parser-like tools which take artifacts of the system as the input and
produce one or mode Code views as output
• Construction of the Code view is determined by the syntax and semantics of the
programming language of the corresponding artifact, and it based on the mapping from
the given programming language to KDM; such mapping is specific only to the
programming language and not to a specific software system
• The mapping from a particular programming language to KDM may produce additional
information (system-specific, or programming language-specific, or extractor toolspecific).
This information can be attached to KDM elements using stereotypes, attributes
or annotations
Section 15.1, page 163 KDM Platform architecture viewpoint
Concerns:
• What are the resources used by the software system?
• What elements of the run-time platform are used by the software system?
• What behaviour is associated with the resources of the run-time platform?
• What control flows are initiated by the events in the resources?
• What control flows are initiated by the run-time environment?
• What are the bindings to the run-time environment?
• What are the deployment configurations of the software system?
• What are the dynamic/concurrent threads of activity within the software system?
Viewpoint language:
Platform views conform to KDM XMI schema The viewpoint language for the Platform
architectural viewpoint is defined by the Platform package. It includes an abstract entity
AbstractPlatformElement, several generic entities, such as ResourceType, RuntimeResource, as well as
several concrete entities, such as PlatformAction, PlatformEvent, ExternalActor, MarshalledResource,
NamingResource, etc. The viewpoint language for the Platform architectural viewpoint also includes
several relationships, which are subclasses of AbstractPlatformRelationship.
Analytic methods:
The Platform architectural viewpoint supports the following main kinds of checking:
• Data flow (for example, what action elements read from a given resource; what action
elements write to a given resource; what action elements manage a given resource;
including indirect data flow using a MarshalledResource or a MessagingResource where
a particular resource is used to perform a data flow between the “send” action element
and the “receive” action element)
• Control flow (for example, what action elements are triggered by events in a given
resource; what action elements operate on a given resource)
• Identify of resource instances based on resource handles in various modules
Platform Views are used in combination with Code views and Inventory views.
Construction methods:
• Platform views that correspond to the KDM Platform architectural viewpoint are usually
constructed by analyzing Code views for the given system as well as the platformspecific
configuration artifacts. The platform extractor tool uses the knowledge of the
API and semantics for the given run-time platform to produce one or mode Platform
views as output As an alternative, for some languages like Cobol, in which the elements of the run-time
platform are explicitly defined by the language, the platform views are produced by the
parser-like tools which take artifacts of the system as the input and produce one or mode
Platform views as output (together with the corresponding Code views)
• Construction of the Platform view is determined by the semantics of the run-time
platform, and it based on the mapping from the given run-time platform to KDM; such
mapping is specific only to the run-time platform and not to a specific software system
• The mapping from a particular run-time platform to KDM may produce additional
information (system-specific, or platform-specific, or extractor tool-specific). This
information can be attached to KDM elements using stereotypes, attributes or annotations
Section 16.1, page 183 UI architecture viewpoint
Concerns:
• What are the distinct elements of the user interface of the systems?
• What is the organization of the user interface?
• How user interface uses artifacts of the system (for example, images) ?
• What data flows originate from the user interface ?
• What data flows output to the user interface?
• What control flows are initiated by the user interface?
Viewpoint language:
UI views conform to KDM XMI schema The viewpoint language for the UI architectural
viewpoint is defined by the UI package. It includes an abstract entity AbstractUIElement, several generic
entities, such as UIResource, UIDisplay, as well as several concrete entities, such as Screen, Report,
UIField, UIAction, UIEvent, etc. The viewpoint language for the UI architectural viewpoint also includes
several relationships, which are subclasses of AbstractUIRelationship.
Analytic methods:
The UI architectural viewpoint supports the following main kinds of checking:
• Data flow (for example, what action elements read from a given UI element; what action
elements write to a given UI element; what action elements manage a given UI element)
• Control flow (for example, what action elements are triggered by events in a given UI
element; what action elements operate on a given UI element)
• Workflow (what UI elements will be displayed after the given one; what UI elements are
displayed before the given one)
UI Views are used in combination with Code views and Inventory views.
Construction methods:
• UI views that correspond to the KDM UI architectural viewpoint are usually constructed
by analyzing Code views for the given system as well as the UI-specific configuration
artifacts. The UI extractor tool uses the knowledge of the API and semantics for the given
run-time platform to produce one or mode UI views as output
• As an alternative, for some languages like Cobol, in which the elements of the UI are
explicitly defined by the language, the UI views are produced by the parser-like tools
which take artifacts of the system as the input and produce one or mode UI views as
output (together with the corresponding Code views)
• Construction of the UI view is determined by the semantics of the UI platform, and it
based on the mapping from the given UI platform to KDM; such mapping is specific only
to the UI platform and not to a specific software system
• The mapping from a particular UI platform to KDM may produce additional information
(system-specific, or platform-specific, or extractor tool-specific). This information can be
attached to KDM elements using stereotypes, attributes or annotations Section 17.1, page 195 Event architecture viewpoint
Concerns
• What are the distinct states involved in the behaviour of the software system?
• What are the events that cause transitions between states?
• What action elements are executed in a given state?
Viewpoint language:
Event views conform to KDM XMI schema The viewpoint language for the Event architectural
viewpoint is defined by the Event package. It includes an abstract entity AbstractEventElement, generic
entity EventResource, UIDisplay, as well as several concrete entities, such as State, Transition, Event,
EventAction, etc. The viewpoint language for the UI architectural viewpoint also includes several
relationships, which are subclasses of AbstractEventRelationship.
Analytic methods:
The Event architectural viewpoint supports the following main kinds of checking:
• Reachability (for example, what states are reachable from the given state)
• Control flow (for example, what action elements are triggered by a given state transition;
what action elements will be executed for a given traversal of the state transition graph)
• Data flow (what data sequences correspond to a given traversal of the state transition
graph)
Event Views are used in combination with Code views, Data views, Platform views and
Inventory views.
Construction methods:
• Event views that correspond to the KDM Event architectural viewpoint are usually
constructed by analyzing Code views for the given system as well as the configuration
artefacts specific to the event-driven framework. The Event extractor tool uses the
knowledge of the API and semantics of the event-driven framework to produce one or
mode Event views as output
• Construction of the Event view is determined by the semantics of the event-driven
framework, and it based on the mapping from the given event-driven framework to
KDM; such mapping is specific only to the event-driven framework and not to a specific
software system
• The mapping from a particular event-driven framework to KDM may produce additional
information (system-specific, or platform-specific, or extractor tool-specific). This
information can be attached to KDM elements using stereotypes, attributes or annotations
Section 18.1, page 207 Data architecture viewpoint
Concerns
• What is the organization of persistent data in the software systems?
• What are the information model supported by the software system?
• What action elements read persistent data?
• What action elements write persistent data?
• What control flows are determined by the events corresponding to persistent data?
Viewpoint language
Data views conform to KDM XMI schema The viewpoint language for the Data architectural
viewpoint is defined by the Data package. It includes abstract entities AbstractDataElement,
AbstractContentElement, generic entities DataResource, DataContainer, ContentItem, as well as several
concrete entities, such as Catalog, RelationalSchema, DataEvent, DataAction, ColumnSet,
RecordFile,XMLSchema, etc. The viewpoint language for the Data architectural viewpoint also includes
several relationships, which are subclasses of AbstractDataRelationship. Analytic methods:
The Data architectural viewpoint supports the following main kinds of checking:
• Data aggregation (the set of data items accessible from the given ColumnSet by adding
data items through foreign key relationships to other tables)
Data Views are used in combination with Code views and Inventory views.
Construction methods:
• Data views that correspond to the KDM Data architectural viewpoint are usually
constructed by analyzing Data Definition Language artifacts for the given data
management platform. The Data extractor tool uses the knowledge of the data
management platform to produce one or mode Data views as output
• As an alternative, for some languages like Cobol, in which some elements of the Data are
explicitly defined by the language, the Data views are produced by the parser-like tools
which take artifacts of the system as the input and produce one or mode Data views as
output (together with the corresponding Code views)
• Construction of the Data view is determined by the semantics of the data management
platform, and it based on the mapping from the given data management platform to
KDM; such mapping is specific only to the data management platform and not to a
specific software system
• The mapping from a particular data management platform to KDM may produce
additional information (system-specific, or platform-specific, or extractor tool-specific).
This information can be attached to KDM elements using stereotypes, attributes or
annotations
Section 19.1, page 255 Structure architecture viewpoint
Concerns:
• What are the structural elements of the system, and what is the organization of these
elements?
• What software elements compose the system?
• How the structural elements of the system are related to the computational elements?
• What are the connections of these elements based on the relationships between the
corresponding computational elements?
• What are the interfaces of the structural elements of the system?
Viewpoint language:
Structure views conform to KDM XMI schema The viewpoint language for the Structure
architectural viewpoint is defined by the Structure package. It includes abstract entitity
AbstractStructureElement, and several concrete entities, such as Subsystem, Layer, Component,
SoftwareSystem, ArchitectureView. The viewpoint language for the Structure architectural viewpoint also
includes an abstract relationship AbstractStructureRelationship.
Analytic methods:
The Structure architectural viewpoint supports the following main kinds of checking:
• Attachment (are components properly connected?)
• Coupling and cohesion (the number of internal relationship within a component
compared to the number of relationships to other components)
• Efferent and afferent relationship (uses of a component by other components and usages
of other component by the given component)
• Interfaces (what is the required and provided interface of the given component)
Structure Views are used in combination with Code views, Data views, Platform views, UI
views and Inventory views.
Construction methods: Structure views that correspond to the KDM Structure architectural viewpoint are usually
constructed by analyzing architecture models of the given system. The Structure extractor
tool uses the knowledge of the architecture models to produce one or mode Structure
views as output
• As an alternative, structure views can be produced manually using the input from the
architect of the system and architecture documentation
• Construction of the Structure view is determined by the architectural description of the
system
• Construction of the Structure views corresponding to a particular architectural description
may involve additional information (system-specific or architecture-specific). This
information can be attached to KDM elements using stereotypes, attributes or annotations
Section 20.1, page 261 Conceptual architecture viewpoint
Concerns:
• What are the domain terms implemented by the system?
• What are the behaviour elements of the system?
• What are the business rules implemented by the system?
• What are the scenarios supported by the system?
Viewpoint language:
Conceptual views conform to KDM XMI schema The viewpoint language for the Conceptual
architectural viewpoint is defined by the Conceptual package. It includes abstract entitity
AbstractConceptualElement, and several concrete entities, such as TermUnit, FactUnit, RuleUnit, Scenario,
BehaviorUnit. The viewpoint language for the Conceptual architectural viewpoint also includes
ConceptualFlow relationship, which is a subclass of an abstract relationship
AbstractConceptualRelationship.
Analytic methods
The Conceptual architectural viewpoint supports the following main kinds of checking:
• Conceptual relationships (what are the relationships between conceptual entities, based
on their implementation by the Code and Data entities?)
• Scenario flow (what are the control flow relationship between the two scenarios based on
the flow between action elements referenced by each scenario)
• BehaviorUnit coupling (what are the control flow and data flow relationships between
two behaviour units based on the action elements referenced by each behaviour unit)
• Business Rule analysis (what is the logic of the business rule based on the action
elements referenced by the business rule)
Conceptual Views are used in combination with Code views, Data views, Platform views, UI
views and Inventory views.
Construction methods:
• Conceptual views can be produced manually using the input from the information
analysis and the architect of the system and architecture documentation
• Construction of the Conceptual view is determined by the domain model and the
architectural description of the system
• Construction of the Conceptual views corresponding to a particular architectural
description may involve additional information (system-specific or architecturespecific).
This information can be attached to KDM elements using stereotypes, attributes
or annotations
Section 21.1, page 279 Build architecture viewpoint
Concerns:
• What are the inputs to the build process? What artifacts are generated during the build process?
• What tools are used to perform build steps?
• What is the workflow of the build process?
• Who are the suppliers of the source artifacts?
Viewpoint language
Build views conform to KDM XMI schema The viewpoint language for the Build architectural
viewpoint is defined by the Build package. It includes abstract entity AbstractBuildElement, a generic
entity BuildResource as well as several concrete entities, such as BuildComponent, BuildStep,
BuildProduct, BuildDescription, Library. The viewpoint language for the Build architectural viewpoint also
includes several build relationships, which is a subclass of an abstract relationship
AbstractBuildRelationship.
Analytic methods
• Supply chain analysis (what are the artifacts that depend on a given supplier)
Build Views are used in combination with Inventory views.
Construction methods:
• Build views that correspond to the KDM Build architectural viewpoint are usually
constructed by analyzing build scripts and build configuration files for the given system.
This inputs are specific to the build automation framework. The Build extractor tool uses
the knowledge of the semantics of the build automation framework to produce one or
mode Build views as output
• Construction of the Build view is determined by the semantics of the build automation
framework, and it based on the mapping from the given build automation framework to
KDM; such mapping is specific only to the build automation framework and not to a
specific software system
• The mapping from a particular build automation framework to KDM may produce
additional information (system-specific, or platform-specific, or extractor tool-specific).
This information can be attached to KDM elements using stereotypes, attributes or
annotations

Existing software based systems have the relationship among packages. But this standard doesn't mention it precisely. (Conceptually, this shows package structure.)

Suggested resolution: Describe it using Package diagram.

No Data Available

Related to 8.2, paragraph 1, bullet 10

"Structure package defines the architectural components of existing application, subsystems, layers, packages, etc."

DIS should articulate how the Structure package supports common architectural concepts of architecture, architecture description, architecture viewpoint, architecture view, and architecture model per ISO 42010

Change sentence Page 12, Structure package defines the architectural components of existing
application, subsystems, layers, packages, etc.
into
Structure package defines meta-model elements that represent architectural components of
existing software systems, such as subsystems, layers, packages, etc. and define traceability of
these elements to other KDM facts.
Editorial changes to the other bullets of the list:
Change bullet:
The Source package defines the inventory of the physical artifacts of the existing software system and
references to the source code.
Into
The Source package defines meta-model elements that represent the inventory of the physical artifacts of
the existing software system and define the key traceability mechanism of KDM – how KDM facts
reference back to their original representation in the artefacts of the software system (for example, source
code).
Change bullet:
The Code package defines the low-level building blocks of application source files, such as procedures,
datatypes, classes, etc. (as determined by a programming language).
Into
The Code package defines meta-model elements that represent the low-level building blocks of software
such as procedures, datatypes, classes, variables, etc. (as determined by a programming language).
Change bullet:
Action package defines end points of relations, and the majority of KDM relations.
Into
Action package defines meta-model elements that represent s statements of software as the end points of
relations, as well as the majority of low-level KDM relations.
Change bullet: Platform package defines artifacts, related to the run time platform of the enterprise application.
Into
Platform package defines meta-model element that represent the run time resources used by the software
systems, as well as relationships determined by the run-time platform.
Change bullet:
UI package defines the user-interface aspects of the application.
Into
UI package defines meta-model element that represent the user-interface aspects of the application.
Change bullet:
Event package defines a common concept related to event-driven programming.
Into
Event package defines meta-model element that represent event-driven aspects of the software systems,
such as events, states, state transitions, as well as relations determined by the event-driven semantics of the
application’s run-time framework.
Change bullet:
Data package defines the persistent data aspects of an application.
Into
Data package defines meta-model elements that represent persistent data aspects of the software system.
Change bullet:
Conceptual package defines the domain-specific elements of an application.
Into
Conceptual package defines meta-model elements that represent the domain-specific elements of existing
software system.
Change bullet:
Build package defines the artifacts related to engineering of an application.
Into
Build package defines meta-model elements that represent the artefacts related to the build process of
the software system (including but not limited to the engineering transformations of the
“source code” to “executables”).

Related to section 7, paragraph 13, bullet 5

"KDM defines multiple hierarchies of entities via containers and groups." It is very difficult to read this sentence and accept the claim in 4 that there are no special terms in this document. Terms like GROUP, CONTAINER, HIERARCHY have ordinary language meanings, numerous technical meanings.

The DIS should define those terms it depends upon, either within the current document, or by reference to other standards (or if they ordinary language sense of these terms is intended) to a suitable dictionary

No Data Available

Related to section 7, paragraph 13, bullet 3

"KDM defines an ontology for describing existing software systems"

Clarify whether the intent is an ontology for systems or software assets of system. These are very different subject matters

Add to page 10 (ontology bullet), and move that bullet to the end of the list:
The ontology defined by KDM is related to the elements of existing software systems, and the
relationships between these elements, as well as the elements of the operational environment of
the software system. KDM ontology addresses both physical elements (for example, a procedure,
a variable, a table), which are originally represented by language-specific artifacts of the software
(for example source code), as well as logical elements (for example, user interface elements,
concepts that are implemented by the software, architectural components of the software, such
as layers, etc.)

Related to 19.1

"The Structure package defines constructs for defining the high level abstraction of the organization of a software system." Some might call this "architecture". If that is intent, the capabilities of this clause should be aligned with those of existing architecture standards such as ISO 42010, which has a rich ontology (and metamodel) of architectural "assets". Users of that standard should be able to model assets using this DIS, but there is no clear connection, and the current Structure package looks inadequate to conduct this modeling.

Align with ISO 42010, or explain why it is excluded from software assets of interest.

Change paragraph page 255, section 19.1:
Structure package defines constructs for defining the high level abstraction of the organization of a
software system. The Structure model constructs specify how the software’s divisions and subdivisions
down to the modules defined in the Code Package.
The form of the system may be presented as a single form or a set of layers components, subsystems, or
packages. The reach of this representation extends from a uniform architecture to entire family of modulesharing
subsystems.
The Structure model is a collection of StructuralElement instances.
Packages are the leaf elements of the Structure model, representing a division of a system’s Code Modules
into discrete, non-overlapping parts. An undifferentiated architecture is represented by a single Package.
StructuralGroup recursively gathers StructuralElements to portray various architectural divisions. The
Software System subclass provides a gathering point for all the system’s packages directly or indirectly
through other Structure elements. The packages may be further separated into Subsystems, Layers, and
Components, or Architecture Views.
Into
Structure package defines meta-model elements that represent architectural components
of existing software systems, such as subsystems, layers, packages, etc. and define
traceability of these elements to other KDM facts for the same system.
Change sentence page 255, section 19.1: Structure package defines constructs for
defining the high level abstraction of the organization of a software system. The Structure
model constructs specify how the software’s divisions and subdivisions down to the
modules defined in the Code Package.
Into Structure package defines meta-model elements that represent architectural components
of existing software systems, such as subsystems, layers, packages, etc. and define
traceability of these elements to other KDM facts for the same system. Structure model
defines an architectural viewpoint. The architectural views based on the viewpoint
defined by the Structure model represent how the structural elements of the software
system are related to the modules defined in the Code views that correspond to the Code
architectural viewpoint defined by the Code model. The architectural viewpoint is
defined as follows.
This text will be followed by the definition of the Structural architecture viewpoint from
the resolution to issue 13301.
Add the following paragraphs to the end of section 19.1
The organization of the system may be presented as a single Structure view or a set of multiple Structure
view showing layers, components, subsystems, or packages. The reach of this representation extends from
a uniform architecture to entire family of module-sharing subsystems.
The Structure model owns a collection of StructuralElement instances.
Packages are the leaf elements of the Structure model, representing a division of a system’s Code Modules
into discrete, non-overlapping parts. An undifferentiated architecture is represented by a single Package.
StructuralGroup recursively gathers StructuralElements to represent various architectural divisions. The
Software System subclass provides a gathering point for all the system’s packages directly or indirectly
through other Structure elements. The packages may be further grouped into Subsystems, Layers, and
Components, or Architecture Views.

Related to 11.1

"Engineering view", logical view" and "developers view" should be defined

Views should have definitions USUALLY as viewpoints

Remove references to these “views” (they are actually viewpoints, according to ISO 42010), since
each KDM model explicitly defines an architecture viewpoint.
Engineering view:
Editorial changes are provided as part of the resolution to issue 13296
Logical view:
Editorial changes are provided as part of the resolution to issue 13296
Developers view:
Change sentence Page 113, Ignore the generated primary code, provide a high-fidelity representation to
the embedded construct; the embedded construct is the origin and the target of KDM relationships; some
details of how the embedded construct is expanded into the primary code may not be recovered from the
KDM representation (but in general, the embedded construct provides a better representation, since it is the
view that developers have).
Into
Ignore the generated primary code, provide a high-fidelity representation to the
embedded construct; the embedded construct is the origin and the target of KDM
relationships; some details of how the embedded construct is expanded into the primary
code may not be recovered from the KDM instance (but in general, the embedded
construct provides a better choice, since it is the constructs introduced by the developer).

Related to clause 1.

Suggested resolution:

Remove the following statement from scope.

"The primary purpose of this meta-model is to provide a common interchange format that will allow interoperability between existing modernization and software assurance tools, services, and their respective intermediate representations."

Section 1 Scope: change ‘to provide’ into ‘to enable’:
"The primary purpose of this meta-model is to enable a common
interchange format that will allow interoperability between existing
modernization and software assurance tools, services, and their
respective intermediate representations.
In Section 2. Conformance add the following:
KDM is defined via Meta-Object Facility (MOF). KDM defines the
interchange format via the XML Metadata Interchange (XMI) by applying
the standard MOF to XMI mapping to the KDM MOF model. The interchange
format, defined by KDM is called the KDM XMI schema. The KDM XMI schema
is provided as the normative part of this specification."
Also make the following editorial clarifications.
EDITORIAL COMMENT: these edits are made to the conformance paragraph
change:
The primary goal of KDM is to provide the capability to exchange models between tools and thus facilitate
cooperation between tool suppliers by allowing integration information about a complex enterprise
application from multiple sources, as the complexity of modern enterprise applications involves multiple
platform technologies and programming languages.
Into
The primary goal of KDM is to provide the capability to exchange models between tools and thus facilitate
cooperation between tool suppliers to integrate multiple facts about a complex enterprise application from,
as the complexity of modern enterprise applications involves multiple platform technologies and
programming languages. Remove sentence:
Consequently, the definition of compliance for KDM requires a balance to be drawn between modularity
and ease of interchange

would like to report another inconsistency detected in the KDM specification v1.0 owned ADM effort.
In this case is the Build Package in Abstract Layer (page 280-281). In BuildModel Class Diagram (in page 280) there is an element so-called “Supplier”. However, in page 281 this element is not depict, but a new element so-called “Origin” is depict. I think that both elements are the same element.

Change text of section 21.3.4 page 281 from
“ 21.3.4 Origin Class
The Origin class models producers of the 3rd party software components as they contribute to the
build process.”
Into
“ 21.3.4 Supplier Class
The Supplier class models producers of the 3rd party software components as they contribute to
the build process.”

Related to 19.3.8

"The ArchitectureView class represents a logical packaging of the architectural artifacts related to a particular view of a software system."

The terminology herein should be aligned to use terms from ISO/IEC 42010:2007, as we can see substantial alignment.

In addition to alignment on terms, it would be A Good Thing for the developers of this document to look at the draft 42010:20xx, to understand the emerging requirements on Architecture Frameworks. DIS 19506 could well be positioned as an Architecture Framework that conforms to the requirements in the revision of ISO/IEC 42010.

ArchitectureView class should have attributes with those in the 42010 conceptual model: a corresponding Architectural Viewpoint (which also must be an ArchitectureElement in the present DIS, see Clause 5.3); Identifier, Purpose; and its contained Architecturl Models (see Clause 5.4).

Page 258: Change
19.3.8 ArchitectureView Class
The ArchitectureView class represents a logical packaging of the architectural artifacts related to a
particular view of a software system.
Superclass StructureGroup
Semantics
To:
19.3.8 ArchitectureView Class
The ArchitectureView class represents an arbitrary architecture view, as defined by ISO 42010
Architectural View. The KDM ArchitectureView class is a collection of KDM entities that correspond to a
particular architectural view of a software system. To conform to the ISO 42010 requirements for
architectural description, the creator of the KDM model shall further document the viewpoint used (as a a
stereotype to the ArchitectureView class, attributes or annotations).
Superclass StructureGroup
Semantics

Related to clause: 4.5

Suggested resolution: Remove the clause "4 Terms and definitions" and "5 Symbols".

No Data Available

Related to clause: 3

The following standard must be refered.

• XMI ISO/IEC19503

• MOF ISO/IEC19502

• ISO/IEC11404

• SBVR

Suggested resolution:

ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)

ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)

ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)

Semantics of Business Vocabulary and Business Rules (SBVR) available at http://www.omg.org/spec/SBVR/1.0/PDF

Change list of references in section 3 “Normative references” into:
• OMG UML 2.2 Infrastructure Specification formal/2009-02-04
• OMG Meta-Object Facility (MOF) ver. 2.0 formal/2006-01-01
• OMG Semantics of Business Vocabularies and Business Rules (SBVR) Ver 1.0 formal/08-01-
02
• ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
• ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
• ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)
Disposition: Resolved

Related to clause 2.2

"There are two KDM compliance levels:" But there are three level:L0, L1, L2.

Suggested resolution: "There are Three KDM compliance levels:"

Section 2.2 Compliance levels: change
"There are two KDM compliance levels:"
into
"There are three KDM compliance levels:"

Related to clause: 2

The compliance of this standard assume common interchange format between tools. But this standard doesn't define it. Thus remove it.

Suggested resolution: Remove the clause "2 compliance".

No Data Available

Overall comments – I found it somewhat confusing to have differences between items just dependent
on case (e.g. KDM package and kdm package, Core and core, etc.) when the items refer to very
different things. This occurs with several things. Not sure whether this can be fixed or made more

clear as to the distinction, but it was a source of confusion for me in reading it.

Page 4 “L0 compliance point” replace “as defined in the Kdm package” into “as defined in the
package named “kdm” (in 2 columns)
Page 7 top replace “Chapter 10. KDM package” into “Chapter 10. The Package named “kdm””
Page 15: replace
“In particular, each KDM package depends on the Core package” into “In particular, each
package depends on the Core package”.
Replace “Also, each package depends on the kdm package” into “Also, each package depends
on the package with name “kdm”.
Replace “Each KDM package above the kdm package defines a KDM Model,…” Into “Each
package above the package with name “kdm” in Figure 8.1 defines a viewpoint,…”.
Replace “The Kdm package provides the infrastructure for all KDM models.” Into “The package
with name “kdm” provides the infrastructure for all viewpoints.”
Replace “The nature of the dependency on the kdm package is twofold. First each package
defines a subclass of the KDMModel class defined in the kdm package. Second, each kdm
package provides several concrete classes that are instantiated in each KDM representation as
part of the infrastructure. Kdm package defines several important mechanisms that are used by
all KDM models: the annotation mechanism, the mechanism of user-defined attributes, and the
light-weight extension mechanism. The meta-model elements that support these mechanisms
can be instantiated by any KDM model.” Into
“The nature of the dependency on the package with name “kdm” is as folllowes. First each
package defines a subclass of the KDMModel class defined in that package. Second, each
package provides several concrete classes that are instantiated in each KDM instance as part of
the infrastructure. Third, the package with name “kdm” defines several important mechanisms
that are used by all KDM models: the annotation mechanism, the mechanism of user-defined
attributes, and the light-weight extension mechanism. The corresponding meta-model elements
can be instantiated by any KDM model.”
Page 16: replace “The Kdm package provides static context shared by all KDM models.” Into
“The package with name “kdm” provides shared context for all KDM models”.
Page 13 (page 43 of the ptc2009-06-05 – looks like there is a glitch in page numbers)
Replace “The kdm package defines several elements that together constitute the framework of
each KDM representation” into “The package with name “kdm” defines several elements that
together constitute the framework of each KDM instance”
Page 14 Replace “for which the KDM representation is created” into “For which the KDM views
are created”
Page 15 (section 9.2) replace “The KDM uses packages” into “The KDM specification uses
packages”
Replace “The KDM Core package consists” into “The Core package consists”
Page 17 (page 47 of the ptc2009-06-15, 2nd line) replace “defined in the kdm package” into
“defined in the package named “kdm” Page 25, change title of section 10 from “KDM Package” into “The Package named “kdm” “
Page 25 (section 10.1) 1st paragraph replace “The Kdm package defines” into “The package with
name “kdm” defines”
Same paragraph: Replace “KDM representations” into “KDM views” (2 times)
Replace “are instances of the KDM (which is a meta-model)” into “are collections of the elements
that are instances of the meta-model elements defined by the KDM specification”.
Section 10.1 paragraph 2: Replace “Kdm package describes” into “The package named “kdm”
describes”
Change title of 10.2 into “Organization of the KDM framework”
Replace “The Kdm package is a collection “ into “The package with name “kdm” is a collection”
In the last paragraph on page 25 replace “The Kdm package consists” into “The package with
name “kdm” consists”
Replace “of the kdm framework” into “of the KDM framework”
Page 12 replace “Core, kdm and Source. Core and kdm packages” into “Core, “kdm” and Source.
The Core package and the package named “kdm” “
Page 26 replace “The Kdm package depends” into “The package with name “kdm” depends”
Page 27 replace “Each KDM Framework is the container” into “These elements are containers”
Change index: replace 2 items “KDM package 9” and “Kdm package 25” with “Package named
“kdm” 9,25
Page 13 (page 43 of PDF) Change “of one of the core classes” into “of one of the classes defined
in the Core package”
Replace “Small KDM Core” into “The Core package”
Page 15 replace “Core KDM package” into “The Core package”
Page 129 delete duplicate “Core” bullet
Page 145 replace “with the core” into “with the code”
Page 186 (page 223 of the PDF) replace “subclass core meta-model elements from the KDM
Core package” into “are related to the meta-model elements defined in the Core package”
Page 198 17.4 replace “inherit core meta-model classes from KDM Code package” into “inherit
meta-model elements from the Core package”.
Page 210 replace “various data classes derive from the Core KDM classes” into “the meta-model
elements defined in the Data package are related to the meta-model elements defined in the
Core package”
Replace “KDM Core package” into “Core package”
Page 259 replace “various data classes are types of Core KDM classes” into “the meta-model
elements of the Structure package are related to the meta-model elements of the Core package.”
Replace “KDM classes defined within the KDM Core package” into “meta-model elements defined
in the Core package”
Page 282 replace “in the KDM Core package” into “in the Core package”
Disposition:

As currently specified in the build package, in figure 21.3 the BuildDescription has a relation to SourceRef with the containment side with a 1 specified. This is forcing any SourceRef to actually have a BuildDescription attached or else it won’t validate. This be 0..1. At the same time, the relationship to SourceRef should originate from BuildResource rather than only from BuildDescription in order for identifying BuildStep for example.

Suggested resolution: change multiplicity to 0..1

Change the origin of the relationship to SourceRef from BuildDescription to BuildResource.

No Data Available

Several association ends are both 0..* and composite owners. This is not only an invalid combination but is inconsistent with the specification document and Rose model used for that. This seems to affect the ends that

have isComposite='false'
For example, the above line 172 would become:
<ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='false' association='A.35' />

Change the clause isComposite=’true’ into isComposite=’false’ in the following lines (provided
below in the context of their Class owner) in the file kdm_1.1.cmof.xml:
<ownedMember xmi:id='C.22840242' xmi:type='cmof:Class'
name='BuildResource' superClass='C.14056260' isAbstract='false' >
<ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917'
name='implementation' lower='0' upper='*' isComposite='true'
association='A.35' />
<ownedAttribute xmi:id='P.O.13254846' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.14056260' name='groupedBuild' lower='0' upper='*' isComposite='true'
association='A.37' />
</ownedMember>
<ownedMember xmi:id='C.21360255' xmi:type='cmof:Class'
name='NamespaceUnit' superClass='C.7475352' isAbstract='false' >
<ownedAttribute xmi:id='P.O.6893036' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.7475352'
name='groupedCode' lower='0' upper='*' isComposite='true'
association='A.80' />
</ownedMember>
<ownedMember xmi:id='C.2688299' xmi:type='cmof:Class'
name='AbstractConceptualElement' superClass='C.19792917'
isAbstract='true' >
<ownedAttribute xmi:id='P.O.20416442' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917'
name='implementation' lower='0' upper='*' isComposite='true'
association='A.104' />
</ownedMember>
<ownedMember xmi:id='C.12349885' xmi:type='cmof:Class'
name='IndexElement' superClass='C.16116684' isAbstract='false' >
<ownedAttribute xmi:id='P.O.9068636' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.30064779'
name='implementation' lower='0' upper='*' isComposite='true'
association='A.115' />
</ownedMember>
<ownedMember xmi:id='C.25797638' xmi:type='cmof:Class'
name='DataAction' superClass='C.27225657' isAbstract='false' >
<ownedAttribute xmi:id='P.O.18189246' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.8621536'
name='implementation' lower='0' upper='*' isComposite='true'
association='A.126' />
</ownedMember>
<ownedMember xmi:id='C.12180601' xmi:type='cmof:Class'
name='AbstractEventElement' superClass='C.19792917' isAbstract='true' >
<ownedAttribute xmi:id='P.O.15209872' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.32333114'
name='implementation' lower='0' upper='*' isComposite='true'
association='A.151' />
</ownedMember>
<ownedMember xmi:id='C.3554254' xmi:type='cmof:Class'
name='AbstractPlatformElement' superClass='C.19792917' isAbstract='true'
>
<ownedAttribute xmi:id='P.O.23393515' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.32333114'
name='implementation' lower='0' upper='*' isComposite='true'
association='A.175' />
</ownedMember> <ownedMember xmi:id='C.13266771' xmi:type='cmof:Class'
name='DeployedSoftwareSystem' superClass='C.3554254' isAbstract='false'
>
<ownedAttribute xmi:id='P.O.31436981' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.31179076'
name='groupedComponent' lower='0' upper='*' isComposite='true'
association='A.185' />
</ownedMember>
<ownedMember xmi:id='C.31179076' xmi:type='cmof:Class'
name='DeployedComponent' superClass='C.3554254' isAbstract='false' >
<ownedAttribute xmi:id='P.O.29921964' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.28336930'
name='groupedCode' lower='0' upper='*' isComposite='true'
association='A.188' />
</ownedMember>
<ownedMember xmi:id='C.32002033' xmi:type='cmof:Class'
name='AbstractStructureElement' superClass='C.19792917'
isAbstract='true' >
<ownedAttribute xmi:id='P.O.14191483' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917'
name='implementation' lower='0' upper='*' isComposite='true'
association='A.202' />
</ownedMember>
<ownedMember xmi:id='C.26598825' xmi:type='cmof:Class'
name='AbstractUIElement' superClass='C.19792917' isAbstract='true' >
<ownedAttribute xmi:id='P.O.14454637' xmi:type='cmof:Property'
isOrdered='false' subsettedProperty='P.O.6222315' type='C.32333114'
name='implementation' lower='0' upper='*' isComposite='true'
association='A.209' />
</ownedMember>
These are all associations that follow the “group association” pattern
of KDM. This change is performed automatically in the process of
converting the UML Rose diagrams into CMOF. The unique ids of the cmof
elements may change during the conversion.

Many associations and association ends are given meaningless generated names, like A.0, P.G.307. Since these will be used for the generated language bindings, and are required for traversing and accessing models, these names are not usable. In addition, the inclusion of '.'s in the names makes unnecessary for language bindings since they are not valid Java names.

For example lines 4 and 5 illustrate the names:
<ownedMember xmi:id='A.2' xmi:type='cmof:Association' memberEnd='P.O.14122707 P.D.14122707' name='A.2' general='A.3'>
<ownedEnd xmi:id='P.D.14122707' xmi:type='cmof:Property' subsettedProperty='P.D.29853041' type='C.8621536' name='P.D.14122707' lower='1' upper='1' isComposite='false' association='A.2' />

Proposed resolution:
Generate meaningful names for these elements, using the same algorithm as UML2, which is as follows (from section 6.4 of formal/07-11-02)

• If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached,
  modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are
  often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal
  constraints - although they may be needed for other purposes, such as MOF language bindings that use the metamodel.)

• Associations that are not explicitly named, are given names that are constructed according to the following production
  rule: "A_" <association-end-name1> "_" <association-end-name2>
  where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of
  the second association end.

As an example, lines 4 and 5 would become:
<ownedMember xmi:id='A.2' xmi:type='cmof:Association' memberEnd='P.O.14122707 P.D.14122707' name='A_actionElement_actionRelation' general='A.3'>
<ownedEnd xmi:id='P.D.14122707' xmi:type='cmof:Property' subsettedProperty='P.D.29853041' type='C.8621536' name='actionElement' lower='1' upper='1' isComposite='false' association='A.2' />

Resolution:
Proposed resolution:
Change the rules for converting the UML Rose diagram into CMOF xml file to generate
meaningful names for unnamed association endpoints and associations.
1. If an association end is unlabeled, the default name for that end is the name of the
class to which the end is attached,
modified such that the first letter is a lowercase letter. In addition, if the name of
the class to which the end is attached starts has a meaningful prefix of uppercase
letters, for example XMLxxxx, KDMxxx, UIxxxx, the entire uppercase prefix is
modified to become lowercase. For example, the above words become xmlxxxx,
kdmxxx, uixxxx.
2. Unlabeled association end points at the KDM Entity side which correspond to
KDM Relationships are additionally prefixed with “in” or “out” according to the
direction of the relationship. The corresponding properties at the KDM
Relationship class side as "to" and "from". For example, association ends for the
ActionElement class corresponding to the associations to ControlFlow class are
named “inControlFlow” (the counterpart of the “to” endpoint from the
ControlFlow side) and “outControlFlow” (the counterpart of the “from” endpoint
from the ControlFlow side).
3. Associations that are not explicitly named, are given names that are constructed
according to the following production
rule: "A_" <association-end-name1> "_" <association-end-name2>
where <association-end-name1> is the name of the first association end and
<association-end-name2> is the name of
the second association end.
The unique ids of the cmof elements may change during the conversion.

Association A.62 has an owned end is called 'model ' (trailing space), which is inconsistent and invalid for generating language bindings

Proposed resolution
Remove the trailing space

Line 347 is currently:
<ownedEnd xmi:id='P.D.11368610' xmi:type='cmof:Property' subsettedProperty='P.D.7559765' type='C.13301479' name='model ' lower='0' upper='1' isComposite='false' association='A.62' />
And should become
<ownedEnd xmi:id='P.D.11368610' xmi:type='cmof:Property' subsettedProperty='P.D.7559765' type='C.13301479' name='model' lower='0' upper='1' isComposite='false' association='A.62' />

No Data Available

The file is invalid XML, since for the 'type' attribute of Operations it omits spaces after the closing quote of the previous value.
For example line 784 is:
<ownedOperation xmi:id='OP.28195661' xmi:type='cmof:Operation' name='getInbound' lower='0' upper='*'type='C.6698801' />

Proposed resolution
Insert space before 'type=' in all Operation definitions. The above line becomes:
<ownedOperation xmi:id='OP.28195661' xmi:type='cmof:Operation' name='getInbound' lower='0' upper='*' type='C.6698801' />

In the kdm_1.1.cmof.xml correct the following 11 occurences of “ownedOperation” by
inserting a space between “upper” clause and “type” clause. This is implemented as part
of the automatic conversion from UML Rose diagrams into CMOF, so the unique ids of
cmof elements may change.
<ownedOperation xmi:id='OP.28195661' xmi:type='cmof:Operation'
name='getInbound' lower='0' upper='*'type='C.6698801' />
<ownedOperation xmi:id='OP.28796973' xmi:type='cmof:Operation'
name='getOutbound' lower='0' upper='*'type='C.6698801' />
<ownedOperation xmi:id='OP.1602470' xmi:type='cmof:Operation'
name='getOwnedRelation' lower='0' upper='*'type='C.6698801' />
<ownedOperation xmi:id='OP.22060939' xmi:type='cmof:Operation'
name='getInAggregated' lower='0' upper='*'type='C.1688690' />
<ownedOperation xmi:id='OP.1735173' xmi:type='cmof:Operation'
name='getOutAggregated' lower='0' upper='*'type='C.1688690' />
<ownedOperation xmi:id='OP.4259620' xmi:type='cmof:Operation'
name='getOwner' lower='0' upper='1'type='C.19792917' /> <ownedOperation xmi:id='OP.19831230' xmi:type='cmof:Operation'
name='getOwnedElement' lower='0' upper='*'type='C.19792917' />
<ownedOperation xmi:id='OP.7316011' xmi:type='cmof:Operation'
name='getGroup' lower='0' upper='*'type='C.19792917' />
<ownedOperation xmi:id='OP.16772004' xmi:type='cmof:Operation'
name='getGoupedElement' lower='0' upper='*'type='C.19792917' />
<ownedOperation xmi:id='OP.29851750' xmi:type='cmof:Operation'
name='getModel' lower='0' upper='1'type='C.31431715' />
<ownedOperation xmi:id='OP.12504936' xmi:type='cmof:Operation'
name='getTo' lower='1' upper='1'type='C.19792917' />
<ownedOperation xmi:id='OP.19054722' xmi:type='cmof:Operation'
name='getFrom' lower='1' upper='1'type='C.19792917' />

In the mapping for COBOL the code model uses action elements that correspond to various resource packages (in particular, Data, UI, Platform). These action elements are not exactly system calls, so from the micro KDM perspective they should have distinct kinds, at least saying that they represent resource actions. Otherwise the model can not be compliant to micro KDM.

Add section A.11 Actions related to Resources
Resource micro-actions represent specific statements that are determined by some programming
languages and which manipulate resources provided by the operating environment. Such
statements are alternative to using system calls. Kinds in Table A.11 represent such statements
as micro KDM ActionElements. Precise semantics of representing the operating environment is
described in Part 3 Runtime Resource Layer. In particular, a combination of resource actions,
resource relationships and resource events can be used, where the resource micro-action is part
of a Code Model, while other elements can be added in various models of the Resource Layer
(Platform, Data, Event or UI).
Inputs: Zero or more Reads relationships to DataElements; represent input data which is
sent to the resource; ordered
Outputs: Zero or more Writes relationships to DataElements; represents output data which
is received from the resource;
Control: optional single Flow to the next micro action (no Flow means a terminal action
element).
Extras: optional resource-specific relationships
Table A.11 Resource Actions
Micro Action Description
Platform ActionElement represents a
statement that manipulates a
Platform Resource
Data ActionElement represents a
statement that manipulates a
Data Resource
Event ActionElement represents a
statement that manipulates an
Event Resource UI ActionElement represents a
statement that manipulates a
UI Resource
Disposition: Resolved

Currently the BindsTo relationship has the ResourceType as its “from” endpoint and another ResourceType as its “to” endpoint. As the result there is a lack of capability to capture binding of logical resources to their physical counterparts (such as files in the inventory model).

Suggested resolution: generalize the “to” endpoint of the BindsTo relationship to KDMEntity class.

No Data Available

Signature and SourceFile are used as both Class and Association names in the same package: this is not permitted by CMOF constraints

Proposed resolution
Rename these associations to SignatureType and SourceFileRegion respectively

Line 256 is currently:
<ownedMember xmi:id='A.25972044' xmi:type='cmof:Association' memberEnd='P.G.94 P.G.95' name='Signature'>
And should become
<ownedMember xmi:id='A.25972044' xmi:type='cmof:Association' memberEnd='P.G.94 P.G.95' name='SignatureType'>

Line 1083 is currently:
<ownedMember xmi:id='A.30564957' xmi:type='cmof:Association' memberEnd='P.G.264 P.G.265' name='SourceFile'>
And should become:
<ownedMember xmi:id='A.30564957' xmi:type='cmof:Association' memberEnd='P.G.264 P.G.265' name='SourceFileRegion'>

No Data Available

The CMOF and XMI namespaces are incorrect (they include an extra 'www')
Line 1 of the file is:
<XMI xmlns:xmi="http://www.schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://www.schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1">

Proposed resolution
Include correct namespace definitions, so that the above line becomes:
<XMI xmlns:xmi="http:// schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1">

In file kdm_1.1.cmof.xml change line
<XMI xmlns:xmi="http://www.schema.omg.org/spec/XMI/2.1"
xmlns:cmof="http://www.schema.omg.org/spec/MOF/2.0/cmof.xml"
xmi:version="2.1">
Into
<XMI xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1">
This is implemented as part of the automatic conversion from UML Rose diagrams into CMOF.

Related to section 4

Unable to determine intended scope of this standard without a definition of "software asset". Does it intend to cover information items as defined in ISO 15289?

Define "software asset". Clarify which information items and work products specified in ISO 15289 are included within the scope of this DIS.

In the following editing instructions, the occurrences of terms in the original sentences are highlighted, and
the changes are underlined.
Change sentence Page 1. This specification defines a meta-model for representing existing software assets,
their associations, and operational environments, referred to as the Knowledge Discovery Meta-model
(KDM).
Into:
This specification defines a meta-model for representing existing software, its elements, associations, and
operational environments, referred to as the Knowledge Discovery Meta-model (KDM).
Change sentence Page 1. One common characteristic of various tools that address SwA and ADM
challenge is that they analyze existing software assets (for example, source code modules, database
descriptions, build scripts, etc.) to obtain explicit knowledge.
Into
One common characteristic of various tools that address SwA and ADM challenge is that they analyze
existing software artifacts (for example, source code modules, database descriptions, build scripts, etc.) to
obtain explicit knowledge..
Change sentence page 1: Each tool produces a portion of the knowledge about existing software assets.
Such tool-specific knowledge may be implicit (“hard-coded” in the tool), restricted to a particular source
language, and/or particular transformation, and/or operational environment.
Into:
Any tool that operates on existing software produces some portion of the knowledge about the
given software system. However, such tool-specific knowledge may not be exported in any
explicit format. For example, such knowledge may be used internally by the tool: a compiler
generates precise knowledge about a compilation unit only to discard it as soon as the object file is generated. Tool-specific knowledge may be limited in scope, restricted to a particular source
language and/or particular transformation, and/or particular operational environment.
Change sentence Page 1. The meta-model for Knowledge Discovery provides a common repository
structure that facilitates the exchange of data contained within individual tool models that represent existing
software assets. The meta-model represents the physical and logical assets at various levels of abstraction.
Into
The meta-model for Knowledge Discovery provides a common ontology and an interchange format that
facilitates the exchange of data contained within individual tool models that represent existing software.
The meta-model represents the physical and logical elements of software as well as their relations at
various levels of abstraction.
Change Page 9. section 7. This specification defines a meta-model for representing information related to
existing software assets, their associations, and operational environments (referred to as the Knowledge
Discovery Meta-model (KDM)).
Into
This specification defines a meta-model for representing information related to existing software, its
elements, associations, and operational environments (referred to as the Knowledge Discovery Meta-model
(KDM)).
Change sentence Page 9. section 7. More specifically, (KDM) provides a common repository structure that
facilitates the exchange of data currently contained within individual tool models that represent existing
software assets. The meta-model represents the physical and logical software assets at various levels of
abstraction as entities and relations.
Into
More specifically, (KDM) defines a common ontology and an interchange format that facilitates the
exchange of data currently contained within individual tool models that represent existing software. The
meta-model represents the physical and logical elements of software as well as their relations at various
levels of abstraction.
EDITORIAL NOTE: For traceability purposes the following minor edits are marked as Block 2 in
the specification text with changebars
Section 10.1 change “application” into “system”
KDM instance is not a model that represents constraints, like the ones used during the design phase, rather,
this is an intermediate representation that captures precise knowledge about the system.
Section 10.1 change “artifacts” to “elements”
The remaining KDM packages provide meta-model elements that represent various elements of
existing systems.
Section 11.1
The Source package also represents traceability links between instances of KDM meta-elements
and the regions of source code, which is represented by these meta-model elements.

Related to section 4

It is hard to believe that there are "no special terms or definitions in this specification", since usage of a number of terms in this DIS seem to have no relationship to other, more common usages of those same terms.

Define the terms that have specialzed meanings or usage in this DIS. ISO/IEC 42010:2007 provides a well established ontology for describing architectures of various types, presumably including "Architecture Driven Modernization" senses of "Architecture". For the architecture-related terms, architecture, architecture description, architecture view, architecture viewpoint and architecture model, adopt the defintions from ISO/IEC 42010:2007

Section 4, Page 6 “Terms and Definitions”
Replace sentence “There are no special terms or definitions in this specification.”
with the following text:
This subclause contains only those terms which are used in a specialised way throughout the
KDM specification. The majority of terms in KDM are used either according to their
accepted dictionary definitions or according to commonly accepted definitions that may be
found in ISO glossaries or other well-known collections of software engineering terms. Some
combinations of common terms used in KDM, while not meriting glossary definition, are
explained for clarity in the context where they are used.
Abstraction: A view of an object that focuses on the information relevant to a particular
purpose and ignores the remainder of the information.
Aggregation: a derived relationship between two elements that are groups of other
elements that represents all individual relationships between the grouped elements of the
two groups.
Architecture-Driven Modernization (ADM): ADM is the process of understanding and
evolving existing software assets of a system of interest. ADM focuses at collecting,
sharing, utilizing, transforming, presenting, maintaining and storing models of the
architectural aspects of existing systems. ADM does not preclude source-to-source
migrations (where appropriate), but encourages user organizations to consider
modernization from an analysis and design perspective. In doing so, project teams ensure
that obsolete concepts or designs are not propagated into modern languages and
platforms. Build: An operational version of a system or component that incorporates a specified
subset of the capabilities that the final product provides.
Build process: a process of transforming of project code base into usable applications.
The end result of a software build is a collection of files that consitute a product in a
distributable package. In this case, package can mean a standalone application, Web
service, compact disc, hotfix, or bug fix. Each step of a build process is a transformation
performed by software running on a general purpose computer. A simple software build
may involve compiling a single source code file into an executable code. A complex
software build may involve orchestrating hundreds of versions of thousands of files with
millions of lines of source code such that a correct executable code results from the
compilation. The implementation of a system also involves deploying the build onto the
system nodes, and applying appropriate configuration settings.
Component: a functionally or logically distinct part of a system. A component may be
hardware or software and may be subdivided into other components. Often a component
is a physical, replaceable part of a system that packages implementation and provides the
realization of a set of interfaces. Such component represents a physical piece of
implementation of a system, including software code (source, binary or executable) or
equivalents such as scripts or command files.
Container: a model element that owns one or more distinct elements through the special
“owns” (“contains”) relationships between the container element and owned elements.
“Containment” relationships form a special group of the corresponding owned elements.
No element has more than one container.
Domain : An area of knowledge or activity characterized by a set of concepts and
terminology understood by practitioners in that area.
Element: one of the parts of a compound or complex whole. For example, a model
element, a meta-model element.
Group: a number of model elements regarded as a unit formed by traceability
relationships to a single distinct element. An element may be part of multiple groups,
including a single group formed by the “containment” relationships between a container
and its owned elements. An element is said to group together one or more elements, if
these elements have traceability relationships to the element.
Hierarchy: an arrangement of model elements according to traceability relationships,
where an element that “owns” or “group” other elements is considered at a higher level
than the owned (grouped) elements.
Interface: (1) a shared boundary or connection between two dissimilar objects, devices or
systems through which information is passed. The connection can be either physical or
logical. (2) a named set of operations that characterize the behavior of an entity
Item: that which can be individually described or considered. See also Component,
Element, Unit, Module. KDM Entity: a meta-model element (as well as the corresponding model elements) that
represents a thing of significance of the system of interest, about which information needs
to be known or held. A KDM entity is an abstraction of some element of the system of
interest that has a distinct, separate existence objective or conceptual reality, a selfcontained
piece of data that can be referenced as a unit. As a model element each KDM
entity is an instance of some specific meta-model element and it usually the endpoint of
distinct KDM relationships.
KDM instance: a collection of KDM model elements that represent one or more views of
the system of interest.
KDM model: a meta-model element (as well as the corresponding model elements) that is
a container for a KDM view
KDM Relationship: a meta-model element (as well as the corresponding model elements)
that represents some semantic association between elements of the system of interest. All
KDM relationships are binary. As a model element each KDM relationship is an instance
of some specific meta-model element.
Meta-model: A special kind of model that specifies the abstract syntax of a modeling
language. The typical role of a metamodel is to define the semantics for how model
elements in a model get instantiated. A model typically contains model elements. These
are created by instantiating model elements from a metamodel, i.e., metamodel elements.
Meta-model element: an element of a meta-model from which model elements are
instantiated.
Model: A model represents a system of interest, from the perspective of a related set of
concerns. The model is related to the system by an explicit or implicit isomorphism.
Models are instances of MOF meta-models and therefore consist of model elements and
links between them.
Model element: instance of a meta-model element
Module. (1) A program unit that is discrete and identifiable with respect to compiling,
combining with other units, and loading; for example, the input to, or output from, an
assembler, compiler, linkage editor, or executive routine. (2) A logically separable part of
a program.
Resource: any physical or virtual component of limited availability within a computer
system available for a given purpose and managed by the runtime platform.
Runtime platform: the set of hardware and software components that implement the
services utilized by the application software. A runtime system generally controls how
several tasks are scheduled to run, and manages resources. Its provisions for the
programmer typically form an Application Programming Interface— a set the welldocumented
ways of using the system.
Segment: A collection of data that corresponds to one or more coherent views of a
system of interest that is stored or transferred as a unit. Software artifact: A software artifact is a tangible machine-readable document created
during software development. Examples are requirement specification documents, design
documents, source code and executables.
Software asset: A software asset is a description of a partial solution (such as a
component or design document) or knowledge (such as requirements database or test
procedures) that engineers use to build or modify software products. A software asset is a
set of one or more related artifacts that have been created or harvested for the purpose of
applying that asset repeatedly in subsequent contexts. The asset consumer is an architect
or a designer of any type of IT or business process solutions from solution business
modeling, analysis (assets used are models) and design to application development
(assets used are pieces of code).
Traceability: The degree to which a relationship can be established between two or more
products of the development process, especially products having a predecessor-successor
or master-subordinate relationship to one another; for example, the degree to which the
requirements and design of a given software component match.
Unit : (1) a piece or complex of apparatus serving to perform one particular function (2) A
software element that is not subdivided into other elements.
User interface: An interface that enables information to be passed between a human user
and hardware or software components of a computer system.
View: A representation of a whole system from the perspective of a related set of
concerns.
Viewpoint: A specification of the conventions for constructing and using a view. A
pattern or template from which to develop individual views by establishing the purposes
and audience for a view and the techniques for its creation and analysis.

Related to section 7, paragraph 3

"ADM KDM separates knowledge about existing systems into several orthogonal facets that are well-known in software engineering and are often referred to as Architecture Views."

Clarify usage of view. if Architectural View is intended, following rules of ISO 42010 to enable readers understand intent.

Editorial changes to the text of the specification related to the resolution of this issue are part of
the resolution to another issue 13296
Disposition: Duplicate

Related to section 4

"View" is used in a number of context. Sometimes as "architectural view" other times, unclear

Clarify when "architecture view" in intended, and use ISO 42010 definition. If "database view" is meant (which is a very different notion); make that clear. If both notions are needed; qualify each usage.

The resolution to this issue involves the following editorial changes:
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 1 in the editorial note in the specification text with changebars
Change sentence Page 6: Chapter 11. Source package - This package describes meta-model elements
for specifying the linkage between the KDM model artifacts and their physical implementations in the
artifacts of existing software. Elements of the Source package allow viewing the source code,
corresponding to KDM model elements.
Into:
Chapter 11. Source package – Describes meta-model elements that provide traceability
from KDM facts to the original representation of the software item (for example, the
source code).
Change sentence Page 7 Chapter 20. Conceptual package - Describes the meta-model elements for
representing business domain knowledge about existing applications in the context of other KDM views.
Into
Chapter 20. Conceptual package – Describes meta-model elements that represent facts
related to the business domain of the existing system and provide traceability to other
KDM facts.
Change sentence Page 7: Chapter 21. Build package - Describes the meta-model elements
for representing the artifacts involved in building the software system (the engineering
view of the software system).
Into: Chapter 21. Build package - Describes the meta-model elements that represent the facts
related to the build process of the software system (including but not limited to the
engineering transformations of the “source code” to “executables”). Build package
defines the architectural viewpoint for the Build domain.
EDITORIAL NOTE: This is the end of Block 1
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 2 in the editorial note in the specification text with changebars
Change sentence Page 13: Each KDM package defines several entity types representing specific
abstractions related to a certain viewpoint on existing software systems.
Into
Each KDM package defines several meta-model elements that represent specific entities
for a particular KDM domain.
Change sentence Page 13: Each KDM package defines several relationship types representing specific
abstractions related to a certain viewpoint on existing software systems.
Into
Each KDM package defines several meta-model elements that represent specific
relationships for a particular KDM domain.
EDITORIAL NOTE: This is the end of Block 2
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 3 in the editorial note in the specification text with changebars
Change sentence Page 18: Each KDM package defines several entity types representing specific
abstractions related to a certain viewpoint on existing software systems.
Into
Each KDM package defines several meta-model elements that represent specific entities
for a particular KDM domain.
EDITORIAL NOTE: This is the end of Block 3
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 4 in the editorial note in the specification text with changebars
Change sentence Page 19: Each KDM package defines several relationship types representing specific
abstractions related to a certain viewpoint on existing software systems.
Into
Each KDM package defines several meta-model elements that represent specific
relationships for a particular KDM domain.
EDITORIAL NOTE: This is the end of Block 4
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 5 in the editorial note in the specification text with changebars Change sentence section 10.2 page 25: There are 9 kinds of models, corresponding to some well-known
concerns of software engineering.
Into
There are 9 kinds of models. Each KDM model is described by one or more KDM packages and
corresponds to one KDM domain.
Change sentence section 10.2, page 25, From the architectural perspective, each KDM model represents a
particular view of the existing system. From the infrastructure perspective, a KDM model is a typed
container for model element instances. From the meta-model perspective, KDM model is represented by a
separate package that defines a collection of the meta-model elements, which can be used to build
representations of the particular view of existing systems.
Into
From the architectural perspective, each KDM package defines an architectural viewpoint. KDM model is
the key mechanism to organize individual facts into architecture views. From the infrastructure perspective,
a KDM model is a typed container for meta-model element instances (collection of facts organzied into an
architectural view). From the meta-model perspective, each KDM model is represented by a separate KDM
package that defines a collection of the meta-model elements, which can be used to represent the facts
about the given existing systems from a particular viewpoint.
Change sentence Page 27 A KDM model corresponds to one of the well-known architecture views of
software systems.
Into
Each KDM model defines an architectural viewpoint. An instance of a KDM model is an
architectural view of the given existing system. Physically every instance of KDMModel
element and its subclasses is a container for the facts from the corresponding KDM
domain.
Change sentence Page 29: The Segment element represents a coherent set of logically
related KDM models that together provide a useful view of an existing software system.
Into
The Segment element is a container for a meaningful set of facts about an existing
software system. Each Segment may involve one or more KDM model instances and thus
represents a collection of one or more architectural views for a given existing system.
Change sentence Page 29: Each KDM model defines KDM entities representing a certain view of the
existing software system. Each KDM model defines specific meta-model elements.
Into
Each KDM model defines an architectural viewpoint. KDM model defines specific metamodel
elements (entities and relationships specific to the viewpoint) that collectively
define the viewpoint language.
Change sentence Page 43: The Source package defines the KDM Inventory model that corresponds in part
to the engineering view of the existing software system.
Into
The Source package defines an architectural viewpoint for the Inventory domain.
Change section 11.1 sentence: The Source package also represents traceability links between instances of
KDM meta-elements and the regions of source code, which is represented by these meta-model elements. It
represents the convergence between the KDM intermediate representation and the application source it
represents
Into: The Source package also represents traceability links between instances of KDM meta-elements and the
regions of source code, which is represented by these meta-model elements. It represents the link between
the KDM instance and the corresponding artifacts of the existing system.
Change sentence Page 44: InventoryModel class diagram defines meta-model elements that represent the
artifacts of the existing software system as “first class citizens” on the KDM instance.
into
: InventoryModel class diagram defines meta-model elements that represent the physical artifacts of the
existing software system.
Change sentence Page 44: The InventoryModel class diagram follows the uniform pattern for KDM model
to extend the KDM Framework with specific meta-model elements related to the engineering view of
existing software systems.
into
The InventoryModel class diagram follows the uniform pattern for KDM model to extend the KDM
Framework with specific meta-model elements.
Change sentence Page 45: The InventoryModel is a specific KDM model which corresponds to the physical
(engineering) view of the existing software system.
into
The InventoryModel is a specific KDM model which represents facts related to the physical artifacts of the
existing software system.
Change sentence Page 51: KDM Build package that constitutes a separate L1.Build
compliance point, defines more precise meta-model elements to represent the engineering
view of the software system.
into
KDM Build package that constitutes a separate L1.Build compliance point, defines additional meta-model
elements that represent the facts involved in building the software system (including but not limited to the
engineering transformations of the “source code” to “executables”).
Remove sentence Page 59: This facet of knowledge about existing software systems corresponds to the
logical view.
Change sentence Page 61 The CodeModel is the specific KDM model that corresponds to the logical view
of the implementation of the existing software system.
Into
The CodeModel is the specific KDM model that represents collections of facts about the existing software
system such that these facts correspond to the Code domain.
Change sentence Page 164: Platform model defines one of the architectural views in support of the
principle of separation of concerns in KDM models.
Into
PlatformModel is the specific KDM model that represents collections of facts about the existing software
system such that these facts correspond to the Platform domain.
Remove sentence Page 177 The logical view of KDM model describes one or more SoftwareSystems.
Change sentence Page 207 This fact of knowledge corresponds to the logical view. It is determined by a
data description language.
Into
Fact in the Data domain are usually determined by a certain Data Description Language (for example,
SQL) but may in some cases be determined by the code elements. Change sentence Page 253: Abstraction Layer defines a set of meta-model elements whose purpose is to
represent domain-specific and application-specific abstractions, as well as the engineering view of the
exsting software system.
Into
Abstraction Layer defines a set of meta-model elements that represent domain-specific and applicationspecific
abstractions, as well as the artifacts related to the build process of the existing software system.
Change sentence Page 262: The Conceptual package defines meta-model elements for representing highlevel,
high-value application-specific “conceptual” views of existing software systems.
Into
The Conceptual package defines meta-model elements for representing high-level, high-value applicationspecific
“conceptual” elements of existing software systems and their traceability to other KDM facts.
Change the sentence Page 263: The ConceptualModel class is a KDM model that extends the KDM
Infrastructure framework to provide the infrastructure for representing conceptual views of existing
software systems.
Into
The ConceptualModel is the specific KDM model that represents collections of facts about conceptual
elements implemented by a given existing software system.
Change sentence Page 279: The Build package represents the artifacts that represent the engineering view
of a particular existing system. The Build package also includes the entities to represent the artifacts that
are generated by the build process.
into
The Build package defines meta-model elements that represent the facts involved in building the software
system (including but not limited to the engineering transformations of the “source code” to “executables”).
The Build package also includes the meta-model elements to represent the artifacts that are generated by
the build process.
Change sentence Page 279 The Build package defines a collection of meta-model elements that represent
entities and relationships related to the engineering view of existing software systems.
Into
The Build package defines a collection of meta-model elements that represent entities and relationships
related to the build process of an existing software system.
Change sentence Page 279 The BuildModel class diagram provides basic meta-model constructs to model
the engineering view of a particular existing software system within the KDM framework.
into
The BuildModel class diagram provides basic meta-model elements that represent entities and relationships
related to the build process of an existing software system.

Related to section 2.1

"KDM domains correspond to the well-known concept of architecture views." If this is true, the requirements for documenting views should be met; and the rules for interpreting such views should be provided. Usually this is done in terms of an Architectural Viewpoint definition for each view.

Satisfy requirements on each architectural view in accordance with ISO/IEC 42010.

Add Architectural Viewpoint definitions for each view in accordance with the rules of ISO/IEC 42010.

EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 1 (see specification with changebars and editorial notes)
page 1 Change sentence: Each KDM domain consists of a single KDM package that
defines meta-model elements to represent particular aspects of the system under study.
KDM domains correspond to the well-known concept of architecture views. Each KDM domain defines an architectural viewpoint. The viewpoint language for the
domain is defined by the corresponding KDM package that defines meta-model elements
to represent particular facts of the system under study that are essential to the given
knowledge discovery domain. The meta-model elements defined by all KDM packages
constitute the ontology for describing existing systems.
Page 1 change sentence:
For example, the Structure domain enables users to discover architectural elements of source code from the
system under study, while the Business Rules domain provides users with behavioral elements of the same
system such as features or process rules.
Into
For example, the Code package defines the language to represent individual code elements, such as
variables, statements and procedures, the Structure package provides the language to represent
architectural elements of the system such as subsystems and components, while the Conceptual package,
corresponding to the Business Rules domain defines the language to represent behavioral elements of the
same system such as features or business rules. KDM formally defines traceability, aggregation and
derivation of facts across domains.
Page 1 remove sentence: Separation of concerns in the design of KDM is embodied in the concept of
KDM domains.
Page 1 change sentence: The following domains of knowledge have been identified as the foundation for
defining compliance in KDM: Build, Structure, Data, Business Rules, UI, Event, Platform, and micro
KDM.
Into:
The following domains of knowledge have been identified as the foundation for defining compliance in
KDM: Inventory, Code, Build, Structure, Data, Business Rules, UI, Event, Platform, and micro KDM.
EDITORIAL NOTE: This is the end of Block 1.
EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 2 (see specification with changebars and editorial notes)
Page 2: change sentence: This compliance level contains the following KDM packages: Core, kdm, Source,
Code, and Action packages.
Into:
This compliance level addresses the Inventory and Code domains and is determined by the following KDM
packages: Core, kdm, Source, Code, and Action packages.
Page 2 change sentence: To be L0 compliant, a tool must completely support all model elements within all
packages for L0 level.
Into
To be L0 compliant, a tool shall completely support all meta-model elements within all packages of L0
level.
Page 2: change sentence
Level 1 (L1) - This level addresses KDM domains and extends the capabilities provided by Level 0.
Specifically, it adds the following packages: Build, Structure, Data, Conceptual, UI, Event, Platform, as
well as the set of constraints for the micro KDM domain defined in sub clause 14 “Micro KDM,” and Annex A “Semantics of the Micro KDM Action Elements.” These packages are grouped to form abovementioned
domains.
Into
Level 1 (L1) - This level addresses the remaining KDM domains and extends the capabilities provided by
Level 0. Specifically, this level is determined by the following packages: Build, Structure, Data,
Conceptual, UI, Event, Platform, as well as the set of constraints for the micro KDM domain defined in sub
clause 14 “Micro KDM,” and Annex A “Semantics of the Micro KDM Action Elements.”.
Page 3 change sentence:
To be L1 compliant for a given KDM domain, a tool must completely support all model elements defined
by the package for that domain and satisfy all semantic constraints specified for that domain.
Into
To be L1 compliant for a given KDM domain, a tool shall completely support all meta-model elements
defined by the corresponding packages and satisfy all semantic constraints specified for that domain.
EDITORIAL NOTE: This is the end of Block 2.
EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 3 (see specification with changebars and editorial notes)
Change sentence page 12 KDM representation is a single, integrated repository of different facets of
knowledge about the software system.
Into
KDM instance is a single, integrated representation of different facets of knowledge about the software
system.
EDITORIAL NOTE: This is the end of Block 3.
EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 4 (see specification with changebars and editorial notes)
Page 9 Change from: KDM separates knowledge about existing systems into several orthogonal facets
that are well-known in software engineering and are often referred to as Architecture Views.
into:
KDM groups facts about existing systems into several domains each of which corresponds to an ISO 42010
architectural viewpoint. Each KDM domain is represented by one or more KDM packages, which
formalizes the viewpoint language for that domain. KDM focuses at the entities and their relationships that
are essential for the given domain. A KDM representation of a given existing system – KDM instance - is a
collection of facts about that system. These facts are organized into KDM models per each domain. KDM
model corresponds to an ISO 42010 architectural view. KDM facts are further organized into meaningful
groups called segments. A KDM segment may include one or more architectural views of the given
system. KDM instances may be part of the complete architectural description of the system, as defined by
ISO 42010, in which case additional requirements of ISO 42010 shall be satisfied by the overall document.
KDM instances are represented as XML documents conforming to the KDM XMI schema.
Add clarification page 9 after sentence: Logically, KDM consists of 9 models.
Each KDM model is described by one or more KDM packages and corresponds to one KDM domain.
Most KDM domains are defined by a single package, with the exception of the Code domain, which is split
between the Code and the Action packages.
EDITORIAL NOTE: This is the end of Block 4. EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 5 (see specification with changebars and editorial notes)
Page 27: Change from: A KDM model corresponds to one of the well-known architecture views of
software systems. KDM defines several concrete subclasses of the KDMModel class.
To:
A KDMModel element is an abstract class that defines the common properties of KDM model instances
which are collection of facts about a given existing system from the same architectural viewpoint of one of
the KDM domains. KDM defines several concrete subclasses of the KDMModel class, each of which
defines a particular kind of a KDM model. The architectural viewpoint is defined by the corresponding
KDM package. A KDM model instance is an architectural view of the given system.

p. 113 (p.91) Change "return this is a return parameter" to "return parameter being returned"
and "unknown the parameter passing convention is unknown" to "unknown parameter passing
convention is unknown" to be consistent with the other entries.

Page 91 Replace “”this is a return parameter” with “parameter being returned”
Replace “the parameter passing convention is unknown” with “parameter passing convention is
unknown”

p. 178 (p. 154) – Inputs bullet – should be "Ordered incoming..." not "Ordered outgoing..."

Page 154, inputs bullet replace “Ordered outgoing Reads” into “Ordered incoming Reads”

.69 (p.47) Section 11.3.6, 7, 8, 9, 10... – "The Image is used to represent image files." should be "Image is used to represent image files."
and the initial "The" should be removed in the same way from sections the other sections. These classes are obviously very vague –
will they be expanded in a future iteration of the document?

Page 48, section 11.3.6 replace “The Image” into “Image element”
Page 48, section 11.3.7 replace “The Configuration” into “Configuration element”
Page 48, section 11.3.8 replace “The ResourceDescription” into “ResourceDescription element”
Page 48, section 11.3.9 replace “The BinaryFile” into “BinaryFile element”
Page 49, section 11.3.10 replace “The ExecutableFile” into “ExecutableFile element”

p.104 (p.82) "...defined datatype Octet String." – "String" should be "string"

Page 82 12.9.16 section semantics, replace “The KMD Octetstring class … Octet String” with
“The KDM OctetString class … Octet string”

p.88 (p.66) Suggest changing "Same source files may produce a different logical model (for example, when compiled and linked
for a different hardware platform, or for a different operating system)." to "A source file may produce a different logical models when,
for example, compiled and linked for a different hardware platform, or for a different operating system.

Section 12.5.5. replace "Same source files may produce a different
logical model (for example, when compiled and linked for a different
hardware platform, or for a different operating system)."
With "A source file may produce a different logical models when, for
example, compiled and linked for a different hardware platform, or for
a different operating system.”

Suggest putting Part 1, Part 2, Section 1, etc. in the table of contents to logically break up the TOC such as these
heading do within the document. These headings do segment the document logically and as such I don't see why

they are not in the TOC. Also would make it easier to find them in the document.

Change the TOC to include parts

p. 178 (p. 154) Semantics – need to capitalize Annex A title to match Annex A as it appears. That
is, change the title to "Semantics of the Micro KDM Action Elements"

Replace "Semantics of the micro KDM action elements"
With "Semantics of the Micro KDM Action Elements"

p.69 (p.47) in the Semantics section – the sentence "The requirement for KDM tools is to read information in UTF-8." should be
incorporated in the next paragraph where the discussion is and "UTF-8" is introduced.

Delete "The requirement for KDM tools is to read information in UTF-8."
Add to the last paragraph of Semantics: “KDM tools shall at a minimum
support UTF-8”.

p. 177 (p. 153) – last line should be reordered to be the same as the items presented – i.e. should
be Action Kind, Outputs, Inputs, Control, Extras)

Page 153, last line, replace “5 parts (Action Kind, Inputs, Outputs, Control, and Extras)” into
“5 parts (Action Kind, Outputs, Inputs, Control, Extras)”

p. 178 (p. 154) Control and Extras bullets should not have "part" as part of name. That is, remove
"part" from "Control part" and "Extras part"

Page 154 replace “Control part” into “Control”
Replace “Extras part” into “Extras”