Issue 5812: String representation shortcut to simplify representation of complex elemen (hutn-ftf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com) Nature: Uncategorized Issue Severity: 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 Resolution: Revised Text: Actions taken: January 13, 2003: received 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 : String representation shortcut to simplify the representation of complex elements 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') ubject: interest from blind architects From: Jim Steel To: hutn-ftf@omg.org Cc: hutn@dstc.edu.au X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 17 Oct 2003 10:53:05 +1000 X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) Hi, Just to let you know, I have over the last few months had a few mails from blind people looking for a textual language for using UML, enquiring about TokTok (our HUTN prototype). I don't really have a good answer for them, for a variety of reasons: (1) the UML metamodel doesn't lend itself very well to the present HUTN generation rules (see Conrad Bock's discussions) (2) our tool doesn't have a very good integration path to major UML tools (this is my problem) Anyway, its an interesting problem, and one that I didn't envision when I was working on our HUTN submissions. Its also another good motivation for getting a good solution to issue 5812 (about string representations for complex concepts) and similar concerns, to address (1) from above. Jim. -- ---------------------------------------------------- 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 ---------------------------------------------------- The 'replacementSpec' may reference an OCL function defined at some place Subject: Temptative to resolve issue 5812 Date: Fri, 17 Oct 2003 18:32:24 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: interest from blind architects Thread-Index: AcOUSRH0+A2aHjUSSsixVNCq8v2PggAe4WTA From: "BELAUNDE Mariano FTRD/DTL/LAN" To: "Jim Steel" , Cc: X-OriginalArrivalTime: 17 Oct 2003 16:32:26.0132 (UTC) FILETIME=[3FCFAD40:01C394CC] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h9HGRoQR018953 Jim, In relation with your message, below a temptative resolution for the issue 5812 . - Add a ShorthandConfig class in the configuration metamodel The ShorthandClass need the folowing attributes: 'the_element:ModelElementRef' refers to the MOF model element (for instance: org.omg.UML13.MultiplicityElement) 'encodeOperation:OperationConfig' contains a reference to an operation that specifies how the "shorthand" value representation is obtained. 'decodeOperation:OperationConfig' contains a reference to an operation that specifies how the original value is obtained from the shorthand. - Add a OperationConfig class which refers to an operation definition, with the following attributes: 'language : String' the language used, such as OCL, ASL, future QVT... 'definition : String' contains the code definition of the operation (the signature + the body) 'resultType : String' the type name of the shorthand value (is most cases a String) 'uri : String' the location to find the operation definition (in case the 'definition' field is left empty) Hope this will help. I did not tried yet to implement this, so maybe some more elements are needed. Do not hesitate to correct/complete this or propose another way to do. Mariano -----Message d'origine----- De : Jim Steel [mailto:steel@dstc.edu.au] Envoye : vendredi 17 octobre 2003 02:53 A : hutn-ftf@omg.org Cc : hutn@dstc.edu.au Objet : interest from blind architects Hi, Just to let you know, I have over the last few months had a few mails from blind people looking for a textual language for using UML, enquiring about TokTok (our HUTN prototype). I don't really have a good answer for them, for a variety of reasons: (1) the UML metamodel doesn't lend itself very well to the present HUTN generation rules (see Conrad Bock's discussions) (2) our tool doesn't have a very good integration path to major UML tools (this is my problem) Anyway, its an interesting problem, and one that I didn't envision when I was working on our HUTN submissions. Its also another good motivation for getting a good solution to issue 5812 (about string representations for complex concepts) and similar concerns, to address (1) from above. Jim. -- ---------------------------------------------------- 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: Temptative to resolve issue 5812 From: Jim Steel To: BELAUNDE Mariano FTRD/DTL/LAN Cc: hutn-ftf@omg.org, hutn@dstc.edu.au X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 22 Oct 2003 11:11:47 +1000 X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) Mariano, Could you: - do this up as a UML class diagram (perhaps a modified version of the diagram at the start of section 5) - provide an example (perhaps UML multiplicities?) Cheers, Jim. On Sat, 2003-10-18 at 02:32, BELAUNDE Mariano FTRD/DTL/LAN wrote: > Jim, > > In relation with your message, below a temptative resolution for the > issue > 5812 . > > - Add a ShorthandConfig class in the configuration metamodel > The ShorthandClass need the folowing attributes: > 'the_element:ModelElementRef' refers to the MOF model element > (for instance: org.omg.UML13.MultiplicityElement) > 'encodeOperation:OperationConfig' contains a reference to an > operation > that specifies how the "shorthand" value representation is > obtained. > 'decodeOperation:OperationConfig' contains a reference to an > operation > that specifies how the original value is obtained from the > shorthand. > - Add a OperationConfig class which refers to an operation definition, > with > the following attributes: > 'language : String' the language used, such as OCL, ASL, future > QVT... > 'definition : String' contains the code definition of the operation > (the signature + the body) > 'resultType : String' the type name of the shorthand value > (is most cases a String) > 'uri : String' the location to find the operation definition > (in case the 'definition' field is left empty) > > Hope this will help. > I did not tried yet to implement this, so maybe some more elements are > needed. > Do not hesitate to correct/complete this or propose another way to do. > > Mariano > > > -----Message d'origine----- > De : Jim Steel [mailto:steel@dstc.edu.au] > Envoye : vendredi 17 octobre 2003 02:53 > A : hutn-ftf@omg.org > Cc : hutn@dstc.edu.au > Objet : interest from blind architects > > > > Hi, > > Just to let you know, I have over the last few months had a few mails > from blind people looking for a textual language for using UML, > enquiring about TokTok (our HUTN prototype). I don't really have a good > answer for them, for a variety of reasons: > (1) the UML metamodel doesn't lend itself very well to the present HUTN > generation rules (see Conrad Bock's discussions) > (2) our tool doesn't have a very good integration path to major UML > tools (this is my problem) > > Anyway, its an interesting problem, and one that I didn't envision when > I was working on our HUTN submissions. Its also another good motivation > for getting a good solution to issue 5812 (about string representations > for complex concepts) and similar concerns, to address (1) from above. > > Jim. > > > > -- > ---------------------------------------------------- > 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 > ---------------------------------------------------- > -- ---------------------------------------------------- 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 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 5812 : string shorthands In section 5.1 1) Add a ShorthandConfig class in the configuration metamodel This class is used to represent contained objects as simple Attribute values. The ShorthandClass has the folowing attributes: 'the_element:ModelElementRef' refers to the MOF model element (for instance: org.omg.UML13.MultiplicityElement) 'encoder:OperationConfig' contains a reference to an operation that specifies how the "shorthand" value representation is obtained. 'decoder:OperationConfig' contains a reference to an operation that specifies how the original value is obtained from the shorthand. 2) Add a OperationConfig class which refers to an operation definition, with the following attributes: 'language : String' the language used, such as OCL, ASL, future QVT... 'definition : String' contains the code definition of the operation 'operationRef : OperationRef' refers the operation (used when the 'definition' field is left empty) 3) Add an OperationRef datatype. This is an AliasType to string, for representing a MOF Operation by its fully qualified name. 4) Add at the end of the section describing the ShorthandConfig class, the following example: """Example: When representing a UML 1.3 multiplicity value, instead of: multiplicity: Multiplicity {range: MultiplicityRange {lower="1";upper="5";}} We can write: multiplicity = "1..5", having the following OCL encoding operation: Multiplicity::encode() : String = self.range.lower.toString().concat("..") .concat(self.range.upperboundToString()) MultiplicityRange::upperboundToString() : String = if self.upper=#UNLIMITED then "*" else self.upper.toString() endif; Note: the corresponding decoder could be defined using the future QVT standard.""" 5) In HUTN Document production (section 6), add the following sentence (above figure 6-9): "Contained objects which have a ShorthandConfig class instance associated with its type are not represented as references. Instead they are represented as attributes (see the attribute representation rules in 6.4)". ----------------------------------------------------