In the latest UML specification for 2.5.1, the implementation in the OCL language of the overridden StringExpression::stringValue() is given at section 8.6.17.5 “Operations” on page 130:

body: if subExpression->notEmpty() then subExpression->iterate(se;
stringValue: String = ” | stringValue.concat(se.stringValue())) else
operand->iterate(op; stringValue: String = ” |
stringValue.concat(op.stringValue())) endif

The intent of this is perfectly clear; however, for example in specifying an ordered list of function parameters, there is always some kind of separator token (usually the comma) to delimit the individual arguments passed to a function. AFAICT the OCL ‘concat’ operation does not supply any separator token.

Since theoretically a StringExpression’s subexpressions might return their own concatenated subexpressions, ending up with some kind of nesting of operands, it seems that no separator at all would quickly lead to confusion and errors.

It doesn’t seem to be specified anywhere as to whether the concatenated operands or subexpressions need to be separated by commas or perhaps some other token? There might be languages in use where something other than the comma is used (perhaps a space?), so it is conceivable that the behavior could be overridden by a Profile in some form or fashion.

Is this a defect in the specification?