${taskforce.name} Avatar
  1. OMG Task Force

HUTN FTF — All Issues

  • Key: HUTN
  • Issues Count: 14
Open Closed All
All Issues

Issues Descriptions

Page: 6-1 to 6-18

  • Key: HUTN-4
  • Legacy Issue Number: 9365
  • Status: open  
  • Source: University College London ( James Skene)
  • Summary:

    The following serious issues exist in the BNF for the HUTN specification 1. Package Instances cannot be nested. Package instances disambiguate the type names used within them. However they cannot be nested (rule 4) and only use atomic names, so this disambiguation is limited to a single level of package nesting in this metamodel. This should be resolved by making rule 1 a choice option in rule 4. This would render rule 2 ambiguous in the case of nested packages with the same name and the use of the ';' syntax. The ';' syntax should hence be removed. 2. Class names in nested instances are atomic Nested class instances may be of a type from outside the package instance enclosing the enclosing class instance. Class names for the nested instances can therefore not be disambiguated. It should be possible to refer to the Class of nested instances using an absolute or relative type path. 3. Nested objects adjectives and contained attributes may be confused. The grammar becomes ambiguous when a contained object (rule 12), or a nested object for default containment reference (rule 22, in which ReferenceName is optional) has adjectives with the same name as attributes of the enclosing class (rule 20). ReferenceName should be made mandatory in rule 22, and the contained object rule (rule 12) should be removed (see also next issue). 4. Contained object rule inappropriate. The contained object rule (rule 12) allows an associated object to be nested in an instance that does not have a reference to it. Is nesting really appropriate in this case? Rule 12 should be removed. 5. Inconsistent restrictions on nested class instances. Non-contained references must be referenced by a ClassInstanceRef (rules 23 and 13). However the same restriction does not apply to object-typed attribute where nesting or a reference may be used, via rule 26. Given that attributes do not connote a composition relationship, this seems inconsistent. This could be resolved by either insisting that attribute values must be ClassInstanceRefs, or by removing the distinction between rules 22 and 23 with respect to contained and noncontained references.

  • Reported: HUTN 1.0 — Thu, 16 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 5.1.1

  • Key: HUTN-3
  • Legacy Issue Number: 8266
  • Status: open  
  • Source: Queensland University of Technology ( Kerry Raymond)
  • Summary:

    The description of "container" uniqueness is not quite correct. Currently it says "This value indicates that the scope or uniqueness of attribute values identifying class instances is the set of instances of this class participating in a containment relationship with the same container instance as this class does." This is not correct. What it is trying to say is (informally) this. A container object contains contained objects. Some of these contained objects will be instances of classes which have this "container" uniqueness scope, and the identifiers for these contained objects must be unique. That is, the uniqueness isn't just over objects of this class in the same container, but over objects of any class (which has container-uniquness) in the same container.

  • Reported: HUTN 1.0 — Thu, 10 Feb 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Excessive indentation due to the blocks used to delimit the package content

  • Key: HUTN-8
  • Legacy Issue Number: 5813
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Issue : Excessive indentation due to the blocks used to delimit the package contents.
    According to the current draft, the top-level definitions of a package instance need to be put inside
    a block delimited by open and close brackets. This is not very user-friendly in the sense that it
    introduces excessive indentation that could be avoided.
    Suggestion for resolution: Use a one-line delimiter convention (such as 'package "xxxxxx";') meaning
    that all the above definitions until the next delimiter are part of the package content. Note that the same
    kind of notation is found in the Java language to declare packages.
    This delimiter convention may be optional or mandatory (to be discussed).

  • Reported: HUTN 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    see below

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

Section 6.5: Need to improve readability when referencing instances

  • Key: HUTN-7
  • Legacy Issue Number: 5810
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Issue Section 6.5: Need to improve readability when referencing instances.
    Inside the class contents, due to the multiple short-hands, it's not always clear whether an instance is
    being defined (fully represented) or is being referenced .
    To avoid any possible confusion and improve readability, a "ref" prefix keyword could be added.
    Suggestion for resolution: Add the "ref" keyword in ClassInstanceRef
    [23] ClassInstanceRef := ('ref' (<ClasName>? 14:ClassRefString) ) | ExternalObjRef
    Need discussion : should the "ref" keyword be optional or mandatory?

  • Reported: HUTN 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    No Data Available

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

Issue : Section 6.3

  • Key: HUTN-6
  • Legacy Issue Number: 5809
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue : Section 6.3 : Ambiguous meaning when omitting opening and closing brackets
    In 6.3 in the first paragraph it's said that opening and closing brackets should be optionnaly omitted
    if the instance has no contents. This is error prone and ambiguous since one cannot distinguish between
    a definition without contents from a contained instance whose definition (full representation) is forwarded.
    Suggestion for resolution: remove the sentence (open and close brackets are not allowed to be omitted).

  • Reported: HUTN 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    see below

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

Issue : Section 6.5

  • Key: HUTN-5
  • Legacy Issue Number: 5808
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Issue : Section 6.5 : Missing where to put the full representation of a non inlined contained instance.
    According to the specification, a contained instance maybe represented by a full representation
    of the instance or by a reference to the instance. However, in the latter case, the specification does
    noy say nothing about where to place the full representation of the contained instances that are not
    inlined.
    Suggestion for resolution:
    In the second paragraph, after "or by a reference to the instance.", add the following sentence:
    "In the latter case the full representation of the contained instance must appear as a top level
    definition in the content of the current package.
    In addition, in order to distinguish between these "forwarded" definitions and the other
    "top-level" definitions we should consider introducing a prefix keyword (such as "forward",
    to be added in the ClassHeader).

  • Reported: HUTN 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    see below

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

Section 1.3 : Add text regarding the France Telecom implementation of HUTN

  • Key: HUTN-11
  • Legacy Issue Number: 5816
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Below the proposed text:
    France Telecom has developped since 1997 a MOF based model repository tool [Belaunde99] and has
    implemented since 1999 facilities to import and export textual human usable specifications that use a
    Java-like syntax (the notation was originnally named JMI) and a hierarchical identification system. The
    implementation uses a generic parser that is connected at run time to the API's generated from the MOF
    compliant metamodel definitions (No intermediate BNF parser generation is then used). France Telecom has
    provided feedback to the submitters based on its original implementation.

  • Reported: HUTN 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    see below

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

Update the list of persons in the acknowledgments paragraph

  • Key: HUTN-10
  • Legacy Issue Number: 5815
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Issue : Preface : Update the list of persons in the acknowledgments paragraph
    In the current submission only two persons are mentioned (Kerry Raymond and Keith Duddy). Other
    persons such as Jim Steel and Mariano Belaunde should appear.

  • Reported: HUTN 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    see above

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

The identification mechanism need to be more flexible

  • Key: HUTN-9
  • Legacy Issue Number: 5814
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Issue : The identification mechanism need to be more flexible to make easier the automatic production
    of HUTN renderings from modeling tools.
    The proposed identification mechanism is too rigid and very difficult to manage appropriately when
    HUTN renderings are produced automatically from use case tools.

  • Reported: HUTN 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    see below

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

String representation shortcut to simplify representation of complex elemen

  • Key: HUTN-2
  • Legacy Issue Number: 5812
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Sometimes the representation based in the metamodel is too complex, and some simplifications can be
    taken. As an example, when representing multiplicities, the UML MM has a very complex way to do that.
    However a compact string representation for multiplicities already exists and is widely used. The HUTN
    should allow the users to use the special textual representations when available.
    For instance: the string datavalue "1..5" culd be used instaed of
    ... Multiplicity {range: MultiplicityRange {lower="1";upper="5";}}
    Suggestion for resolution: Enhance the configuration Metamodel with a ElementSubstitutionConfig
    metaclass declaring the replacement and the string convention to be used
    (attributes 'the_element : ModelElementRef' and 'replacementSpec : String')
    The 'replacementSpec' may reference an OCL function defined at some place

  • Reported: HUTN 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5 : Missing containment information when referencing class instances

  • Key: HUTN-1
  • Legacy Issue Number: 5811
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    When referencing an instance (ClassInstanceRef), the user needs to look at the metamodel in order
    to know if it is a contained reference or a non contained reference (BNF rules 22 and 23).
    Suggestion 1 for resolution: Use a "forward" prefix keyword when referencing contained instances that
    are fully represented in another place (that are not inlined).
    Suggestion 2 for resolution : Use a "ref" keyword when referencing non contained instances and use no
    keyword to reference contained instances not inlined.
    Note: The resolution of this issue may depend on the resolution of "need to improve readability when
    referencing instances"

  • Reported: HUTN 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

classifier level attributes

  • Key: HUTN-12
  • Legacy Issue Number: 5876
  • Status: closed  
  • Source: DSTC ( Anna Gerber)
  • Summary:

    The document does not address how classifier level attributes are
    represented by HUTN

  • Reported: HUTN 1.0b1 — Mon, 3 Mar 2003 05:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    see below

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

On page 6-13, production rule [31]

  • Key: HUTN-14
  • Legacy Issue Number: 6701
  • Status: closed  
  • Source: Queensland University of Technology ( Jim Steel)
  • Summary:

    : On page 6-13, production rule [31] states:
    [31] AssocInstance := 32:AssocInstance | 35:InfixAssocLink
    This should be 32:AssocBlock, not 32:AssocInstance
    Proposed Resolution: On page 6-13, in section 6.7, replace
    "[31] AssocInstance := 32:AssocInstance | 35:InfixAssocLink"
    with
    "[31] AssocInstance := 32:AssocBlock | 35:InfixAssocLink"

  • Reported: HUTN 1.0b1 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    see below

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

page 3-1, in section 3.2, "Input Stream Conformance

  • Key: HUTN-13
  • Legacy Issue Number: 5997
  • Status: closed  
  • Source: Queensland University of Technology ( Jim Steel)
  • Summary:

    on page 3-1, in section 3.2, "Input Stream Conformance":

    • "For a given combination of MOF model and HUTN Configuration" should
      be replaced with "For all given combinations of MOF models and HUTN
      Configurations".
  • Reported: HUTN 1.0b1 — Wed, 16 Jul 2003 04:00 GMT
  • Disposition: Resolved — HUTN 1.0
  • Disposition Summary:

    see below

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