Issue 5814: The identification mechanism need to be more flexible (hutn-ftf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde@orange-ftgroup.com) Nature: Uncategorized Issue Severity: 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. Resolution: see below Revised Text: 1) In the configuration metamodel add the "property_in_container" enumeration value in "UniquenessScope" enumeration type, with the following explanation: "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 and the same containment relationship as this class does". 2) Add the following example at the end of "UniquenessScope" section. "Example: Typical identifier for a UML class contained in a UML Package: MyPackage.MyClass, if 'container' is used MyPackage.ownedElement.MyClass, if 'property_in_container' is used" 3) Within the HUTN document production document, in last paragraph, in 6-5 page, before "To indicate …", insert the sentence: "If container is used then a level is represented by a single string, which is the container's identifier. If property_in_container is used then a level is represented by two strings separated by a delimiter: the container's identifier and the property name of the containment association." 4) Add some text to clarify that it is possible to override the usage of attribute identifiers. More precisely, in 5.1.6, within the paragraph describing the 'id_attribute', add the following sentence: "If this attribute is non null, a specific instance of this class may use or may not use the value of the identifying attribute as the identifier. If the latter case, both the arbitrary identifier and the identifying attribute value should be provided within the HUTN representation of the instance." Actions taken: January 13, 2003: received issue September 24, 2004: closed issue Discussion: End of Annotations:===== Subject: Issues for the HUTN FTF Date: Mon, 13 Jan 2003 16:54:49 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues for the HUTN FTF Thread-Index: AcK7HBpU397iUQ+WTOq/6odFTDzC5g== From: "BELAUNDE Mariano FTRD/DTL/LAN" To: "Juergen Boldt" Cc: X-OriginalArrivalTime: 13 Jan 2003 15:54:50.0281 (UTC) FILETIME=[1ACB6190:01C2BB1C] Juergen, You will find below 9 issues for the HUTN FTF. Thanks in advance, Mariano -------------------------------- 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 Subject: Re: Proposed resolution for issues 5812 and 5814 From: Jim Steel To: BELAUNDE Mariano FTRD/DTL/LAN , hutn-ftf@omg.org X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 07 Jan 2004 13:26:10 +1000 X-Scanned-By: MIMEDefang 2.38 Mariano, Thanks for those proposed resolutions. I couldn't agree more that good solutions to them will make a great improvement to the standard. Some comments, though. Regarding the string shorthands resolution, I think it is the right solution, but that we probably need to think about its implications for conformance as well. Also, I really think it is too big of a change for an FTF. Talking with Keith as a former AB member, he agrees. As such, I'd really rather defer the issue to an RTF. Regarding the identification techniques, it seems to be divided into 3 separate considerations. If we could split the 3, then I'd feel comfortable about putting them to ballot. Parts 1-3, about property_in_container, seems fine. Part 4 seems to suggest that it is possible to use arbitrary identifiers even when an identifying attribute has been configured. I think this makes referencing very complicated, and probably isn't really helpful. Part 5, about global identifiers, I don't think is really necessary. If all classes use a single identification technique, its generally through inheritance, and I don't think the proposed change really adds much. What do you think? For any of these, we really need to put a ballot tomorrow, closing next Thursday, if I am to include them in a report next Friday. Cheers, Jim. On Tue, 2004-01-06 at 01:00, BELAUNDE Mariano FTRD/DTL/LAN wrote: > Hi Jim and all, > > I believe that it would be better to solve these two issues (5812 and > 5814) before > ending this FTF, because these are quite important to make HUTN more > usable. > It would take a lot of time and work if we postpone them to a future RTF > (at least one year). > Attached (see the word document), my proposed resolutions, which I think > would carry > minimal impact on the current specification. > I have included the updated version of the configuration metamodel (a > class diagram). > Feel free to make any comment on this proposal. > > Happy new year! > Mariano > <> > > -- ---------------------------------------------------- Jim Steel Research Scientist, DSTC steel@dstc.edu.au Ph: +61 7 3365 4310 "Why write something in five days that you can spend five years automating?" - Terence Parr, ANTLR guy ---------------------------------------------------- Subject: RE : Proposed resolution for issues 5812 and 5814 Date: Wed, 7 Jan 2004 12:40:33 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed resolution for issues 5812 and 5814 Thread-Index: AcPUzgMv0ZWwLlYuS8S3lvt13sE7NQAM/A5A From: "BELAUNDE Mariano FTRD/DTL/LAN" To: "Jim Steel" , X-OriginalArrivalTime: 07 Jan 2004 11:40:34.0607 (UTC) FILETIME=[100083F0:01C3D513] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i07BaGv6026464 Jim, I'm OK for deferring issue 5812, since you feel it's too big for the FTF. Let's then discuss on the three aspects of 5814. >> Parts 1-3, about property_in_container, seems fine. Great! >> Part 4 seems to suggest that it is possible to use arbitrary >> identifiers even when an identifying attribute has been configured. Yes this is the intend. The implicance would be that a HUTN configuration indicates "potential" attribute identification instead of "mandatory". >> I think this makes referencing very complicated, and probably >> isn't really helpful. It provides more flexibility for end-users. Suppose you are rendering a UML 1.3 diagram. In most cases, within a state machine, ActionStates can simply be distinguished using the 'name' attribute. Because of this, when I edit manually the HUTN rendering I will tend to use the "name" attribute as an identifying attribute for the action states. Now, if I produce automatically the HUTN rendering from a graphical tool, I won't be able to make such assumption, because in the general case, the "name" is not a distinguishing attribute for action states. So as a consequence, I won't be able to use the same HUTN configuration data I used, naivily, when editing it manually. So if we provide this facility ("potential" instead of "mandatory"), an automatic HUTN generator would be able to produce distinct identifiers when duplicates are detected - this can be implemented on a generic way. In the other hand, manually edited HUTN will need less effort because the users won't need to care about some subtilities in the metamodel regarding unicity. Finally, it will be easier to define "reusable" HUTN configurations (for instance: for UML2, we simply configure the NamedElement abstract class and we don't need, at this stage, to specify in what concrete classes 'name' is not used as a distiguishing identifier). So as I conclusion, I see various practical advantages on this. I don't know why do you think this makes referencing more complex. Referencing is normally based on identifiers, whatever is the relationship an identifier may have with an attribute. >> Part 5, about global identifiers, I don't think is really necessary. >> If all classes use a single identification technique, its generally >> through inheritance, and I don't think the proposed change really >> adds much. Agree. So my suggestion would be for the next ballot. - ask again for deferring 5812 - propose 5814 resolution (with part on global identifiers suppressed) What do you think? Cheers, Mariano -----Message d'origine----- De : Jim Steel [mailto:steel@dstc.edu.au] Envoyé : mercredi 7 janvier 2004 04:26 À : BELAUNDE Mariano FTRD/DTL/LAN; hutn-ftf@omg.org Objet : Re: Proposed resolution for issues 5812 and 5814 Mariano, Thanks for those proposed resolutions. I couldn't agree more that good solutions to them will make a great improvement to the standard. Some comments, though. Regarding the string shorthands resolution, I think it is the right solution, but that we probably need to think about its implications for conformance as well. Also, I really think it is too big of a change for an FTF. Talking with Keith as a former AB member, he agrees. As such, I'd really rather defer the issue to an RTF. Regarding the identification techniques, it seems to be divided into 3 separate considerations. If we could split the 3, then I'd feel comfortable about putting them to ballot. Parts 1-3, about property_in_container, seems fine. Part 4 seems to suggest that it is possible to use arbitrary identifiers even when an identifying attribute has been configured. I think this makes referencing very complicated, and probably isn't really helpful. Part 5, about global identifiers, I don't think is really necessary. If all classes use a single identification technique, its generally through inheritance, and I don't think the proposed change really adds much. What do you think? For any of these, we really need to put a ballot tomorrow, closing next Thursday, if I am to include them in a report next Friday. Cheers, Jim. On Tue, 2004-01-06 at 01:00, BELAUNDE Mariano FTRD/DTL/LAN wrote: > Hi Jim and all, > > I believe that it would be better to solve these two issues (5812 and > 5814) before > ending this FTF, because these are quite important to make HUTN more > usable. It would take a lot of time and work if we postpone them to a > future RTF (at least one year). > Attached (see the word document), my proposed resolutions, which I think > would carry > minimal impact on the current specification. > I have included the updated version of the configuration metamodel (a > class diagram). > Feel free to make any comment on this proposal. > > Happy new year! > Mariano > <> > > -- ---------------------------------------------------- Jim Steel Research Scientist, DSTC steel@dstc.edu.au Ph: +61 7 3365 4310 "Why write something in five days that you can spend five years automating?" - Terence Parr, ANTLR guy Resolution for issue 5814: More identification techniques 1) In the configuration metamodel add the "property_in_container" enumeration value in "UniquenessScope" enumeration type, with the following explanation: "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 and the same containment relationship as this class does". 2) Add the following example at the end of "UniquenessScope" section. Example: Typical identifier for a UML class contained in a UML Package: MyPackage.MyClass, if 'container' is used MyPackage.ownedElement.MyClass, if 'property_in_container' is used 3) Within the HUTN document production document, in last paragraph, in 6-5 page, before "To indicate …", insert the sentence: "If container is used then a level is represented by a single string, which is the container's identifier. If property_in_container is used then a level is represented by two strings separated by a delimiter: the container's identifier and the property name of the containment association. 4) Add some text to clarify that it is possible to override the usage of attribute identifiers. More precisely, in 5.1.6, within the paragraph describing the 'id_attribute', add the following sentence: "If this attribute is non null, a specific instance of this class may use or may not use the value of the identifying attribute as the identifier. If the latter case, both the arbitrary identifier and the identifying attribute value should be provided within the HUTN representation of The instance. 5) Allow usage of IdentifierConfig with a null value for the classref attribute, meaning default identifier configuration for ALL classes. More precisely, in 5.1.6, before the decription of "id_attribute" field, add the following sentence: "If the_class attribute has a null value then this IdentifierConfig applies by default to all the classes. This facility can be used to set the uniquenessScope attribute to a global and constant value that applies to all the represented instances." HUTN renderings are produced automatically from use case tools.