Subclause 9.3.4.1 originally had an "ActivitySpaceAndActivity::Language elements" diagram (similar to language elements diagrams for other areas). However, this seems to have gotten lost in the preparation of the FTF Beta 2 document and it does not appear in the formal version of the specification.

Restore the diagram

Restore the ActivitySpaceAndActivity::Language elements diagram that was in the FTF Beta 1 document.

The resolution to Issue ER-2 added a shortDescription attribute to the Checkpoint language element and updated the invariant for that element to "self.shortDescription <> null implies self.description <> null". However, the Checkpoint::description attribute is mandatory (multiplicity [1]), so it can never be null. This means that the new invariant is unnecessary.

Also, the correct number for the new subclause is 9.7.5.8.2, not 9.7.4.7.5.

Do not add invariant

As proposed in the issue description, do not add the invariant proposed in the adopted resolution to Issue ER-2 and correct the subclause number.

There was an error made in a recent change to the definition of practice. Please return the definition to the original "A practice is a repeatable approach to doing something with a specific purpose in mind."

The current definition states that a practice is a description...
A practice is not a description. A practice does not need to be described to be a practice.

Update glossary and language specification descriptions

This resolution makes the description of the Practice language element give a primacy to the definition as given in Clause 4 on what a practice actually is, while still providing additional information on what is included in a Practice model element in the language.

Request a change to the symbol used for Activity Spaces from the current rectangle with a "pointie head" to a basic rectangle with NO pointie head similar to the Areas of Concern symbol.

Rationale: The symbol is causing confusion to people leading them to think this is an activity rather than a generic container for activities and leading them to believe their is an implied sequential order which is not the case.

Not worth the change

It was decided that making such a change was not worth the benefit.

Problem to be solved:

The spec supports state cards but not level of detail cards.

Proposed solution:

Add new section “9.7.5.8.2 Level of Detail Card” similar to section “9.7.4.7.5 Alpha State Detail Card”.

Add new subclause

Add a new subclause describing level of detail cards.

Problem to be solved:

The cards may not have enough space to display the full descriptions of all checkpoint in all cases. The language only defines one property “description” for checkpoints and does not support abbreviated descriptions. On the other hand, it declares attribute “name” which is not used on the cards or anywhere else.

Proposed solution:

The attribute “name” in language element “Checkpoint” is renamed to “shortDescription” for an optional abbreviated version of the full description. An OCL constraint is added to ensure that "shortDescription" is not empty only if “description” is not empty.
The definition of a card body (page 119) is extended by: “If provided, the abbreviated description of a checkpoint is used as a default.”

Add short description

It is agreed that this would make the normative cards be the most useful. However, for backwards compatibility, it would be best to keep the name attribute and just add shortDescription.

Request a change be made to the phrase "completion criteria" under Kernel Activity Spaces, to "primary goals".

Rationale: Phrase "Completion criteria" is leading people to the wrong understanding, such as the wrong belief that activities will end when "completion criteria" met.

"primary goals" is a more accurate phrase for the intent.

Closed, no change

Changing the phrase "completion criteria" to "primary goals" would not be consistent with the language specification, which specifically indicates that both activities and activity spaces have criteria, of which completion criteria are one kind. Changing this, especially if just for activity spaces, would be a significant update to the language that does not seem to be justified by the rationale given in this issue. The fact that activities can span multiple activity spaces is clear from the language metamodel, in that one Activity can have ActivityAssociations with multiple ActivitySpaces. This should be made clear in tutorial presentations on Essence, but an update to the specification is not necessary.

Problem to be solved: The definition of five generic competency levels in section 8.1.6 (pages 16 to 19) is not supported in that detail by the definition of the language elements in section 9.3.5 (pages 86 to 88). Mismatches are in particular:
- Section 8.1.6 states “Each competency has five levels of achievement. These are standard across all the kernel competencies […]”, while section 9.3.5.2 allows zero to many levels and does not enforce any standard instantiations.

• Table 1 in section 8.1.6 summarizes the proposed competency levels in checklist style, while section 9.3.5.3 does only allow free text properties for that purpose.

Proposed solution: It is proposed to enhance section 9.3.5 as follows:

• Change section 8.1.6 to say “across all competencies”
• Add a clarifying note in section 9.3.5 that each tool claiming conformance to the standard must implement the kernel and therefore has to provide the standard instantiations for competencies as defined in table 1 in section 8.1.6. To enforce this partially via the language directly, change multiplicity on association “possibleLevel” in section 9.3.5.2 from * to 5.
• Add an association “checkListItem [*]” in section 9.3.5.3 that targets model element “Checkpoint”. For architectural clearness, move this element from package “AlphaAndWorkProduct” to “Foundation”.

Close no change.

This has already partially been resolved. In particular, section 9.3.5.3 is already updated as suggested. The RTF does not feel that the suggestion to change the multiplicity definition in section 9.3.5.2 is a good idea. The other suggestions are just minor additions that might be a service to the reader, but not particularly important.

"Requirements::Acceptable" should be "Requirements::Addressed"

Merged

The resolution to ER-21 removes the listing of intermediate states (such as the one referenced in the issue) in the completion criteria of kernel activity spaces. The issue is effectively handle in the resolution to ER-21 by including "Requirements::Acceptable" (rather than Requirements::Coherent) as an entry criterion of the Test the System activity space, such that the first state to which Requirements may be progressed by activities in the activity space is Requirements::Addressed (the successor to Requirements::Acceptable).

The Essence metamodel contains Dependencies which are not valid in MOF metamodels as per the constraints in the MOF spec.

Change dependencies to package imports

In subclause 7.3.1, it says "The dependency between the packages [depicted in Figure 9.3] is expressed with import relationships." However, the relationships shown in Figure 9.3 are actually captured in the abstract syntax model as Dependencies, rather than as PackageImports.

Point 3b) says “Bind transformed Work Product Definitions to Essence kernel Alphas […] by establishing Essence Alpha Containments […].”

This is wrong. Instead, second part should be “[…] by establishing Essence Work Product Manifests […].”

Change wording

The correction is agreed to.

None of the Activity Spaces seems to address the Requirements::Addressed Alpha State. All other Alpha States of the Kernel are addressed by Completion Criteria of Activity Spaces.

If an Alpha States is not be addressed by any of the Alphas it would not be defined how to progress from its preceding Alpha state to itself.

Having an Endeavour in a Method Enactment standing at Requirements::Acceptable the Kernel would not determine which next Activity (Space) to choose in order to progress the Alpha.

Merge with ER-11

Resolving ER-11 results in an activity space with Requirements::addressed as a completion criterion, which also resolves this issue.

The semantics of "Action" only talks about work products but it can do the same things on alphas also I assume.

Defer

This issue was received too late for consideration for Essence 1.1, but the RTF feels it should be considered for Essence 1.2.

There are many cases in the kernel in which the completion criteria for an activity space include multiple states for the same alpha. But, from the definition of "completion criterion” in the language, it is unclear what it means to have to complete multiple states for the same alpha. It seems redundant, since when you achieve a later state, it is assumed that all earlier states have already been met.

Add entry criteria and update completion criteria

The states currently listed as "completion criteria" a kernel activity space are those states to which various alphas may be progressed by activities considered to be within the activity space. This is useful information, but it is confusing to refer to them all as "completion criteria", since some are really intermediate states of an alpha that must be progressed further before the activity space can truly be considered "complete".

For alphas that are expected to be progressed from some starting state to some final state by activities within an activity space, it would seem more correct to list the starting state of the alpha as an entry criterion for the activity space and the final state as a completion criterion. The problem with this is that the current language definition of entry criteria for an activity or an activity space seems to indicate that all the entry criteria must be fulfilled before the activity or activity space can start (logical "and" of the criteria). But this is not what is desired for an activity space, because an activity within an activity space will be able to start progressing alphas within the context of that activity space as long as the entry criteria for that activity are fulfilled, even if alphas unrelated to the activity have not reached the entry criterion state required for the activity space.

Therefore, the proposal for resolution of this issue is as follows:

1. Update the language definition of EntryCriterion to make it clear that work of an activity space can start when "one or more of its entry criteria are fulfilled" (logical "or" of entry criteria).

2. Update the kernel specifications for activity spaces to only list the final state of each alpha in the completion criteria (do not list intermediate states).

3. Update the kernel specifications for activity spaces to add entry criteria listing the required initial states of relevant alphas (these will be a subset of the input alphas for the activity space).

PRINCIPLE OF ALPHA STATE INDEPENDENCE
The Essence Kernel framework is featured as independent of all methods and practices.

Dependent relationships among Essence Kernel alphas are established and determined by the choice of methods and practices their users import, that is, methods and practices supply the integrating glue that binds alphas.

Consequently, the checklist conditions for achieving an alpha state must be intrinsically associated with the alpha of which they are apart and should not explicitly import or repeat checklist conditions from other alphas.

A careful and critical review of the OMG Essence standard reveals that while these principles and rules of construction are fait fully adhered to in the Stakeholder, Software System, Team, Work, and Way of Working alphas, they are violated in the Opportunity and Requirements alphas where checklist conditions from each are explicitly restated as well as the Software System alpha.

It appears that the authors may be tilting towards the Agile Development Method and permitting the Agile way of thinking on the Opportunity and the Requirements to bleed through despite the method and practice promise and intention of Essence.

Specifically:

1.Stakeholders- OK

2. Opportunity
Issue 1: The Identified state imports checklist conditions from the Stakeholder alpha, that is, Recognized and Represented.
Issue 2: The Solution Needed state imports checklist conditions from the Stakeholder alpha, that is, Recognized and Represented.
Issue 3: The Solution Needed state imports checklist conditions from the Requirements alpha, that is, Acceptable and Addressed.
Issue 4: The Addressed state imports a checklist condition from the Software System alpha, that is, Usable.

3. Requirements
Issue 1: The Conceived state imports checklist conditions from the Stakeholder alpha, that is, Recognized, Represented, and Involved.
Issue 2: The Conceived state imports a checklist condition from the Opportunity alpha, that is, Identified.
Issue 3: The Bounded state imports checklist conditions from the Stakeholder alpha, that is, Recognized, Represented, Involved, and In Agreement.
Issue 4: The Coherent state imports checklist conditions from the Stakeholder alpha, that is, Recognized, Represented, Involved, and In Agreement.
Issue 5: The Accepted state imports a checklist condition from the Stakeholder alpha, that is, In Agreement.
Issue 6: The Addressed state imports checklist conditions from the Stakeholder alpha, that is, In Agreement and Satisfied for Deployment.
Issue 7: The Fulfilled state imports a checklist condition, that is, Satisfied In Use.

4. Software System- OK

5. Team- OK

6. Work- OK

7. Way of Working- OK

Close, no change.

The references from certain alpha checklist items to other alphas is intentional and not unreasonable, since there are associations between alphas, as reflected in kernel specification. However, this does not imply explicit dependencies between the alpha states – checklist items in one alpha do not actually refer explicitly to specific states in other alphas, but just general conditions that need to be checked. It should also be noted that kernel activity spaces are likely to advance alphas in the same area of concern together, indicating that alphas may move forward in "waves". Further formalization of this wave might allow the alpha checklists to be made more independent, but this is a topic that will require future research, and it would not be appropriate to change the specification in this regard at this time.

UNDERSTANDABILITY ISSUE
1. In Team alpha, the state label "Seeded" is not understandable. Perhaps "Seeded" is a language translation anomaly.
2. The dictionary definition states, "given the status of seed in a sports tournament." Googling "Team Seeded" results in sports returns reflecting such a definition.
3. "Selected" is understandable and the logical predecessor state for the successor state "Formed".

ACTION: Suggest that the revised OMG Essence standard adopt the change of replacing "Seeded" with "Selected" as the initial state in the Team alpha.

Closed, no change

The Team alpha's Seeded state is defined as: “The team’s mission is clear and the know-how needed to grow the team is in place."

Merriam-Webster’s dictionary (the dictionary chosen by the team that developed Essence) defines "seed" as “the grains.. used for sowing” and refers to “capable...of germination...to produce a new plant”. It is this meaning of the word "seeded" that is meant in the choice of the state name because, in the Seeded state, the team knows how to grow, but there actually may not yet be team members selected. That starts to happen in the formed state.

The term “selected” for this state would give an inaccurate meaning to the state, since team members have not necessarily been selected at this point.

SEMANTIC DISCIPLINE ISSUE
1.The three concerns of Customer, Solution, and Endeavor are permitted to progress independently.
2. Page 4 Areas of Concern, "Elements in kernels or practices may be divided into a collection of main areas of concern that a software engineering endeavor has to pay special attention to. All elements fall into at most one of these."
3. However, the OMG Essence Standard employs "Solution", one of three concerns, in the Customer concern Opportunity alpha "Solution Needed" state.
4. The result is the use of the word "Solution" in both the name of a concern and in the separate concern of Opportunity as an alpha state "Solution Needed."

ACTION: Since software is known to be the domain of consideration in Opportunity, the "Solution Needed" state in the alpha Opportunity should be be relabeled "Software Needed", thereby eliminating this semantic intrusion of concern terminology into alpha state of a different concern. Suggest that the revised OMG Essence standard adopt this change.

Close, no change

Currently, the specificity of the Essence kernel to "software" is captured almost entirely within the Solution domain – or, more accurately, the specificity is to "software system", which may also include the hardware the supports the software. The alphas in the Customer and Endeavor areas of concern can and should largely apply to cases where the solution may not be a software system. While the current standard kernel focus on software-system solutions, the intent is that it be customizable for use with other solution areas – and, in fact, some groups have actually done this.

Further, from a Customer point of view it makes more sense to talk about whether a solution is needed than whether that solution is specifically a "software system" or even a "system". The focus should be on the value of the solution needed, not on what the solution "is". It was with this in mind that the term "solution" was specifically used in the name of the state "Solution Needed" when Essence was developed.

There was an error made in a recent change to the definition of Activity. Please return the definition to the original, "An activity defines one or more kinds of work items and gives guidance on how to perform these"

The current definition refers to work products which is wrong because an activity does not require a work product.

Update glossary and language specification descriptions

The changes given in this resolution make, the descriptions in the language consistent with the definition in Clause 4, without using the term “work item”, which is not actually defined in the language.

Refinement proposals as in the attached file, primarily related to state checklists.

Defer

This issue was received too late for consideration for Essence 1.1, but the RTF feels it should be considered for Essence 1.2.