Issue 12861: concrete syntax (marte-ftf) Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr) Nature: Enhancement Severity: Significant Summary: Section 9 proposes some stereotypes to identify clocks and clock constraints. Annex C proposes a non-normative language (CCSL) to describe clock constraints. Even though CCSL is non normative (to give more freedom to tool vendors for implementation), such a constraint language must have some specific characteristics. For instance, it MUST allows description of both synchronous and asynchronous constraints. Hence, the normative part (Section 9) should provide a mechanism to identify the nature (synchronous, asynchronous, mixted) of the constraint even if the concrete syntax remains non-normative and described in Annex C. This would give some kind of consistency between different implementations. Resolution: The resolution proposes to add three meta-attributes to the stereotype ClockConstraint to reflect the domain view (CoincidenceRelation and PrecedenceRelation described in Figure 9.5) and identify the nature of the constraint. Revised Text: see ptc/2009-05-12 pages 277 - 278 Actions taken: September 25, 2008: received issue October 16, 2009: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 25 Sep 2008 07:56:57 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Frédéric Mallet Company: INRIA mailFrom: fmallet@sophia.inria.fr Notification: No Specification: MARTE Section: 9 FormalNumber: 08-06-08 Version: beta 2 RevisionDate: June 2008 Page: 70-81 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Description Section 9 proposes some stereotypes to identify clocks and clock constraints. Annex C proposes a non-normative language (CCSL) to describe clock constraints. Even though CCSL is non normative (to give more freedom to tool vendors for implementation), such a constraint language must have some specific characteristics. For instance, it MUST allows description of both synchronous and asynchronous constraints. Hence, the normative part (Section 9) should provide a mechanism to identify the nature (synchronous, asynchronous, mixted) of the constraint even if the concrete syntax remains non-normative and described in Annex C. This would give some kind of consistency between different implementations.