KDM has several instances of MOF enumerations. The model shall represent them as MOF enumerations, rather than as MOF classes with a hardcoded stereotype "<<enumeration>>"

Refactor MOF enumerations and update diagrams in the specification

Currently MOF enumerations are represented as UML classes with a hardcoded stereotype "<<enumeration>>". Instead, they should be represented directly as instances of MOF Enumeration. The figures need to be replaced because of a slightly different look an feel of proper MOF Enumerations. Otherwise the specification text is correct.

Currently the KDM spec references an old XMI version 2.1
The current is 2.4.2
This affects examples in the specification text as well as KDM XMI XSD

Update example to new version of XMI and KDM

The new format of standard references for XMI 2.4.2 schema files is :
XMI namespace URI http://www.omg.org/spec/XMI/20110701
XMI xref URI http://www.omg.org/spec/XMI/20110701/XMI-model.xmi

According to standard format of OMG references, each KDM 1.4 package
has own namespace URI, with the common base
http://www.omg.org/spec/KDM/20160501
followed by the package name.

For example, for KDM Core package
XMI namespace URI http://www.omg.org/spec/KDM/20160501/core
XMI xref core.xsd

Use of references in XSD schema
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xmi="http://www.omg.org/spec/XMI/20110701"
xmlns:core="http://www.omg.org/spec/KDM/20160501/core"
xmlns:kdm="http://www.omg.org/spec/KDM/20160501/kdm"
xmlns:source="http://www.omg.org/spec/KDM/20160501/source" targetNamespace="http://www.omg.org/spec/KDM/20160501/source" >

<xsd:import namespace="http://www.omg.org/spec/KDM/20160501/core" schemaLocation="core.xsd" />
<xsd:import namespace="http://www.omg.org/spec/KDM/20160501/kdm" schemaLocation="kdm.xsd" />

Use of references in KDM XMI document
<?xml version="1.0" encoding="UTF-8"?>
<kdm:Segment
xmlns:xmi="http://www.omg.org/spec/XMI/20110701"
xmlns:core="http://www.omg.org/spec/KDM/20160501/core"
xmlns:code="http://www.omg.org/spec/KDM/20160501/code"
xmlns:kdm="http://www.omg.org/spec/KDM/20160501/kdm"
name="Stereotype Example">

In KDM 1.3 the predefined datatypes used to be instances of MOF datatype. According to KDM14-12 this has been changed to PrimitiveType. However, following up the discussion at the AM meeting on March 26, 2015, using MOF datatype is a more appropriate decision.

Revert predefined types to MOF datatype

the 3 datatype from Core shall be referred to as "predefined" datatypes to distinguish from primitive datatypes in Code model

Several corrections to the resolution text of KDM14-289 based on the feedback from the production of the MOF model

Make editorial changes to the specification text

Make editorial changes to the specification text, with reference to the text introduced by KDM14-289 and the sections of the KDM-1.4 draft. In the changebar document the corrections are marked as KDM14-289

Strictly speaking end ownership should be used for generating operators not navigability. e.g. if the property is an ownedAttribute of the class, not whether it's navigable.

Clarify specification text regarding association end ownership

From Pete Rivett:
Navigability is an implementation hint that the navigation should be efficient.
It is quite conceivable to have an ownedAttribute which is not seen an important for it to be efficient (e.g. the implementation might iterate through all instances of the target to look for a link to the source).
Likewise there might be an end owned by association where efficiency is important but there is no ownedAttribute – especially for cross-metamodel associations (or those involving MOF Element) where it is not allowed to add an ownedAttribute to an external metamodel or MOF itself.

Though KDM may have a pattern that always combines ownership and navigability, the specification should reference ownership.
What I’m looking for to resolve my issue is:

• Use ownership not navigability in the text
• Use the dot notation in the diagrams to show end ownership

Overview of the proposed resolution:
Modify the specification text of section 6.2.1 Diagram format according to the suggestion by Pete. Do not use the dot notation in the diagrams, as the convention of the diagrams is fully described in section 6.2.1, the pattern is consistent, and last but not least, introducing the dot notation involves a massive change to the specification text. Instead, add text to the key semantic sections in the kdm core, emphasizing association end ownership.

The current specification describing the BinaryFile Class file is either incorrect or misleading at best.

Since all files are ultimately binary, the BinaryFile Class, it seems, is more defined in terms of exclusion rather than inclusion. Normally we would consider human readable files as text files and non-readable files as binary. This is clearly not the definition used in the KDM context, as we would then have Image and ExecutableFile as extending BinaryFile.

So given the fact that BinaryFile first doesn’t follow general conventions, it should then be better defined. As it can probably be interpreted from reading the specification here, a BinaryFile is any file that doesn’t fit in any of the other type of files extending InventoryItem. But that would still leave us with issues of how to represent files that are clearly Text files, but not SourceFile, Configuration or ResourceDescription.

Rename BinaryFile to LinkableFile and clarify semantics

Rename BinaryFile into LinkableFile to avoid confusion with ImageFile on the semantics of "binary" meaning "linkable" rather than "non-text"
Clarify semantics. BinaryFile, ExecutableFile and SourceFile are related to computations, and contain representations of computational objects and statements in various formats, such as linkable object format for some platform, loadable machine instructions, interpretable bytecode, interpretable text statements, etc.

AbstractEventElement should group KDM Elements (instead of AbstractCodeElement). This allows us to attach an Event model also to other part of the model

Proposal does not align with existing mechanisms

EventModel is available to represent some abstractions and link the to lower-level KDM elements. For example, EventModel can be used to represent abstractions of some existing system.
Semantics of EventModel is not strong enough so that these elements can be used to model other KDM elements.

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.

Currently the KDM defines 6 classes that are derived from InventoryItem and each of those is documented to represent files of some sort, but the naming is inconsistent. 3 of them have the File suffix and the other 3 don’t, leaving the user to question the categorization difference, which doesn’t seem to really exist when reading the documentation.

Rationalization of InventoryItem

Proposed subclasses of InventoryItem:
InventoryItem
.. SourceFile
.. Model (new)
.. LinkableFile (former BinaryFile)
......ObjectFile
......LibraryFile
..ExecutableFile
..ConfigFile (former Configuration)
..DataFile (new)
..ImageFile (former Image)
..Document (new)
..AudioFile (new)
..WebService (new)

remove ResourceDescription (can't distinguish from ConfigFile)

Assume InventoryItem has attribute path:URL (see KDM14-131)
Rename generic Platform::ResourceType into Platform::PlatformResource because the old name conflicts with the use of resource in the InventoryModel.

Add attribute format:String to InventoryItem
format:String Optional description of the format of the InventoryItem
add semantics: format attribute describes the organization of the InventoryItem. Examples of format for various subclasses of InventoryItem are: "xml", "html", "json", "csv", "text", "ms word", "coff", "java class", "jpeg","mp3","css"

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

The current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit and to a certain extent ParameterUnit and StorableUnit.

The issue is that some of the kind enumeration are tied to a class but in reality can apply in other places and that those enumeration are single valued where in real life usage we would need to often specify more than one value.

Some concrete example:

1- ClassUnit (and InterfaceUnit) supports no modifiers (or kind enumeration in KDM speak). This issue was raised in 2006 and never addressed. How can we, without resorting to stereotypes, which are not very interoperable, describe a Java class that is “final public” or “static”

2- MethodUnit has a MethodKind but it has no ExportKind which would be a start to try to capture a Java method like “final protected” (also needs multi-value)

3- ParameterUnit has a ParameterKind but it again has no ExportKind. So another example, your Java method parameter that is declared as “final” (or is that an “ImportKind”)

4- MemberUnit represent for example Java field class member (JLS names). There we have ExportKind but like other places for Java modifiers it would be missing “static”, “transient”, “volatile” and a way to express “default”, unless we agree that it is in force if none of public, private or protected is specified. But we should be able to easily support a field declaration such as: “private static final String CONST1 = “xx”; “

I am not sure what the best approach is here in all regards. First I think we must change the cardinality to support multiple “modifiers” for the same “unit”. We also need to look if we want to simply expand the ExportKind and move it to the ComputationObject class instead of being at the MemberUnit level. That obviously expands the classes that can make use of it, but it addresses most of the issues, except for the ClassUnit and InterfaceUnit which are children of DataType

current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit

Added attributes since using an enum does not seem appropriate. These should match some UML concepts.

In the Action Package, the codeElement at the to endpoint of the ActionElement, AbstractCodeElement relation should be marked as ordered.

This would be consistent with all other subsets of ownedElement with a mulitiplicity greater than 1 from the code model that also point to AbstractCodeElement which are all ordered. Given that these are owned code elements, and I quote, “nested action elements, or nested BlockUnits, or nested definitions of datatypes and computational objects”, losing the ordering of such elements goes counter to the design of the code model and has huge impact as we have to make ordering assumptions to make sense of the content.

Add "ordered" to owned CodeElement in Action

Add "ordered" to owned CodeElement in Action as per issue description. Remove "ordered" from AbstractActionRelationship association.

There is an inconsistency between the documentation in the KDM build package and the example in the section.

The example shows a BuildStep consuming it's input source elements which are classified as BuildComponent.

In the description for BuildComponent we have: "The BuildComponent class represents binary files that correspond to deployable components, for example executable files."

Obviously the input source elements being consumed in the example are .c and .h files, which are not binary.

So is BuildComponent the right class to use for input source elements or is the description of the class incorrect?

Add definitions of BuildComponent, BuildProduct, Library

Rename Library to BuildLibrary for consistency.
The description of BuildProduct and BuildLibrary are missing. Definition of a BuildComponent is actually related to (missing) BuildProduct. A BuildProduct defines the product of a build process.
A Library is a collection of InventoryItems (usually BinaryFiles, or SourceFiles) which is used as an intermediate product of a build process.
BuildComponent can be described as any collection of InventoryItems. A BinaryComponent defines SourceFlles as inputs to BuildSteps or any other anonymous collections of resources as they are used as inputs of outputs of a build process.
The intention is to identify sources and targets of BuildStep as sets of InventoryItem (in fact, the definition is more general and will accept any KDMEntity).

With this interpretation the example on page 306 is correct.

In the platform package we don't seem to have any direct way to express relations between AbstractPlatformElement and InventoryElement. A good example is how to describe the file in the inventory model that represents a certain deployed component.

AbstractPlatformElement has a source relation to a SourceRef but here we're not dealing with a Source inventory element (not sure how often PlatformElement would really need this relation). The Build package uses the implementation relation which points to KDM entity to describe relations to inventory elements. Again here in the platform package this points to AbstractCodeElement only.

I hate to have to use stereotypes to build such a basic relation.

Add TraceableTo relation to Inventory model

In order to support arbitrary traceability links to InventoryItems, we use Figure 11.3, page 59 and add relation "TraceableTo" from KDMEntity to InventoryItem.

In section 21.5, BuildResource class diagram, the class Library and BuildProduct are described in the diagram 21.3 but have no description in the text of the specification. However references can be found in examples and they are part of the XMI model.

I believe that standard documentation sections should be added for these classes.

Merge with KDM14-70

This issue is merged with KDM14-70

After changes from Ballot 11 in 2007, the micro-KDM the documentation was not updated to reflect the fact that the invokes relationship didn’t exist anymore.

We currently still have 4 micro-KDM actions that describe Invokes relationships:

MethodCall, VirtualCall, MemberSelect, MemberReplace.

These need to be changed to the Adresses relationship at the very minimum.

Change Invokes to Addresses

Change specification text to replace 4 occurrences of "Invokes relationship" into "Addresses relationship". One occurrence has been changed as part of resolution to issue 14-79

In section 12.6.4, the Superclass of MethodUnit is shown as CallableElement instead of the current ControlElement

Change superclass of MethodUnit to ControlElement

The correct superclass of MethodUnit is ControlElement as in the model. The specification text should be corrected.

The references to UML, MOF and XMI in the KDM 2.2 are not appropriate.

The references to 19502:2005 and 10503:2005 are not used anywhere in the spec and should be removed.

The ref to MOF should be to the actual version used.

The proposed resolution below assumes the Latest Versions used are MOF 2.0 and XMI 2.1.1.

Proposed solution:

In section 3

Change:
“
3 Normative References
The following normative documents contain provisions, which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to or revisions of any of these publications do not apply.
• 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)
“
To:
“
3 Normative References
The following normative documents contain provisions, which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to or revisions of any of these publications do not apply.
• OMG UML 2.4 Infrastructure Specification <omg spec ref URL>
• OMG Meta-Object Facility (MOF) ver. 2.0 <OMG spec ref URL>
• OMG MOF XML Metadata Interchange (XMI) ver. 2.1.1 <OMG spec ref URL>
• OMG Semantics of Business Vocabularies and Business Rules (SBVR) Ver 1.0 formal/08-01-02
• ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)
"

Merge with KDM14-56

Merge with KDM14-56

Clarify alignment of the KDM Core with RDF

Clarify text regarding alignment with RDF

The text should clarify how KDM explicit and built-in relations can be represented as RDF triples.

Clarify the text regarding the distinction between the explicit relationship and the built-in relationships

Add text to page 27, semantics of KDMRelationship

This issue is to some extent related to KDM14-32 regarding the alignment between KDM and RDF. Semantics of the KDMRelationship should be clarified.

Representation of a stand-alone comment (not associated with a particular CodeElement)

Clarify the description of CommentUnit

The description of the CommentUnit should be clarified.

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

At the start of page 224, a 'Flow' is defined that goes to="id.47" from="id.44". This should be conditional ('FalseFlow'), since 'WITH TEST AFTER' is not used in the 'PERFORM' statement. This would be consistent with the 'FalseFlow' defined in 'id.64'. Suggestion: Move 'id.64' up to before the loop starts (after id.44) and remove the unconditional 'Flow' from 'id.44'. This improves action element arrangement with respect to their associated Cobol code snippets. Also, action elements corresponding to Cobol statements subordinated to the inline PERFORM appear at the same indentation level as action element 'id.64'. If this action element is indeed moved up, those dependent action elements should probably become part of its 'codeElement' children.

Multiple corrections in RecordFile example

The RecordFile example introduces ExceptionFlow in the corresponding DataModel. The base code model does not represent these flows because the semantics of exceptions is determined by the data model, not the code model (this is the KDM split, eventhough in Cobol they are both defined as part of the programming language)
So, we will move the UNTIL condition to the top of the loop, as proposed, since the default for PERFORM UNIL is indeed WITH TEST BEFORE. We will also fix few related issues.

Currently the KDM doesn’t allow for the stereotyping of Audit elements since those inherit from Element and not ModelElement.

We believe that this is an oversight, as a reading of the specification uses the Audit element by name as one of the possible owner of a stereotype (10.5.1 constraint #5: KDM

meta-elements (for example, “KDMEntity,” or “Audit”)) or the endpoint to a TaggedRef (10.5.2 constraint #4: KDM meta-element (for example, “KDMEntity,” or

“Audit”))

We are proposing the following changes to restore this capability that was clearly intended to exist in the first place:

· Move the stereotype relation from ModelElement to Element

· Change the endpoint of the reference relation in TaggedRef to now point to Element instead of ModelElement

· Change all text that refers to ModelElement as being subject to extension in favor of Element

Another possible approach that might be simpler is to derived the Audit from ModelElement instead of Element. Probably the only issue at hand is if it fits the definition given in 9.3.2 as being an element of the existing software system or not. That is a bit of a stretch here, but we could see this as being argued either way in the case of Audit.

Introduce Core class ExtendableElement and change subclass of Audit

in core package: Add class diagram Element to Core. Introduce abstract Core classes AnnotatableElement, AnnotationElement, ExtendableElement and ExtensionElement. Make ModelElement a subclass of ExtendableElement.
in kdm package: Make Audit a subclass of ExtendableElement.
Make Attribute, Annotation subclasses of AnnotationElement
Make ExtendedValue, Stereotype, TagDefinition, ExtensionFamily subclasses of ExtensionElement.
Then on Figure 10.3 we could have ExtendableElement instead of ModelElement.
Clarify descriptions.

We are proposing changing the Audits relation that is now from KDMFramework to Audit and instead having it from ModelElement to Audit.

That change would allow audits to be attached not only to segments and models, but sometimes to other element as well. For examples, Modules or CompilationUnit are prime candidate for us as they are initially produces independently and then brought into a bigger KDM.

Change audit endpoint to ModelElement

Changing the endpoint to allow audits to be stored for any ModelElement to associate additional metadata with any model element. This information can be related to provenance, argument, composition requirements, etc.

This is a follow-up correction to KDM14-58. Some descriptions were missing in the original resolution.

*Add descriptions of the new top-level elements *

Add descriptions of the new top-level abstract elements AnnotatableElement, AnnotationElement, ExtendableElement, ExtensionElement. Editorial changes to description of the Element and ModelElement.

In KDM 1.3 the text description of the KDMEntity is missing properties ownedElement and groupedElement.

Add missing descriptions of properties to KDMEntity

Add text descriptions of derived properties "ownedElement" and "groupedElement" to section 9.4.1
Add text descriptions of derived properties "inbound" and "outbound" to section 9.5.2
Add text descriptions of derived properties "inAggregated", "outAggregated" to section 9.6.2

This is a clarification to text that is introduced as resolution to KDM14-131:
1. replace
md5:String Optional MD5 has signature of the resource
with
md5:String Optional MD5 hash signature of the resource using the MD5 message-digest algorith

2. add sentence to semantics:
The 128-bit (16-byte) hash value produced by the MD5 message-digest algorithm is represented in text format as a string of exactly 32 characters [0-9a-fA-F] that correspond to the digits of the hexadecimal number.

Add clarifications to the use of MD5 property

Add clarifications to the use of MD5 property of IntentoryItem:

Add clarification to BinaryRegion element introduced by KDM14-207:
"Specification of a BinaryRegion assumes that the corresponding resource is a sequence of bytes, where each byte has 8-bit size, representable as an octet. Addresses in a BinaryRegion are represented as non-negative integers. The address of the first byte in a binary resource is 0. For example, an address that may be displayed as a C-like string "0x00A0" is represented as an integer 160."

Add clarification to BinaryRegion

Add clarification to BinaryRegion.
Make sure the diagram shows attributes of BinaryRegion as startAddr, endAddr, as in the text.

Audit element can be extended with ExtensionElement using the light-weight extensibility mechanism.

Add clarification to Audit element

Add clarification to Audit element

Editorial change:
SourceRef and Region elements that represent traceability links between other instances of KDM meta-model elements and source code of an existing software system.
Track element that together with the TraceableTo relation represents traceability links between instances of KDM entities, including links from KDMEntities to InventoryItem elements.

Add clarification regarding Track element to overview

Editorial change

Resolution to KDM14-60 adds source association to AbstractInventoryElement. This has been superseded by the resolution to KDM14-208. The association shall be removed (or not added to begin with).

Remove attribute source

Remove attribute source added in resolution KDM14-60 and not removed by resolution to KDM14-208

KDM14-134 added owner to ExtensionFamily. However the underlying use case also requires owner properties be added to Stereotype (to the corresponding ExtensionFamily, reachable from the stereotyped element), and to TagDefinition (to the corresponding Stereotype, reachable from ExtendedValue).

Add owner to Stereotype and TagDefinition

Add owner to Stereotype and TagDefinition

Explicit KDM relationships are subclasses of KDMRelationship class. There are two associations: one with endpoint "to", redefines "to" from KDMRelationship; other - with endpoint "from", redefines "from" from KDMRelationship. The opposite endpoints of "to" and "from" correspond to "inbound" and "outbound" in KDMRelationship-KDMEntity association. In cmof, these endpoints correctly subset the "inbound" and "outbound" properties. However, in the KDM UML diagrams the is not stated explicitly.
Recommendation to add subsetted properites to all relation endpoints as part of upgrading to NoMagic format.

Add subsets inbound, outbound properties to KDM relation endpoints

Add subsetted property inbound at the endpoint opposite to "to" and subsetted property at the end opposite to "from" in all diagrams that represent KDM relationships.
This is already in the cmof model, so the impact it merely to upgrade the KDM diagrams to reflect this and tie getInbound(), getOutbound() to low-level kdm relationships, using the formal CMOF mechanism.

Association between CompilationUnit and SourceFile other than through SourceRef.

Merged with KDM14-69

Merged with KDM14-69

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

Initialization block? Maybe need a special ControlElement for it. Maybe represent it with a BlockUnit
not a CallableUnit. What is the semantics of passing control to other init blocks? The text needs to be made more
clear

Generalize Calls and clarify constraints for init blocks

1. extend target of the current Calls from ControlElement to CodeItem so that It could refer to either a ControlElement or an entire CompilationUnit.
Add description of initialization blocks to 13.3.3 pages 141-142, refer to Init example in section 12.19.2.

2. Add description text to 12.19.2. Semantics of init blocks: 1) Code Assembly shall have an EntryFlow relation to the Init block, called the "master" init block; 2) each CompilationUnit shall have an EntryFlow relation to the first init block for the CompilationUnit, if required; 3) each init block has Flow relation to next init block within the same CompilationUnit, if required; 4) KDM implementation shall provide correct initialization order between multiple init blocks within each CompilationUnit. 5) KDM implementation shall provide correct initialization order between init blocks of separate modules. This order is typically undefined in the programming language and depends on the linker and the order in which modules are built. 6) KDM implementation shall determining appropriate owner for the init blocks. 6) KDM implementation shall provide appropriate chaining of init blocks across separate CompilationUnits within a CodeAssembly through the "master" init block in the CodeAssembly.
The "master" init block owned by CodeAssembly owns an ActionElement with a sequence of Calls relations to each CompilationUnit that has an init block, in appropriate order. The last Calls relation is to the entry point of the CodeAssembly, for example, "main".

3. Correct "master" init block in the Init example.

4. Correct Init example.
<actionRelation xmi:id="id.74" xmi:type="action:Flow" to="id.79" from="id.71"/>
should flow to id.75

5. Add description to CodeAssembly regarding EntryFlow relation to chained init blocks.

6. Add description to Init microKDM action in Annex A, table A.4
Clarify description of EntryFlow