Issues for MOF Model to Text Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 11093: Issue: Typos in examples
Issue 11964: Section: 8.2
Issue 12174: Specification error in concrete syntax
Issue 12176: Ambiguity detected in Invocation rule Message
Issue 12184: Section: 7.2, 7.3, A3 OCLExpression
Issue 12186: Inconsistency in metamodel Message

Issue 11093: Issue: Typos in examples (mtt-ftf)

Issue: Typos in examples: 
In Annex A, A.1 Example 1: 
In the example fragment 
[template public SchemaToDDL (s: Schema)] 
[for (t:Table | s.table)] 
TableToDDL(t) 
[/for] 
[/template]

Grammar errors in section '8.2 concrete syxtax: syntax: ::= 'elseif' '(' <OclExpressionCS> ')' <production_code> ('/elseif') ? It should be: ::= 'elseif' '(' <OclExpressionCS> ')' <production_code> '/elseif' syntax: ::= '[else]' <production> ('[/else]')? It should be: ::= '[else]' <production> '[/else]'

I've detected an error in the module rule of the concrete syntax section (8.2). This rule has an inconsistency with respect to the metamodel specified in section 8.1. The syntax is: <module_decl> ::= '[module' <PathNameCS> ‘(‘ <PathNameCS> ‘)’ [extends_decl] '/]' | 'module' <PathNameCS> [extends_decl] ---------- -------------- | Module | 0..* ---------> 1..* | TypedModel | ---------- -------------- So a Module can contain one or more TypedModels, but the grammar does not seem to provide ways to attach more than one. Solution: The module rule could be changed as follows: <module_decl> := '[module' <PathNameCS> ‘(‘ <PathNameCS> ( ‘,’ <PathNameCS>)* ‘)’ [extends_decl] '/]' | 'module' <PathNameCS> ‘(‘ <PathNameCS> ( ‘,’ <PathNameCS>)* ‘)’ [extends_decl]

The Mof2Text concrete syntax contain the following rules (see p. 22): <OclExpressionCS> ::= ( <PropertyCallExpCS> | <VariableExpCS> | <LiteralExpCS> | <LetExpCS> | <OclMessageExpCS> | <ifExp> | <invocation> ) <invocation> ::= ( <PathNameCS> '(' <actualarglist> ')' | 'super' ) [ <before> ] [ <separator> ] [ <after> ] <actualarglist> ::= ( <OclExpressionCS> ( ',' <OclExpressionCS> )* )? <before> ::= 'before' '(' <OclExpressionCS> ')' <separator> ::= 'separator' '(' <OclExpressionCS> ')' <after> ::= 'after' '(' <OclExpressionCS> ')' The OCL concrete syntax contain the following rules (see OCL Specificacion. Pages 64, 72, 80 and 81) OclExpressionCS ::= PropertyCallExpCS | VariableExpCS | LiteralExpCS | LetExpCS | OclMessageExpCS | IfExpCS PropertyCallExpCS ::= ModelPropertyCallExpCS | LoopExpCS ModelPropertyCallExpCS ::= OperationCallExpCS | AttributeCallExpCS | NavigationCallExpCS OperationCallExpCS ::= OclExpressionCS[1] simpleNameCS OclExpressionCS[2] | OclExpressionCS '->' simpleNameCS '(' argumentsCS? ')' | OclExpressionCS '.' simpleNameCS '(' argumentsCS? ')' | simpleNameCS '(' argumentsCS? ')' | OclExpressionCS '.' simpleNameCS isMarkedPreCS '(' argumentsCS? ')' | simpleNameCS isMarkedPreCS '(' argumentsCS? ')' | pathNameCS '(' argumentsCS? ')' | simpleNameCS OclExpressionCS argumentsCS[1] ::= OclExpressionCS ( ‘,’ argumentsCS[2] )? The conflict appears when the before, separator and after rules are all empty at the same time in the <invocation> MOF2Text rule. In that case the resolution proceeds as follows: OclExpressionCS ::= invocation ::= PathNameCS '(' actualarglist ')' OclExpressionCS ::= PropertyCallExpCS ::= ModelPropertyCallExpCS ::= OperationCallCS ::= pathNameCS '(' argumentsCS? ')' Solution: The best solution I have found to avoid this conflict involves the introduction of a new keyword, 'invoke'. The invocation rule could be updated as follows: <invocation> ::= invoke ( <PathNameCS> '(' <actualarglist> ')' | 'super' ) [ <before> ] [ <separator> ] [ <after> ] This way we can distinguish easily between the two cases. TemplateInvocation, MacroInvocation and QueryInvocation would then always resolve unambiguously into this last rule.

Title: OCLExpression doesn't support the plus operator for string concatenations Message: The OCL specification defines (see 7.4: Basic Values and Types, page 10) the number of operations on the predefined types. The string type supports the concat, substring and size operations, but the plus operator is only used in integer types. The Mof2Text specification uses the plus operator to concatenate strings, and it's an error. Here there are some examples: 1. 7.2 Traceability --> [trace (c.id + '_definition') ] 2. 7.3 Directing Output to Files --> [file ('file:\\' + c.name + '.java', false, c.id + 'impl')] 3. A.3 Example 3 --> [file (c.name + '.cpp', false)] [trace (c.id + '.header')]

Title: Inconsistency in metamodel Message: The Mof2Text metamodel cannot attach static text to a body section. --------- ---------------------- | Block | 1 ---------> 0..* | TemplateExpression | --------- body ---------------------- --------- ---------------------- ----------------- | Block | -------|> | TemplateExpression | --------|> | OclExpression | --------- ---------------------- ----------------- The problem can be reproduced with the following example (extracted from Example 1. Page 25): [template public TableToDDL(t: Table)] CREATE TABLE [t.name/] ( [for (c:Column|t.column) separator(',')] [c.name/] [c.type/] [/for] ); [KeyToDDL(t.key)/] [ForeignKeyToDDL(t.foreignKey)/] [/template] The template body contains a ForBlock, a TemplateExpression ([t.name/]) and two TemplateInvocation (KeyToDDL and ForeignKeyToDDL). It seems that there are no ways to attach the static text portions "CREATE TABLE", "(" and ");" to the model. The OCL specification contains a StringLiteralExp class that could be used to attach this kind of static literal text. But for that to work, StringLiteralExp instances should be attachable somewhere, for instance, in the Block's body. In that case, perhaps that 'body' property could change its type from TemplateExpression to the more general OCLExpression, in order to allow StringLiteralExp's to be directly added to 'body', although this could be too much a general solution and would possibly require further testing. Solution: The metamodel could be change as follows: --------- ----------------- | Block | 1 ---------> 0..* | OclExpression | --------- body -----------------