The sample input model diagram on page 26 (Annex A, Example 1 – RDBMS model to Oracle DDL) is inaccurate. The 'refersTo' relation from the Department_fky entity should point to the Department_pky entity and not to the Employee_pky entity. Also, the 'foreignKey' relation from the Employee entity should point towards the Department_fky entity and not as shown.

issue withdrawn by submitter, closed

Examples have incorrectly escaped template invocations
E.g.
[attributeToJava(c.attribute)]
[operationToJava(allOperations(c))]
// Constructor
[c.name/]()
{
}
}
[/template]

template invocations are not escaped properly.
They should be [TableToDDL(t)/],[attributeToJava(c.attribute)/] and
[operationToJava(allOperations(c))/] respectively.

Replace with the text below,
[attributeToJava(c.attribute)/]
[operationToJava(allOperations(c))/]
// Constructor
[c.name/]()
{
}
}
[/template]

Whitespace handling rules are not clear:
1. Is whitespace preceding multi-line block expressions (such as for, if, etc) included in the text output? Examples
given in the appendix do not seem to include it.
2. Whitespace handling rule 3 says: "Indentation of the text produced for the invoked template starts at the indentation at the point of the template invocation." Should this be the case even for an embedded template invocation, i.e. a template
invocation that is surrounded by other expressions on the same line?
E.g.
[template printClass(c:Class)]
class [c.name/] implements [printInterfaceName(c.implementsInterface) sep(',')]
[/template]
[template printInterfaceName(i:Interface)]
[i.name/]
[/template]
Here printInterface is invoked iteratively for each interface implemented by the class.
One would expect following kind of output from this:
class myClass implements myIntf1, myIntf2, myIntf3,...

But the rule seems to say that the output of each template invocation starts at the same indentation level.
This is probably not the intended behaviour, atleast for embedded template invocations (like the one above).

Replace existing text in the section discussing whitespace handling with the text given
below,
Text production rules will be easier to specify by viewing the body of a template (or a
block expression) as follows:
<block-body> ::= <body-element>*
<body-element> ::= <literalString> | <whitespace> | <expression> | <BOL-indicator>
<whitespace> ::= space | tab | newline
<expression> ::= <stand-alone-block-expression> | <embedded-block-expression> |
<stand-alone-template-invocation> | <embedded-template-invocation> |
<other-expression>
<BOL-indicator> ::= ‘^’
<stand-alone-block-expression> is a block expression (single or multi-line) that is not
surrounded by other body elements on the lines where the block head and the tail occur.
<embedded-block-expression> is a block expression that is surrounded by other nonwhitespace
body elements on the lines where block head or tail occur.
<stand-alone-template-invocation> is a template invocation expression that stands on a
line all by itself.
<embedded-template-invocation> is a template invocation that is surrounded by other
body elements on the same line.
<other-expression> refers to all expressions other than the block and template invocation
expressions.
Text production rules:

• All body elements produce text
• The text output of a block-body is the sequential concatenation of the text outputs of
  its body elements
• Rules for identifying starting and ending of block body:
  o template: body starts at the beginning of the next line after the template head,
  and ends on the last character (excluding the new line) of the line previous to
  the template tail.
  o multi-line-block: body starts at the beginning of the next line after the block
  head, and ends on the last character (excluding the new line) of the line
  previous to the block tail.
  o single-line-block: body starts after the closing bracket of the block head and
  ends before the starting bracket of the block tail.
• Text outputs of different body elements:
  o A literal string is output as is.
  o A whitespace character is output as is. The text produced by the execution of <other-expression> is output as is.
  o The text produced by the execution of <embedded-block-expression> is
  output as is.
  o The text produced by the execution of <embedded-template-invocation> is
  output as is.
  o <stand-alone-block-expression> needs special handling:
  .. Ignore the whitespace characters occurring before the beginning of the
  head.
  .. In the case of a multi-line 'for block', when a separator character is not
  specified, use 'new line' as the default separator between the outputs
  produced by successive iterations.
  o <stand-alone-template-invocation> needs special handling:
  .. Add the whitespace preceding the invocation expression before each
  line of the text produced by the invoked template.
  .. In the case of an iterative template invocation (e.g. when the argument
  is a collection), if a separator character is not specified, use 'new line'
  as the default separator between the outputs produced by successive
  iterations.
  <BOL-indicator> is a special character (‘^’) that marks the beginning of a line – i.e. on
  the line on which this character appears, the whitespace preceding the character should be
  excluded from the text output.
  In code-explicit mode, all whitespace must be explicitly specified.
  Move this section after the section describing concrete syntax.

Grammar error in section '8.2 concrete syntax':
<elseif> ::= '[elseif]' '(' <OclExpressionCS> ')' <production> ('[/elseif]')?

It should be:
<elseif> ::= '[elseif' '(' <OclExpressionCS> ')' ']' <production> '[/elseif]'

Replace the following text in section '8.2 concrete syntax':
<elseif> ::= '[elseif]' '(' <OclExpressionCS> ')' <production>
('[/elseif]')?
With the text below,
<elseif> ::= '[elseif' '(' <OclExpressionCS> ')' ']' <production>
('[/elseif]')?