ETSI's Bug Tracker - Part-1 Metamodel
Introduction to software language design
Basic principles of meta-modelling
A software language consists of two independent parts: syntax and semantics. The syntax describes the structure of a text provided in this language (or of graphical symbols for a graphical language), while the semantics describes the meaning of individual syntax elements used in the text.
With upcoming multi-representation syntaxes for a single language, the distinction between abstract syntax and concrete syntax becomes necessary. The abstract syntax defines the structure of the text without referencing keywords that are provided in a concrete syntax only.
A text given in one concrete syntax can be transformed into a text of another concrete syntax if the text is syntactical correct w.r.t. concrete syntax and abstract syntax and both concrete syntaxes refer to the same abstract syntax. This transformation is completely independent from the semantics definition (which does not change).
Semantics is divided into static semantics and dynamic semantics. The static semantics defines further restrictions on the structure of the text that cannot be defined alone in syntax rules. The dynamic semantics provide the meaning of a syntax element when it is put into an execution environment.
Mapping to document structure
The four pieces of a software language, concrete syntax, abstract syntax, static semantics, dynamic semantics, are mapped to the standards series of TDL as follows:
• Concrete syntax: defined in parts 2 on TDL-GR (graphical format) and 3 on TDL-XF (exchange format)
• Abstract syntax: defined in part 1 on TDL-MM in the contained diagrams representing the technical meta-model, which correspond to the individual sub-clauses "Generalization" and "Properties".
• Static semantics: defined in part 1 on TDL-MM in the sub-clauses "Constraints" and partly, if constraints are hard to formulate, in the sub-clauses "Semantics".
• Dynamic semantics: defined in part 1 on TDL-MM in the sub-clauses "Semantics". To highlight the dynamic semantics, sometimes the expression "at runtime" is used.
In addition part 4 on TDL-TO (test objective specification) defines an extension of the abstract syntax and semantics of part 1 together with a concrete textual syntax for this extension.
While the syntax and static semantics are (will be) formally defined, the dynamic semantics is defined only informally using a declarative style. It is augmented frequently with further explanations beyond pure semantics definition to ease reading of the document. These explanations are provided as NOTEs.
ETSI requires the use of 'shall' and 'shall not' (among others) to "indicate requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted." (see "ETSI Drafting Rules", clause 14a)
It was observed during the last meeting that the semantics section of a clause in the MM draft does not use 'shall' to formulate requirements in the semantics sections.
I provide the following explanation for this case: The semantics is given in a declarative style. This is true in particular for the data part but also to a large extend for the behaviour part. It is therefore completely useless and actually wrong usage to enrich declarative statements with 'shall'. A declaration is not a requirement, but a statement of fact. In this case, the EDR requires that 'is / is not' "shall be used to indicate statements of fact". This rule is followed in the MM draft.
Example: clause 6.3.1 DataUse
"A 'DataUse' denotes an expression that evaluates to a 'DataInstance' of a given 'DataType'."
It would be a wrong style of writing "A 'DataUse' shall denote…" This would overburden the sentence. The use of 'shall' is commonly associated with verbs of action, e.g. "a user shall do this", "a protocol entity shall behave like this".
Therefore, the MM draft makes use of 'shall' when a user could have a choice which needs to be restricted. Such cases typically occur within the constraints sections because here the options on the syntax a user has are clearly restricted.
Counterexamples might exist in the MM draft, but do not invalidate the above reasoning.
InputTDLMantisIssue_6877.docx (161,030) 12-06-2015 16:30http://oldforge.etsi.org/mantis/file_download.php?file_id=3211&type=bug