Issue 11863: concept of refinement (marte-ftf) Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com) Nature: Clarification Severity: Minor Summary: Does the concept of refinement only apply to clock refinement. My first impression is that this concepts may apply to other NFPs. In any case, this needs to be clarified Resolution: There is agreement to extend the Refinement to any kind of NFP constraints. Issue 11864 required to use the same name in the domain model and in the UML representation so we chose NFPRefine for the name. The resolution replaces every occurrence of ClockRefine by NFPRefine. It also replaces the association to Time::ClockConstraint by an association to NFPs::NfpConstraint. In the domain model, the metaclass Refinement is associated to NFP_Constraint instead of ClockConstraint. The second constraint is removed since it was assuming all constraints were ClockConstraint. Revised Text: In section 12.2, page 138, change figure 12.2, into: In section 12.2, page 137, change text: Figure 12.1 shows a general view of allocation, while Figure 12.2 shows the refinement relations. Allocations are annotated with NfpConstraints as built from the NFP section of this document and refinement are more precisely annotated with ClockConstraints as defined in the Time Model section (chapter 9). Allocations provide links between independent models, while refinement/abstraction works by changing the focus on an underlying similar structure. Into: Figure 12.1 shows a general view of allocation, while Figure 12.2 shows the refinement relations. Both the Allocations and the refinement are annotated with NFP_Constraints as built from the NFP section. Time constraints can also be associated since the metaclass NFP_Constraints is a generalization of the metaclass ClockConstraint defined in the Time Model section (chapter 9). Allocations provide links between independent models, while refinement/abstraction works by changing the focus on an underlying similar structure. In section 12.2, page 138, change text: Time::ClockConstraint specializes NFP_Annotations::NfpConstraint, using such constraints provides time links between the clients and the suppliers. Into: The refinement process generally involves the definition of additional constraints to precise links between the general element and the refined ones. For instance, one may want to specify how the time bases relates, how the bandwidth (or power consumption …) is spread amongst refined elements. The association with some NFPs::NFP_Annotations::NfpConstraint is a provision for defining such links. In section 12.3.1, page 140, change figure 12.6, into: In section 12.3.1, page 140, change text: Concerning the refinement we also think it is important to emphasize the fact that the refinement process implies some additional constraints that mostly concern clocks as defined in the Time Model package. into: Concerning the refinement we also think it is important to emphasize the fact that the refinement process implies some additional constraints. It could be ClockConstraints to relate clocks at the different abstraction level or any other NfpConstraint. Replace section 12.3.2.7 by: 12.3.2.7 NfpRefine (from Alloc) The stereotype NfpRefine maps the domain element Refinement (section F.6.5) denoted in Annex F. NfpRefine is a dependency based on UML::Dependency. It is a mechanism for associating one abstract model element to refined model elements. It is a provision for grouping elements. The refinement process implies some additional constraints between the abstract element and the refined elements. When several application model elements are to be collectively allocated to execution platform elements they should first be grouped using the dependency NfpRefine. Some NfpConstraints, like for instance ClockConstraint, should be associated with this dependency to specify relations between the general element and the refined ones. Extensions o Dependency (from Dependencies). Associations o constraints: NFPs::NfpConstraint [*] The set of constraints implied by the refinement. Constraints [1] A single dependency NfpRefine shall have only one client (from), but may have one or many suppliers (to). context NfpRefine inv: base_Dependency.from->size()=1 and base_Dependency.to->size()>=1 Notation The relationship NfpRefine is a dashed line with an open arrow head. The arrow points in the direction of the refinement. In other words, the directed line points "from" the element being refined "to" the elements that are the refined elements. In section F.6.5 subsection Associations, page 544, insert the following association at the end of the list: o constraints: NFPs::NFP_Annotation::NFP_Constraint [*] The set of constraints implied by the refinement. Actions taken: December 21, 2007: received issue February 17, 2010: closed issue Discussion: see ptc/2008-06-05 for revised text (graphics) End of Annotations:===== m: webmaster@omg.org Date: 21 Dec 2007 13:31:21 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sébastien Demathieu Company: Thales mailFrom: sebastien.demathieu@thalesgroup.com Notification: Yes Specification: UML profile for MARTE Section: 12 FormalNumber: 07-08-04 Version: Beta 1 RevisionDate: 08/2007 Page: 138 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Description Does the concept of refinement only apply to clock refinement. My first impression is that this concepts may apply to other NFPs. In any case, this needs to be clarified. X-IronPort-AV: E=Sophos;i="4.25,345,1199660400"; d="scan'208";a="22570805" Date: Wed, 13 Feb 2008 10:07:25 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: marte-ftf@omg.org Subject: allow_wg: ISSUE 11863 and 11864 from Thales Concerning the issue "The Refinement metaclass relates to the ClockRefinement stereotype. Names should be identical." I have a problem with this one. I agree on the principle but <> already exists in the standard profile L2 of UML superstructure. How do we add semantics to existing stereotypes ? Having another stereotype called Refinement could be the source of multiple confusions. That is why I chose the wording "ClockRefinement". If I try to take into account issue 11863 "Does the concept of refinement only apply to clock refinement. My first impression is that this concepts may apply to other NFPs. In any case, this needs to be clarified" I propose to replace the Refinement metaclass (in the domain model) by NFPRefinement, rename the ClockRefinement stereotype into NFPRefinement and associate with this new stereotype implied NFPConstraints instead of ClockConstraints. Proposition: - Transfer issue 11864 to issue 11863 (Is that the appropriate use of the 'Transferred' status ?). - draft for a resolved resolution that tackles both issues Regards, Frédéric Mallet. p.s.: Note that we have a new issue 12214 that I made to maintain alignment with the SysML RTF. Subject: RE: allow_wg: ISSUE 11863 and 11864 from Thales Date: Wed, 13 Feb 2008 10:09:42 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: allow_wg: ISSUE 11863 and 11864 from Thales thread-index: AchuH/o8hlXSGqmFQXK1z9kmqgq9DwAAC1hQ From: "GERARD Sebastien 166342" To: "Frederic Mallet" , X-OriginalArrivalTime: 13 Feb 2008 09:10:25.0761 (UTC) FILETIME=[451D3510:01C86E20] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m1D9CF0q009096 Sounds good for me. Date: Wed, 13 Feb 2008 10:22:06 +0100 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: Frederic Mallet Cc: marte-ftf@omg.org Subject: Re: allow_wg: ISSUE 11863 and 11864 from Thales X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m1D9MK0l011426 Hi Frédéric, I'm fine with that. If you consider that this kind of relationship is applicable to other elements than clocks (it seems to be the case to me), then renaming both metaclass and stereotype to NFPRefinement (or a similar name) would make sense. Thanks, Sébastien X-IronPort-AV: E=Sophos;i="4.25,358,1199660400"; d="scan'208";a="9243628" Date: Fri, 15 Feb 2008 17:05:39 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: marte-ftf@omg.org, Sébastien Demathieu , lonnie.vanzandt@artisansw.com Subject: alloc_wg: ISSUE 11863 Hi everyone that feels concerned about the allocation, I have uploaded a resolution draft for Issue 11863 in which ClockRefine is replaced by NfpRefine and NfpConstraints is used instead of ClockConstraints. Even though it is a draft I did not use the so called "draft recommandation document" because being a draft is an orthogonal status and it is useful to know what kind of resolution we are aiming at (resolved, closedNoChange,...). So I mentioned the status draft both in the name 11863_resolved_draft.doc and as a note. Using a wiki page really is a good solution, I will do it if ever some issues induce any strong interaction. Do not forget to send your comments/modifications before the beginning of the voting period (March, 17th). Regards, Frédéric. Subject: RE: alloc_wg: ISSUE 11863 Date: Mon, 18 Feb 2008 11:13:59 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: alloc_wg: ISSUE 11863 thread-index: Achv7KF+rZ5+v/FjQBqrK/lHGk7isgAAS8NMAIo8b2A= From: "GERARD Sebastien 166342" To: "VanZandt, Lonnie" , "Frederic Mallet" , , Sébastien Demathieu X-OriginalArrivalTime: 18 Feb 2008 10:14:00.0073 (UTC) FILETIME=[FAAFC790:01C87216] Hi, I have nothing against the wiki page idea, but when a resolution is considered as closed (consensus is reached) please provide the word file. It will be easier to compile the FTF report doc at the end and the ballot doc for voting. Thanks,, Séb -------------------------------------------------------------------------------- De : VanZandt, Lonnie [mailto:lonnie.vanzandt@artisansw.com] Envoyé : vendredi 15 février 2008 17:14 À : Frederic Mallet; marte-ftf@omg.org; Sébastien Demathieu Objet : RE: alloc_wg: ISSUE 11863 I'm pleased that you like the wiki page idea. Do know that in the Draft template, I put a field for "Recommended Resolution". That is where one would indicate the foreseen resolution for the issue: Resolved, NoChange, Transferred, etc. I'm pragmatic though: use what works for you. Lonnie VanZandt Field Applications Engineer Denver, CO Artisan Software Tools mobile: 720 201-1349 desk: 303 482-2943 lonnie.vanzandt@artisansw.com -------------------------------------------------------------------------------- From: Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Sent: Fri 2/15/2008 9:05 AM To: marte-ftf@omg.org; Sébastien Demathieu; VanZandt, Lonnie Subject: alloc_wg: ISSUE 11863 Hi everyone that feels concerned about the allocation, I have uploaded a resolution draft for Issue 11863 in which ClockRefine is replaced by NfpRefine and NfpConstraints is used instead of ClockConstraints. Even though it is a draft I did not use the so called "draft recommandation document" because being a draft is an orthogonal status and it is useful to know what kind of resolution we are aiming at (resolved, closedNoChange,...). So I mentioned the status draft both in the name 11863_resolved_draft.doc and as a note. Using a wiki page really is a good solution, I will do it if ever some issues induce any strong interaction. Do not forget to send your comments/modifications before the beginning of the voting period (March, 17th). Regards, Frédéric. Subject: RE: allow_wg: ISSUE 11863 Date: Thu, 21 Feb 2008 10:10:57 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: allow_wg: ISSUE 11863 thread-index: Ach0aWunraCCHKmLQ3KYZZqRaYcpsAAADH0g From: "ESPINOZA Huascar 218344" To: "Frederic Mallet" , Cc: "GERARD Sebastien 166342" , Sébastien Demathieu X-OriginalArrivalTime: 21 Feb 2008 09:10:58.0369 (UTC) FILETIME=[ABDACB10:01C87469] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m1L9AbMv011533 allocConstraint -----Message d'origine----- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé : jeudi 21 février 2008 10:07 À : marte-ftf@omg.org Cc : GERARD Sebastien 166342; Sébastien Demathieu Objet : allow_wg: ISSUE 11863 Hi, It appears that I had forgotten to replace ClockConstraint by NFP_Constraint in the metamodel (thank you to Sébastien Demathieu who has noticed that), consequently I have uploaded a new resolution proposition. called 11863_resolved_draft2.doc. In that new resolution, I have also updated the annex F (Domain Class Descriptions) => SG. Please comment before the start of the voting period (March, 17th). Besides, Sébastien D. and I have agreed that NFPRefinement is definitely not the right name for the metamodel. Refinement was the name chosen because it was the inverse operation of the abstraction and the purpose is to enrich the UML refinement by some new constraints. Sébastien thinks we may try to find a more precise name to make explicit the difference with the UML refinement (i.e, one source, several targets + explicit "cost" constraints). Anyone is welcome to make a proposition to qualify the MARTE refinement. Regards, Frédéric. Subject: RE: allow_wg: ISSUE 11863 Date: Thu, 21 Feb 2008 10:14:28 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: allow_wg: ISSUE 11863 thread-index: Ach0aWunraCCHKmLQ3KYZZqRaYcpsAAADH0gAAAd8rA= From: "ESPINOZA Huascar 218344" To: "Frederic Mallet" , Cc: "GERARD Sebastien 166342" , Sébastien Demathieu X-OriginalArrivalTime: 21 Feb 2008 09:14:29.0813 (UTC) FILETIME=[29E29650:01C8746A] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m1L9EZiO012054 Sorry, allocRefinement -----Message d'origine----- De : ESPINOZA Huascar 218344 Envoyé : jeudi 21 février 2008 10:11 À : 'Frederic Mallet'; marte-ftf@omg.org Cc : GERARD Sebastien 166342; Sébastien Demathieu Objet : RE: allow_wg: ISSUE 11863 allocConstraint -----Message d'origine----- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé : jeudi 21 février 2008 10:07 À : marte-ftf@omg.org Cc : GERARD Sebastien 166342; Sébastien Demathieu Objet : allow_wg: ISSUE 11863 Hi, It appears that I had forgotten to replace ClockConstraint by NFP_Constraint in the metamodel (thank you to Sébastien Demathieu who has noticed that), consequently I have uploaded a new resolution proposition. called 11863_resolved_draft2.doc. In that new resolution, I have also updated the annex F (Domain Class Descriptions) => SG. Please comment before the start of the voting period (March, 17th). Besides, Sébastien D. and I have agreed that NFPRefinement is definitely not the right name for the metamodel. Refinement was the name chosen because it was the inverse operation of the abstraction and the purpose is to enrich the UML refinement by some new constraints. Sébastien thinks we may try to find a more precise name to make explicit the difference with the UML refinement (i.e, one source, several targets + explicit "cost" constraints). Anyone is welcome to make a proposition to qualify the MARTE refinement. Regards, Frédéric. X-IronPort-AV: E=Sophos;i="4.25,385,1199660400"; d="scan'208";a="9416548" Date: Thu, 21 Feb 2008 10:33:14 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: ESPINOZA Huascar 218344 Cc: marte-ftf@omg.org Subject: Re: allow_wg: ISSUE 11863 Then we have allocRefinement and Allocation, so we should replace Allocation by allocAllocation ?? The purpose is to say that Refinement and Allocation are two distinct but complementary mechanismes. Having a name where both word appears is not a good solution to say there are different things. Frédéric. ESPINOZA Huascar 218344 a écrit : Sorry, allocRefinement -----Message d'origine----- De : ESPINOZA Huascar 218344 Envoyé : jeudi 21 février 2008 10:11 À : 'Frederic Mallet'; marte-ftf@omg.org Cc : GERARD Sebastien 166342; Sébastien Demathieu Objet : RE: allow_wg: ISSUE 11863 allocConstraint -----Message d'origine----- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé : jeudi 21 février 2008 10:07 À : marte-ftf@omg.org Cc : GERARD Sebastien 166342; Sébastien Demathieu Objet : allow_wg: ISSUE 11863 Hi, It appears that I had forgotten to replace ClockConstraint by NFP_Constraint in the metamodel (thank you to Sébastien Demathieu who has noticed that), consequently I have uploaded a new resolution proposition. called 11863_resolved_draft2.doc. In that new resolution, I have also updated the annex F (Domain Class Descriptions) => SG. Please comment before the start of the voting period (March, 17th). Besides, Sébastien D. and I have agreed that NFPRefinement is definitely not the right name for the metamodel. Refinement was the name chosen because it was the inverse operation of the abstraction and the purpose is to enrich the UML refinement by some new constraints. Sébastien thinks we may try to find a more precise name to make explicit the difference with the UML refinement (i.e, one source, several targets + explicit "cost" constraints). Anyone is welcome to make a proposition to qualify the MARTE refinement. Regards, Frédéric. Date: Thu, 21 Feb 2008 10:48:49 +0100 From: Julio Medina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Frederic Mallet Cc: marte-ftf@omg.org, GERARD Sebastien 166342 , Sébastien Demathieu Subject: Re: allow_wg: ISSUE 11863 X-OriginalArrivalTime: 21 Feb 2008 09:48:51.0526 (UTC) FILETIME=[F6C30660:01C8746E] X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:5.0.1023(15742.003) X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:2 S:2 R:2 (0.0000 0.0000) Could it be: concretion particularization Frederic Mallet wrote: Hi, It appears that I had forgotten to replace ClockConstraint by NFP_Constraint in the metamodel (thank you to Sébastien Demathieu who has noticed that), consequently I have uploaded a new resolution proposition. called 11863_resolved_draft2.doc. In that new resolution, I have also updated the annex F (Domain Class Descriptions) => SG. Please comment before the start of the voting period (March, 17th). Besides, Sébastien D. and I have agreed that NFPRefinement is definitely not the right name for the metamodel. Refinement was the name chosen because it was the inverse operation of the abstraction and the purpose is to enrich the UML refinement by some new constraints. Sébastien thinks we may try to find a more precise name to make explicit the difference with the UML refinement (i.e, one source, several targets + explicit "cost" constraints). Anyone is welcome to make a proposition to qualify the MARTE refinement. Regards, Frédéric. Subject: RE: allow_wg: ISSUE 11863 Date: Thu, 21 Feb 2008 10:50:10 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: allow_wg: ISSUE 11863 thread-index: Ach0bM4x2fa/8nWqSm2H5bjFYPs6kAAAFqGA From: "ESPINOZA Huascar 218344" To: "Frederic Mallet" Cc: X-OriginalArrivalTime: 21 Feb 2008 09:50:11.0226 (UTC) FILETIME=[264447A0:01C8746F] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m1L9qiO9020095 Sorry, I overlooked the issue. Let's understand the issue. The first thing is that the relationship between Refinement and Constraints (NfpConstraint) has not been explained in the current domain model. That is an important point if you want people is aware of your approach. As far as I understand, you use the constraint to specify the mapping of elements from an abstract model to a more refined model of the same system (or part of a system). Additionally, you add clock constraint to express some relationships between time properties of both, abstract and refined models. Is that right? Thanks, Huascar -----Message d'origine----- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé : jeudi 21 février 2008 10:33 À : ESPINOZA Huascar 218344 Cc : marte-ftf@omg.org Objet : Re: allow_wg: ISSUE 11863 Then we have allocRefinement and Allocation, so we should replace Allocation by allocAllocation ?? The purpose is to say that Refinement and Allocation are two distinct but complementary mechanismes. Having a name where both word appears is not a good solution to say there are different things. Frédéric. ESPINOZA Huascar 218344 a écrit : > Sorry, allocRefinement > > -----Message d'origine----- > De : ESPINOZA Huascar 218344 > Envoyé : jeudi 21 février 2008 10:11 > À : 'Frederic Mallet'; marte-ftf@omg.org > Cc : GERARD Sebastien 166342; Sébastien Demathieu > Objet : RE: allow_wg: ISSUE 11863 > > allocConstraint > > -----Message d'origine----- > De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] > Envoyé : jeudi 21 février 2008 10:07 > À : marte-ftf@omg.org > Cc : GERARD Sebastien 166342; Sébastien Demathieu > Objet : allow_wg: ISSUE 11863 > > Hi, > > It appears that I had forgotten to replace ClockConstraint by > NFP_Constraint in the metamodel (thank you to Sébastien Demathieu who > has noticed that), consequently I have uploaded a new resolution > proposition. called 11863_resolved_draft2.doc. > In that new resolution, I have also updated the annex F (Domain Class > Descriptions) => SG. > > Please comment before the start of the voting period (March, 17th). > > Besides, Sébastien D. and I have agreed that NFPRefinement is definitely > not the right name for the metamodel. Refinement was the name chosen > because it was the inverse operation of the abstraction and the purpose > is to enrich the UML refinement by some new constraints. Sébastien > thinks we may try to find a more precise name to make explicit the > difference with the UML refinement (i.e, one source, several targets + > explicit "cost" constraints). Anyone is welcome to make a proposition to > qualify the MARTE refinement. > > Regards, > > Frédéric. > X-IronPort-AV: E=Sophos;i="4.25,385,1199660400"; d="scan'208";a="22861624" Date: Thu, 21 Feb 2008 11:16:11 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: ESPINOZA Huascar 218344 Cc: marte-ftf@omg.org Subject: Re: allow_wg: ISSUE 11863 ESPINOZA Huascar 218344 a écrit : Sorry, I overlooked the issue. Let's understand the issue. The first thing is that the relationship between Refinement and Constraints (NfpConstraint) has not been explained in the current domain model. That is an important point if you want people is aware of your approach. It has now been explained in the proposed resolution. As far as I understand, you use the constraint to specify the mapping of elements from an abstract model to a more refined model of the same system (or part of a system). Additionally, you add clock constraint to express some relationships between time properties of both, abstract and refined models. Is that right? In the beta1 specification, we used ClockConstraint because we knew we could make a link between time bases of the abstract model element and the time bases of the refined ones. Sébastien proposes to generalize that. He thinks we can make link between other NFPs. Thinking about that I imagined that we could indeed have some links between power consumption properties (a constraint that would explain how the power budget is spread amongst refined elements) and probably other NFPs (any specific ideas ?). I have modified the profile to associate a NfpConstraint instead of a ClockConstraint (to be more general). In the first resolution I forgot to modify the metamodel and to replace ClockConstraint by NFP_Constraint (different name than NfpConstraint by the way ?). In the new resolution I have corrected that. Besides this aspect, Sébastien thought that since we want to refine the UML refinement, we could try to find a more precise name that explicitly states the difference with the UML refinement. Finding a completely different name is not a good solution since people are used to think of refinement as the inverse operation of the abstraction. The only solution would be to qualify refinement. Here are the differences between MARTE Refinement and UML Refinement: - The UML <> stereotype extends the Abstraction metaclass. This is really not a good idea since they are inverse operations. - The MARTE <> stereotype extends the Dependency metaclass and specifies that this dependency must have only one source (the abstracted element) and several targets (the refined elements). This is the exact definition of Refinement. Since we had to modify this stereotype (or rather to create a new one because we are not allowed to modify existing stereotypes), we took the opportunity to make explicit the fact that refinement in RTES usually implies some additional constraints. As a consequence of all that, I start thinking that may be this is a issue of UML and not of MARTE. Refinement seems to be right word but the UML implementation is not satisfactory. Would you agree to keep Refinement and send an issue to UML so they can consider extending Dependency instead of Abstraction ? Frédéric. Subject: RE: alloc_wg: ISSUE 11863 Date: Fri, 15 Feb 2008 16:14:17 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: alloc_wg: ISSUE 11863 Thread-Index: Achv7KF+rZ5+v/FjQBqrK/lHGk7isgAAS8NM From: "VanZandt, Lonnie" To: "Frederic Mallet" , , S.©bastien Demathieu I'm pleased that you like the wiki page idea. Do know that in the Draft template, I put a field for "Recommended Resolution". That is where one would indicate the foreseen resolution for the issue: Resolved, NoChange, Transferred, etc. I'm pragmatic though: use what works for you. Lonnie VanZandt Field Applications Engineer Denver, CO Artisan Software Tools mobile: 720 201-1349 desk: 303 482-2943 lonnie.vanzandt@artisansw.com -------------------------------------------------------------------------------- From: Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Sent: Fri 2/15/2008 9:05 AM To: marte-ftf@omg.org; Sébastien Demathieu; VanZandt, Lonnie Subject: alloc_wg: ISSUE 11863 Hi everyone that feels concerned about the allocation, I have uploaded a resolution draft for Issue 11863 in which ClockRefine is replaced by NfpRefine and NfpConstraints is used instead of ClockConstraints. Even though it is a draft I did not use the so called "draft recommandation document" because being a draft is an orthogonal status and it is useful to know what kind of resolution we are aiming at (resolved, closedNoChange,...). So I mentioned the status draft both in the name 11863_resolved_draft.doc and as a note. Using a wiki page really is a good solution, I will do it if ever some issues induce any strong interaction. Do not forget to send your comments/modifications before the beginning of the voting period (March, 17th). Regards, Frédéric.