KDM 1.4 RTF Avatar
  1. OMG Issue

KDM14 — Representation of InventoryItems

  • Key: KDM14-131
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Currently the KDM specification for inventory model will represent each file source and/or binary file within the context of a directory structure as shown in the following fragment:
    <directory xmi:type="source:Directory" name="test" path="/home/sample/test" xmi:id="4">
    <attribute tag="link:id" value="test"/>
    <directory xmi:type="source:Directory" name="Pirates-2.1" path="/home/sample/test/Pirates-2.1" xmi:id="5">
    <attribute tag="link:id" value="Pirates-2.1">
    <directory xmi:type="source:Directory" name="src" path="/home/sample/test/Pirates-2.1/src" xmi:id="6">
    <attribute tag="link:id" value="src"/>
    <binaryFile xmi:type="source:BinaryFile" name="Tasks.o" path="/home/sample/test/Pirates-2.1/src/Tasks.o" xmi:id="7">
    <attribute tag="link:id" value="Tasks.o"/>
    </binaryFile>

    Spec does not state that "name" should be an absolute path but internally code will need to walk the object tree to compare if two files are the same at the expense of memory & resources.

    Could we just refer to "file" just as a discrete absolute path instead? This may reduce the code level complexity and reduce resource consumption during the processing of large projects. Currently we need to break down each file into its component parts which has resulted in coding errors (PRs) and forces the developer to manage a number of objects instead of dealing with a single discrete entity.

    Could we use URL instead of path? Apart from the ability to point to network level entities may further improve the implementation the KDM SDK and application level software. I also like this idea since it highlights that "file" may (which in the case of a service is always) is not referring to a file on the native file system. Application should not make is assumption as this may lead to incorrect KDM data representation.

    I would also like to use MD5 as a file ID. Currently the extractor is able to tell if a file has been modified over time or is a duplicate of another file. Thinking that a URL + MD5 attribute would be a solid foundation for inventory entries.

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 16:28 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Define path as URL and add MD5

    1. Define semantics of path attribute in InventoryItem and Directory as URL
    2. Add URL standard to normative references
    3. Clarify the semantics of path attribute in Directory, allow path attribute in InventoryItem to be relative
    4. add attribute MD5:String an MD5 hash signature of the InventoryItem

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