Comments on ODP Enterprise Language (ISO/IEC 15414 | ITU-T X.911)

Source: Finland

Document under ballot: ISO/IEC JTC1/SC7 2CD15414 Open Distributed Processing _ Enterprise Viewpoint, N2252

Vote: Disapproval of the draft with the comments below. Acceptance of these comments and appropriate changes in the text will change our vote to approval.

All comments below are technical, unless otherwise stated.

  1. General technical concerns:

    a)In current form, the enterprise language concepts do not adequately support language developer and system interoperability support needs. Both the scope of terminology and the advisory text for the use of the terminology are lacking.

    b)The last meeting did not finish comments on behaviour modelling.

    c)The last meeting did not quite finish discussion on the difference of role and role type, the need of role cardinalities etc.

    d) The lack of policy framework and the lack of adequate statements on the structuring of constrants, population/assignment rules, and behavaviour requirements is a severe drawback for the usability of this standard. We regret of being unable to contribute to those areas this time, but are willing to continue work on those areas.

  2. General, specifically on clause 7 and Annex A

    The population process of the communities is not clearly enough presented. Especially clause 7 totally misses the concept of population policy for object to fulfil roles. Role itself defines the behavioural aspects of the selection criteria, but non-behavioural aspects (such as policy parameters) should be present too.

  3. Clause 1, lines 17-18, temporary note
    clause 5, page5, lines 12-19
    clause 5, page 6, lines 18-19
    clause 5, page 5, lines 34-35 editor's note

    The audience of this document is threefold: language developers, specifiers (i.e. language users), and specification users (users of tools based on the language, laymen).

    The language should support system analysis, system design, and system interoperability services at the time of system exploitation.

    Yes, one of the usages for enterprise language is to give basis for formal specification. From this, different presentation forms can be derived, or a mapping to existing presentation forms like UML can be given.

    Suggested text for the clause:

  4. clause 5, lines 22-26

    Suggested phrase: this prescription of ODP enterprise language.

  5. clause 6, lines 27-34, editors note

    Replace by a normal text sentence: "The group of concepts below is not restrictive."

  6. clause 6, end

    Add: "These concepts can be used as abstraction tools for specifications to express the focus of interest and requirements for entities under discussion."
    NOTe: For example, the same entity can be modelled as an actor, as an artefact or as a resource, depending on the intent and scope of specification.

  7. Clause 6.1.5

    Replace "< s > community" by "Implicit community".
    Replace "system is represented" by "system can be represented".
    Add: Whether the specification actually includes that level of abstraction is left for the specifier and specification tools to decide.

  8. Clause 6.1.6

    Community representative object: A composite object, the component objects of which are the members of a community and which object is used to model participation of that community as a whole in the behaviour of another community.

  9. clause 6.2.1., note 3

    A process specification ...

  10. delete clause 6.2.3

  11. clause 6.2.4

    Replace "participates" by "initiates" or at least "performs".
    To our understanding, "initiates" have been accepted at least in two earlier meetings, and keeps dropping out in spite of the technical difference.

  12. clauses 6.2.5-6.2.9

    The style of specification we have used uses actor roles with respect of the community and itemises artefact roles with respect to each individual action.

    We suggest that only the terms actor and artefact were defined, and additional sentences are used to explain that there is a need to indicate whether the use is with respect to an action or with respect to a community. Each specification should be consistent in the chosen style, but the choice rests with text organisation decisions within individual tools that help in composing enterprise specifications.

  13. delete clause 6.2.9

  14. clause 6.3.3.

    It may be helpful to have this concept. Violation may cause failure, but the contract may also include violation recovery behaviour for the community, in which case a failure (= a state requiring undefined behaviour) is not reached. In addition to defining violation, we should consider concepts of penalties or sanctions.

  15. clause 6.4

    This clause seems to miss concepts of delegation withdrawal.

  16. clauses 6.4.1, 6.5.4

    Only one of these is needed; delete 6.5.4.

  17. Regrouping within 6

    Add title "Role concepts" and collect 6.4.2-6.2.11, 6.4.2 and 6.4.3 under it. Move 6.2.1. to 6.1.

  18. clause 6.4.2.

    The pair of names agent and principal are good enough and should not cause any confusion.

  19. clause 6.5.1

    Replace by "An action involving one or more parties or agents."

  20. clause 6.5.2, editorial, prescriptive part + note

    Replace "is bound" by "becomes bound".

  21. clause 7.1, lines 16, 30 Replace " < c > community" by "implicit community".

  22. clause 7.1. between lines 40 and 41

    Add new para:
    "A complete ODP system specification is required to indicate rules for internal consistency in terms of relationships between various viewpoint specifications. Furthermore, a complete enterprise specification contains conformance rules that define the required behaviour of the described ODP system, thus separating out the parts of the specification included for the purposes of analyse, understandability and communicatability of the specification."

  23. clause 7.3.1.

    Rationale:

    The document is not clear in describing the possible relationships between communities, nor in describing the possible relationships between roles.

    The relationships needing identification must include

    Suggestions:
    "An enterprise specification can describe several communities. These communities may form an interaction relationship in various ways:

    "

  24. clause 7.4, lines 21-24

    Add: "Communities of these types can be specified so that they overlap totally or partially. These basic community types do not imply any hierarchical relationships. A specification may choose to use some or none of these community types.

    NOTE: For example, Internet forms a technical domain that is controlled by the standardization organisation responsible for Internet protocols, while the owners of communication connections and computers in Internet each have an ownership community comprising of a set of equipment."

  25. clause 7.4.1

    The definition is correct but laborous to read. (Note layout should be corrected.)

    Continue: ... for designers.

  26. clause 7.4.2.

    Add to the end: "< x > controllers may declare their policies amongst themselves and commit their controlled community to some contract but cannot prescribe policies on each other's controlled communities. "

  27. clause 7.4.3

    The owner may either prescribe policies of the community or delegate an authorisation to do so to an agent. This authorisation may also be withdrawn.

  28. clause 7.5.1, line 3

    Replace "assigning by an enterprise objects" by "assigning by enterprise objects".

  29. clause 7.5.2, editor's note:

    We would prefer to see that paragraph in clause 7.5.1.

  30. clause 7.5.2, line 22

    Replace "such changes" by "creation or deletion of roles".

  31. clause 7.5.1, editor's note.

    Keep type, may add a note saying template is a special case.

  32. clause 7.5.3, editor's note

    Terminating behaviour in P2 13.2.5 is sufficient.

  33. clause 7.5.3, between lines 40 and 41

    Add: "The community behaviour includes a termination behaviour that is triggered by some state.

    Note: For instance, a violation may be associated with a recovery behaviour, which may be chosen to be the termination of the community."

  34. clause 7.6

    Correct the inconsistent use of singular and plural forms of "objective".

  35. clause 7.6, line 20

    Delete the sentence.

  36. clause 7.6, line 21

    Replace "An enterprise object fulfilling a role has the objective of the role." by "An enterprise object populating a role adopts and adapts to the objective of the role."

  37. clause 7.7.1, temporary note

    The group has several times agreed on using words initiate an action or perform an action instead of participate in an action. This change keeps popping up without clear (or even written) rationale.

  38. clause 7.7.1

    Rewrite:

    The behaviour of a community defines what the community should be observed to do and consists of a number of expected activities. The behaviour defines the possible restrictions on ordering of the activities.

    Notes 1: The behaviour of the community includes interactions of the community, views as a composite object, with its environment. The behaviour may also include interactions internal for the community.

    2: There are many specification styles for the ordering of actions. The modelling language chosen for expressing an enterprise specification may impose certain styles.

    The assignment of actions to the enterprise objects that comprise the community is defined in terms of roles. A role identifies a projection of the community behaviour that comprises a set of activities that is assigned to a single enterprise object within the community. Each projection is lagelleed as a role. The emphasis is on at what kind of enterprise objects participate in the particular activities.

    Role behaviour decomposes the behaviour of the community into roles that can each be performed by an enterprise object in the community. The enterprise object that performs the role behaviour is said to fulfil that role within the community.

    NOTE: In case of an internal interaction within the community, an action is referred to in all roles involved to that piece of collective behaviour.

    A process identifies a projection of the collective behaviour of the community that relates to achieving a particular result/purpose/sub-objective within the community. Each projection is labelled with a process name the emphasis is on what the behaviour achieves.

    Process behaviour decomposes the collective behaviour of the community into processes, parts ow which can be performed by different enterprise objects in the community. The process naturally enforces partial sequencing of actions.

    NOTE: Each process will involve at least part of at least one role behaviour, but can involve parts of may role behaviours.

    The choice of which approach to use will depend on the modelling method used and the aim of modelling; it is possible to use combination of both. As a minimum, the roles of the enterprise objects in the community shall be specified. If the process-based approach is used as well, it shall be in accordance with the rules for the specification of processes given in 7.7.4.

  39. clause 7.7.2, lines 30-33,

    delete

  40. clause 7.7.2, lines 34-36

    Replace:
    When an enterprise object is assigned to a role, the types of the object should not contradict with any of the role types involved, unless the specification includes mechanisms to determine and resolve such inconsistencies, for example, by intercepting and transforming or filtering some of them object features.

  41. clause 7.7.2.1

    delete

  42. clause 7.7.2.2.

    Rewrite:

    An enterprise specification comprises of a community modelling and ODP system and some additional roles for objects in the environment of that community. Objects of a community typically interact with objects outside the community to achieve the objective of the community. When these external interactions are identified by roles there are two modelling choices. On one hand, the peer roles for these interactions can be specified in another community. In this case the environment roles are not necessarily fully specified, but prescribe only the essential behaviour and policies for interaction with the core community. On the other hand, the community can be modelled at a level of abstraction where the ODP system is represented as a single community representative object and all other roles represent objects in its environment. The community representative object can be further refined as a separate community specification.

  43. clause 7.7.3, lines 40-42

    On line 40, replace "responsibilities" by "obligations, prohibitions, permissions and authorisations".
    On line 41, replace "complete descriptions of all actions" by "descriptions of all required actions.
    Remove editor's notes.

  44. clause 7.7.4.1

    Replace steps by actions.

    In note 2, first sentence change "abstraction of the behaviour" to "abstraction of the collective behaviour".

    Add note 3: Action can be an interaction within the community. In some cases, a relevant spontaneous state change may need to be modelled as an interaction in the role behaviour and in the process description involved.
    (Rationale: the state change is a requirement for the object fulfilling that role and thus is not an internal matter only. Therefore, the modeller does not really have the choice of using an internal action here. Allowing internal actions of enterprise objects in the role descriptions would make the specifications infeasible large and restrictive.)

  45. clause 7.7.4.2, line 27 & editor's note

    Replace "the results of actions" by "The sequence of actions".

    There cannot be any relevant interactions within the community or between the community and its environment that are not mentioned in the roles. That does not cover all behaviour of the objects involved with the community; those objects have internal behaviour and additional interactions related to other purposes than to the objective of the community under specification.

  46. clauses 7.7.1 and 7.7.4.2

    No need to have these separately; 7.7.4.2 just repeats things in 7.7.1. Remove 7.7.4.2.

  47. clause 7.8. ( &7.10)

    Clause needs restructuring, currently repetitive and non-focused. Compare to material in 7.10.

    More detailed suggestions to be provided!

  48. clause 7.8., lines 2-16

    Replace by:

    A community specification contains policy rules that express constraints on the behaviour of the objects fulfilling roles. The specification may also contain non-behavioural rules for populating roles with objects.

    The community policies can be either explicitly defined (in the simplest form, enumeration of fixed policies) within the community or induced on the community (or community representing object that fulfils a role in a larger community) when joining a larger context to operate in.

    The enterprise specification must indicate the possible nesting of communities and thus all the policy rules governing the behaviour of the enterprise objects fulfilling roles in a community.

    The enterprise specification must also indicate whether possible dynamic changes in policy rules of the community (for instance, caused by federation negotiations) should be enforced on subcommunities or peer communities.

    Thus, the policies that apply to community members are affected by at least the following events:

  49. clause 7.8.1 (&7.4.3)

    Remove relinquishing, it is not defined. Remove editors note. Compare with clause 7.4.3.

  50. clause 7.8.2, line 22-24

    Remove lines 22-23.

    Replace "prohibitions and obligations" by "prohibitions, obligations and authorisations" on line 24.

  51. clause 7.8.2.1, page 22, line 10-18.

    It would be appropriate to add the suggested style of discussion on other components as well.

  52. clause 7.8.2.2., line 30

    Replace "can take part in" by " may take part in".
    (Editor suggestion is also better than the current wording.)

  53. clause 7.8.3

    The enterprise specification must indicate the possible nesting of communities and thus all the policy rules governing the behaviour of the enterprise objects fulfilling roles in a community. An enterprise object must conform to all policies in all communities it participates.

    The enterprise specification must also indicate whether possible dynamic changes in policy rules of the community (for instance, caused by federation negotiations) should be enforced on subcommunities or peer communities. A community may require that the peer communities cooperating with it follow the same method of adopting dynamic changes to policies as it itself follows.

    Note: In practice, this currently means static policies in each community, but a composite representative object may inherit its policy requirement from several outer communities.

  54. clause 7.8.4

    By default, each community should enforce the policies prescribed within it.

    Relabel "Policy violations".

    Rewrite in a tone where each breach of a policy is a violation and there either is or is not a recovery procedure for such a violation prescribed for the use within the community.

    More importantly, there should be some text with respect to policy violations leading to breach of the contract between the community and its environment.

    The spot would also be good to insert something about failures caused in cases where one agent is obliged to do something that is actually prohibited to happen. Such cases appear easily for instance in federations.

    Text to be provided!

  55. clause 7.9, line 34.

    Replace "An enterprise object is any object in an enterprise specification." by "An enterprise object is any object in an enterprise specification or any object fulfilling the requirements set for an enterprise object by an enterprise specification."

  56. clause 7.9, page 25, lines 6-10, editor's note

    Move to 7.5.2 after the bullet list.

  57. clause 9

    Move either to 7.11 or 8, before "8 compliance".
    Relabel "Conformance".
    Rationale: Reference points cannot be defined within one viewpoint only.
    Add text:
    " a complete enterprise specification contains conformance rules that define the required behaviour of the described ODP system, thus separating out the parts of the specification included for the purposes of analyse, understandability and communicatability of the specification.

    The conformance rules name the set of objectives and policies that form the conformance requirements. These statements are used in establishing reference points (defined in Part 3) and testing of system design or implementation conformance against this viewpoint specification." "

  58. Annex A

    Delete or rewrite to match the prescriptive text. We prefer removal.