OCL needs an abstract syntax, just like the UML metamodel. This
will clarify many issues about the exact semantics of OCL.
This request has been made by multiple sources.

No Data Available

In the String explanation,
There is a descrition that
"The OCL type String represents ASCII strings."
I think this cannot apply to multi-byte code.

Could you change this sentence to
"The OCL type String represents strings consisting
of ASCII characters and/or multi-byte characters.

No Data Available

1. 6.2.1 "legend" on page 6-3,
There is a following description.
"OCL expression are written using ASCII characters only"
This sentence can be interpreted in this context as
a) OCL expressions are written using only
ASCII characters as examples in this document,
b) the OCL expression must be written by only
ASCII characters in general usage?

Could you change this to
"OCL expressions in this document are
written using ASCII character only."

No Data Available

4.Regarding inhibtedChar on page6-48,
its definition is following.

inhibitedChar :=
"|"\"|"#"|"\'"|"("|")"|"*"|"+"|","|
"|"."|"/"|":"|";"|"<"|"="|">"|"@"|
["|"\\"|"]"|"

"

But, this definition is slightly different from one which we
have provided previously.
(Top two characters of each line are dropped)

inhibitedChar := " " | "\"" | "#" | "\'" | "(" | ")" |
"*" | "+" | "," | "-" | "." | "/" |
":" | ";" | "<" | "=" | ">" | "@" |
"[" | "\\" | "]" | "

"

No Data Available

Relating this, in the EBNF of the String on page6-48.
There is a "~" symbol after double brackets.
Does this means negation?
If it is negation, there is no modification of String
definition on the EBNF even though the body of string
explanation is changed.
But, I cannot find a "~" definition in the EBNF.
In the unaryOperater definition of the EBNF on page6-48
There is a "-".
I think this is a "~" symbol.

No Data Available

It is sometimes useful to downcast an OCL collection, for example
when a generic function returns an OCL Collection, but a particular
usage requires a Sequence. Unfortunately, the OCL operators
asSet(), asSequence() and asBag(), are defined only for the
concrete types, and not for their abstract common supertype
Collection.

No Data Available

> In 6.9 "Grammar for OCL",
> According to the current BNF grammar, we cannot use
> multi-byte characters in class nor attribute names, because
> name and string are composed of alpha-numeric letters only.
> I think the definition of OCL should be modified for us
> to be able to use multi-byte characters.
> I show a draft of modification which will be proposed by
> ISO/Japan National Body.(This will be discussed in UML1.3 PAS
> at the next OMG/ISO Orlando meeting)
>
> typeName :=charForNameTop charForName*
> name :=charForNameTop charForName*
> charForNameTop := /* Characters except inhibitedChar
> and ["0"-"9"]; the available
> characters shall be determined by
> the tool implementers ultimately.*/
> charForName := /* Characters except inhibitedChar; the
> available characters shall be determined
> by the tool implementers ultimately.*/
> inhibitedChar := " "|"\"|"#"|"\'"|"("|")"|"*"|"+"|","|"-"|
> "."|"/"|":"|";"|"<"|"="|">"|"@"|"["|"
"|
> "]"|"

"

No Data Available

Usually, the behaviour of an operation is described by pre and
postconditions, and then shown in a collaboration diagram. In turn, in a
collaboration diagram one can model (via the standard stereotypes create and
destroy) the creation and destroying of instances, but this is not in the
case in OCL. It would be useful to be able to explicitly model in a
postcondition that an instance ocurring in the expression was created during
the execution of the operation being specified. Since introducing a command
is not possible, this feature could be achieved by just 'declaring' in the
postcondition that the instance 'was created'.

For example:

context X::operation()
post: self.attr = self.attr@pre->including(created p)

this declares that p was created during the execution of operation, and it
was not taken from elsewhere.

No Data Available

The second form of the context declaration for OCL invariants should be extended from

context c : Class inv:

to

context c1,..,cn : Class inv:

In similar situations, like the forAll and Exists operators, multiple iterators are allowed. So the above suggestion would increase uniformity. It also leads in some cases to simplified OCL expressions, e.g.

context C inv C.allInstances->forAll(c1,c2 | c1.id = c2.id implies c1=c2)

could be written as

context c1,c2 : C inv c1.id = c2.id implies c1=c2

Crossreference to issue #3139.

No Data Available

The postcondition for the operation round on the predefined OCL type real reads

((r - result) < r).abs < 0.5) or ((r - result).abs = 0.5 and (result > r))

This is incorrect and should be replaced by

((r - result).abs < 0.5) or ((r - result).abs = 0.5 and (result > r))

No Data Available

Section 6.6.2

In the paragraph after the OCL sample should the word "reject" be "collect" instead?

No Data Available

Document ad/2003-05-01 contains directions along which the OCL
metamodel and the UML Infrastructure metamodel can be integrated to form one
single language. The OCL has originally been conceived as part of the UML
language, and has never been intended to be used separately. A tight
connection between the two metamodels is nessesary for all modelers that
want to use either UML, OCL, MOF, or a combination of these. Within the OMG
the OCL is heavily used for specifyingconstraints on metamodels in the
varous OMG standards. OCL is also used extensively in many of the proposals
for the MOF 2.0 QVT RfP, as the solution for a query language, and as part
of a transformation definition language. In all these cases, the OCL is used
at the metamodel level, i.e. at the MOF level. Formally this is incorrect,
because OCL isn't part of the MOF. Within the UML/MOF/OCL 2.0 framework, the
UML and the MOF share a common core. The MOF 2.0 proposal reuses the UML 2.0
Infrastucture. By integrating the OCL into the reused part of the UML 2.0
infrastructure, the OCL metamodel is integrated with the MOF 2.0 as well.
The definition of OCL at the MOF level is then achieved. Some aspects of the
coupling of the OCL metamodel with the UML Superstructure metamodel are
addressed in document ad/2003-05-01 as well.

No Data Available

the routines on String are too sparse to support real world usage.
In particular, most users would require:

• uppercase and lowercase routines
• the ability to ask if String1 is found in String2
• case insensitive compare would be useful but can
  be built using the uppercase or lowercase routines

No Data Available

Is it possible for collections to contain void (= undefined objects)?

Conceptually, this would appear to be required so that you
can specify whether an item in a collection can be null in
an actual implementation. The use of void and undefined() is
advised in exactly the same situation in a non-collection
context.

However, this quote from Section 2.4.11: "In general, an expression
where one of the parts is undefined will itself be undefined", along
with the rest of the section, shows that you can't use void as
a parameter to the collection calls, and in the context of OCL as a
language, this makes sense.

So I thank that this constraint:

context Collection
inv: self->forAll(not OclIsUndefined())

is required, and this should be stated to clear up uncertainties.

This leaves the problem of how to say whether an "item in a collection
can be null in an actual implementation" is inresolvable in OCL 2.

No Data Available

quotes from ad/2003-01-07 (v1.6 of OCL 2 proposal):

Section 1.5.1 says, "the flatten operation is a deep flatten, it
completely flattens a nested collection of any depth". However the
formal definition is :

post: result = if self.type.elementType.oclIsKindOf(CollectionType) then
self->iterate(c; acc : Set() = Set{} |
acc->union(c->asSet() ) )
else
self
endif

From Section 6.5.1 (definition of Set.Flatten). The formal declaration does
not show that the flatten operation is deep. This discussion is extended in
Appendix A, which presents an analogous postcondition, but explains that this
is for a single level only.

It would seem that the post-condition(s) in section 6.5.1 are wrong?

No Data Available

Section 6.6.7

In the second bullet point:

• shouldn't the italics refer to "employee" throughout? (In one case it says "employer"). - "unambiguous" should be "ambiguous".

No Data Available