Comments on ODP Enterprise language PDAM (ISO/IEC 15414 PDAM 1| ITU-T
X.911 Amd. 1)


Source: Finland
Document under ballot: ISO/IEC JTC1/SC7/WG17 W17N0168


1. Root community

Root community is used only once in the whole document. 
It is used to pick out a single community from the
set of community specifications appearing in an enterprise specification.
It is natural to require that one of the community specifications
has the property of expressing how others relate to each other.
However, it is not quite necessary to include root community
as a special concept here, although we have no objection of doing so.

In the notes, it might be said that the purpose of root community
is to show the relationship of other communities in the specification.

2. Policies and policy frameworks

Suggested subclauses 7.9.4 Organisation of policy and 7.9.5 policy
framework include important information that should become
part of the standard: the usage of policies and the ways
in which policy can affect a system. 

However, the terminology used in the suggested amendment text
is not quite consistent, especially when dealing with policy framework.

The intention of earlier ballot comments was to introduce 
policy framework as a bridge between real world requirements
and the actual use of enterprise language concepts on policy.

We believe that a role specification defines a set of expected
interactions (all in which the fulfilling objects should be capable of
participating); internal actions are abstracted away (such detail will
appear in object specifications). However, this internal behaviour might
be governed by certain policies (parametrised) so that object behaviour
can be guided by actual policy values. Likewise, the interaction
patterns between objects in roles can be restricted by policies (the
policy enforcer selects actual behaviour by choosing appropriate policy
values).

Now, each object (or other entity) can be developed independent
from others, in different organisations, for different needs.
For interoperation between the objects, it is necessary to have
some enterprise-specification wide or community-specification wide
agreement on what the appropriate policies should be.
This agreement we call policy framework.

A policy framework is like an ontology developed by an organisation
like OMG for their business domains, or like an ontology evolved
for a technical area because of market forces.


With this rationale, we suggest that texts of 7.9.4 and 7.9.5
are merged under the title Organisation of policy.
(In this process the first paragraph of 7.9.5 will 
probably disappear or  becomes rewritten.)

Further, in this text, references to policy frameworks should be
replaced by references to sets of policies.

For 7.9.6 we suggest removing the word framework from the title.


3. Purposeful selection

We suggest that purposeful selection is introduced as
a special case of policy guided behaviour.
Policy values might be private to the object obeying a policy and  
agent/principal declaring that policy.

4. Annex A

We find that there are several separate aspects of the
enterprise language standard that cannot be included into a
single graph. The metamodel shows
a)  what the structure of an enterprise specification is
   (static view);
b) how communities and objects relate to the specification
   (dynamic view, although in some tool environments and for
   some system development methodologies the relationship
   happens to be static);
c) how policies govern the community behaviour (dynamic view); and
d) linguistical patterns appropriate to be used when specifying
   communication within an enterprise specification (declaration,
   commitment, principal, etc).

In the annex of this ballot comment, we suggest a series of
graphs for explaining a, b, and c above. 

The first illustration captures the structuring rules of enterprise
specifications. Although a UML tool was used for drawing, there is no
use for attribute and operation slots for classes; nor carries the
aggregation symbol more information than simple inclusion relationship.
The structuring rules illustration discusses categories of
textual/graphical specifications and shows how an enterprise
specification may contain multiple community specifications and
enterprise object specifications. Some interpretations have been made:
policies appear at two levels as we consider role specific policies as
means for discussing concepts like guiding purposeful selection. More
importantly, policies govern behaviour between roles. At the edges of
the illustration, the enterprise language standard does not give
normative rules: how enterprise objects are specified and how roles and
objects are mapped together are necessarily outside the scope of this
standard.

The second illustration discusses entities of ODP systems. 
So far, the contract concept have been popping in and out.
Here, the contract is a natural combination of contract structure 
(determined by community specification structure that can be shared) and 
values specific for a certain community instance.

Still missing is the relationship between roles and objects
and the mechanisms by which policies are enforced on objects.

The third illustration shows solely, that the assignment process
is to be defined by 
- concrete specification language,
- concrete specification environment/tool, and 
- concrete environment in which the system runs.
The assignment process ensures the completeness and
consistency of the specifications created.

The fourth illustration discusses entities as well. It shows
how actions performed by objects are controlled by policy values. 
Each policy value can be a combination of policies in effect
in various communities in which the corresponding role belongs to 
(hierarchy). If communities only partially overlap, it may be the case,
that an acceptable action in one community causes violations
in others, unless policies have been properly tested for
consistency beforehand.

The fifth illustration combines categories and entities by 
displaying both contract structuring rules and contract
contents simultaneously. A (community) contract can
use multiple policy frameworks. For instance, it can combine
policies commonly used for guiding payments and policies
used for discussing sanctions after failed delivery.
The essential content of a contract is, however, the
policy values selected. 

We omit illustrations for declarations, commitments etc as trivial
sequence graphs.

It should be noted that various concepts (role, object, contract,
policy) appear in multiple illustrations on purpose to show both their
static and dynamic nature.


5. Annex B

There are also other ways of using the enterprise language
standard terminology. Still, this annex is useful for understanding
the document. 

We suggest the following minor changes
- continue the first sentence to say that the example
is for system specification or requirement analysis or such.
- in B.5, 3rd sentence: When a particular object participates ...
  is not quite correct (includes the other participants of an interactions
  as well! should allow usage of multiple interfaces too)
- B.6 Process needs extending, besides the ones that are still empty
  or labeled as incomplete
- machines etc new concepts seem to appear in the annex and should be
  removed