Knowledge Discovery Metamodel Avatar
  1. OMG Specification

Knowledge Discovery Metamodel — All Issues

  • Acronym: KDM
  • Issues Count: 17
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
KDM14-59 Clarify the meaning of BinaryFile KDM 1.2 KDM 1.4 Duplicate or Merged closed
KDM14-60 Standardize naming of InventoryItem children KDM 1.2 KDM 1.4 Resolved closed
KDM14-64 current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit KDM 1.2 KDM 1.4 Resolved closed
KDM14-63 mark code element as ordered KDM 1.2 KDM 1.4 Resolved closed
KDM14-61 At the start of page 224, a 'Flow' is defined that goes to="id.47" from="id.44". This should be conditional ('FalseFlow' KDM 1.2 KDM 1.4 Resolved closed
KDM14-58 Change specification to allow stereotyping of Audit elements KDM 1.2 KDM 1.4 Resolved closed
KDM14-57 Change relation endpoint for Audit relation KDM 1.2 KDM 1.4 Resolved closed
KDM14-62 Provide detailed information about dependencies between KDM packages KDM 1.2 KDM 1.4 Deferred closed
KDM15-15 Provide detailed information about dependencies between KDM packages KDM 1.2 open
KDM13-20 References in KDM for UML, MOF, and XMI are not current KDM 1.2 KDM 1.3 Resolved closed
KDM13-17 StorableUnit is not a subclass of StorableElement (anymore) KDM 1.2 KDM 1.3 Resolved closed
KDM13-16 'DataUnit' incorrectly used instead of 'DataElement' KDM 1.2 KDM 1.3 Resolved closed
KDM13-15 Cobol code erroneously says "PERFROM" instead of "PERFORM" KDM 1.2 KDM 1.3 Resolved closed
KDM13-14 Small typo at 19.3.8 KDM 1.2 KDM 1.3 Resolved closed
KDM13-13 Wrong class mentioned KDM 1.2 KDM 1.3 Resolved closed
KDM13-19 There should be no references from lower KDM layers to higher layers KDM 1.2 KDM 1.3 Resolved closed
KDM13-18 15.5.5 FileResource Class KDM 1.2 KDM 1.3 Resolved closed

Issues Descriptions

Clarify the meaning of BinaryFile

  • Key: KDM14-59
  • Legacy Issue Number: 14170
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    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.

  • Reported: KDM 1.2 — Fri, 31 Jul 2009 04:00 GMT
  • Disposition: Duplicate or Merged — KDM 1.4
  • Disposition Summary:

    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.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Standardize naming of InventoryItem children

  • Key: KDM14-60
  • Legacy Issue Number: 14171
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    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.

  • Reported: KDM 1.2 — Fri, 31 Jul 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    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"

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-64
  • Legacy Issue Number: 15277
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    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

  • Reported: KDM 1.2 — Mon, 7 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    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.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

mark code element as ordered

  • Key: KDM14-63
  • Legacy Issue Number: 15276
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    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.

  • Reported: KDM 1.2 — Sat, 5 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add "ordered" to owned CodeElement in Action

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

At the start of page 224, a 'Flow' is defined that goes to="id.47" from="id.44". This should be conditional ('FalseFlow'

  • Key: KDM14-61
  • Legacy Issue Number: 14173
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

    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.

  • Reported: KDM 1.2 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    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.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Change specification to allow stereotyping of Audit elements

  • Key: KDM14-58
  • Legacy Issue Number: 14107
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    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.

  • Reported: KDM 1.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    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.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Change relation endpoint for Audit relation

  • Key: KDM14-57
  • Legacy Issue Number: 14106
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    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.

  • Reported: KDM 1.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    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.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Provide detailed information about dependencies between KDM packages

  • Key: KDM14-62
  • Legacy Issue Number: 15129
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Description: As per issue JP7 raised by the Japan delegation to ISO during the KDM review, it was stated that “Existing software based systems have the relationship among packages. But this standard doesn't mention it precisely. (Conceptually, this shows package structure.)”. The suggested resolution was to Describe it using Package diagram. KDM 1.1 RTF decided not to replace the existing architectural illustration of the layers (as per issue resolution 13828) with the UML package diagram in order not to complicate the introductory part of the specification and not to complicate the maintenance of the formal machine readable documents of the specification. Also, the UML package diagram was not considered to be detailed enough. However, useful detailed relations between packages can be added as a non-normative appendix to the specification.

  • Reported: KDM 1.2 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Provide detailed information about dependencies between KDM packages

  • Key: KDM15-15
  • Legacy Issue Number: 15129
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Description: As per issue JP7 raised by the Japan delegation to ISO during the KDM review, it was stated that “Existing software based systems have the relationship among packages. But this standard doesn't mention it precisely. (Conceptually, this shows package structure.)”. The suggested resolution was to Describe it using Package diagram. KDM 1.1 RTF decided not to replace the existing architectural illustration of the layers (as per issue resolution 13828) with the UML package diagram in order not to complicate the introductory part of the specification and not to complicate the maintenance of the formal machine readable documents of the specification. Also, the UML package diagram was not considered to be detailed enough. However, useful detailed relations between packages can be added as a non-normative appendix to the specification.

  • Reported: KDM 1.2 — Wed, 24 Mar 2010 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:21 GMT

References in KDM for UML, MOF, and XMI are not current

  • Key: KDM13-20
  • Legacy Issue Number: 15872
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:

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

  • Reported: KDM 1.2 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Replace Normative References section 3, page 6, with the following:
    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 Infrastructure Specification, ver. 2.3, formal/2010-05-03
    • OMG Meta Object Facility (MOF) Specification, ver. 2.0, formal/06-01-01
    • OMG MOF XML Metadata Interchange (XMI) Specification, ver. 2.1, formal/05-09-01
    • OMG Semantics of Business Vocabularies and Business Rules (SBVR) Specification,
    ver. 1.0, formal/08-01-02
    • ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)

  • Updated: Sun, 8 Mar 2015 13:51 GMT

StorableUnit is not a subclass of StorableElement (anymore)

  • Key: KDM13-17
  • Legacy Issue Number: 15273
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    12.7.2 StorableUnit Class

    StorableUnit class is a concrete subclass of the StorableElement class that represents variables of the existing software

    system.

  • Reported: KDM 1.2 — Fri, 4 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    No Data Available

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

'DataUnit' incorrectly used instead of 'DataElement'

  • Key: KDM13-16
  • Legacy Issue Number: 14572
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

    'Table A.4 - Control actions' contains two rows related with Incr and Decr ActionElement Micro actions. In the column named 'Outputs' the word 'DataUnit' is incorrectly used twice, one per row. It should read 'DataElement'.

  • Reported: KDM 1.2 — Mon, 19 Oct 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Page 296, A.4 replace “DataUnit” with “DataElement” (2 times)

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

Cobol code erroneously says "PERFROM" instead of "PERFORM"

  • Key: KDM13-15
  • Legacy Issue Number: 14172
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

    Cobol code erroneously says "PERFROM" instead of "PERFORM".

  • Reported: KDM 1.2 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Page 222, replace “perfrom” with “perform”

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

Small typo at 19.3.8

  • Key: KDM13-14
  • Legacy Issue Number: 14109
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Small typo at 19.3.8

    “attrbiutes” instead of attributes

  • Reported: KDM 1.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Page 258, 19.3.8 replace “attrbuites” with “attributes”

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

Wrong class mentioned

  • Key: KDM13-13
  • Legacy Issue Number: 14108
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    In 10.5.1, Stereotype class, it says that: “In the meta-model the Stereotype is a subclass of ModelElement.”

    This should read as: “In the meta-model the Stereotype is a subclass of Element.”

  • Reported: KDM 1.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    10.5.1. replace “In the meta-model the Stereotype is a subclass of ModelElement” with
    “In the meta-model the Stereotype is a subclass of Element”

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

There should be no references from lower KDM layers to higher layers

  • Key: KDM13-19
  • Legacy Issue Number: 15305
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    In the preface to part III we have the following:

    KDM is designed in such a way that the Resource level analysis can use KDM models from the Platform Elements Layer as input and produce Resource Layer models as output. There should be no references from lower KDM layers to higher layers; therefore, new Resource Layer models can be built on top of existing Program Element layer models.

    Couple of points:

    1. There is no “Platform Elements Layer”. As shown in the next sentence it should probably read “Program Elements Layer” which is part II.

    2. The 2 places where it refers to “Resource Layer” might be renamed to “Runtime Resources Layer” to better match the part title.

  • Reported: KDM 1.2 — Fri, 25 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Page 159, replace “commpon properties of the Resource Layer” with “common properties of the
    Runtime Resources Layer”
    (After bullets) Replace “Since Resource Layer” with “Since “Runtime Resources Layer”
    Replace “a way that the Resource Layer” with “a way that the Runtime Resources Layer”
    Replace “produce Resource Layer models” with “produce Runtime Resources Layer
    models”
    Replace “new Resource Layer models” with “new Runtime Resources Layer models”
    Replace “Platform Elements Layer as input” with “Program Elements Layer as input”
    Replace “Resource Layer package systematically: with “Packages of the Runtime
    Resources Layer”
    Bullet 1 replace “Each Resource Layer package defines” with “Each Runtime Resources
    Layer package defines”
    Bullet 2 replace “Each Resource Layer package defines” with “Each Runtime Resources
    Layer package defines”
    Bullet 2 replace “Each Resource Layer package defines” with “Each Runtime Resources
    Layer package defines”
    Replace “modularity between Resource Layer packages” with “modularity between
    KDM packages”
    Page 160
    Bullet 5 replace “elements of Resource Layer package” with “elements of Runtime
    Resources Layer package”
    Bullet 6 replace “Each Resource Layer package defines” with “Each Runtime Resources
    Layer package defines” After bullets: replace “Resource Layer packages are independent” with “Runtime
    Resources Layer packages are independent”
    Replace “action containers in Resource Layer models” with “action containers in
    Runtime Resources Layer models”
    In the next bulleted list replace “Resource Layer patterns” with “Runtime Resources
    Layer patterns”

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

15.5.5 FileResource Class

  • Key: KDM13-18
  • Legacy Issue Number: 15304
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    In the following paragraph, the DataInterface has been gone since 2006, so maybe we just want to remove the last sentence or reword it to refer to the PlatformActions.

    15.5.5 FileResource Class

    FileResource represents platform resources that provide any non-database related storage. In the meta-model the

    FileResource class is a subclass of ResourceType. It also implements the DataInterface so that this class can be the

    endpoint of Data relations.

  • Reported: KDM 1.2 — Fri, 25 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Page 170, delete sentence “It also implements the DataInterface so that this class can be the
    endpoint of Data relations.”

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