Issues for Human -usable Textual Notation Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5811: 6.5 : Missing containment information when referencing class instances
Issue 5812: String representation shortcut to simplify representation of complex elemen
Issue 8266: Section: 5.1.1
Issue 9365: Page: 6-1 to 6-18

Issue 5811: 6.5 : Missing containment information when referencing class instances (hutn-ftf)

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" 

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

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.

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.