The current PPMN XSDs were developed with a faulty translation of UML class relationships to the XSD elements.
To resolve this issue we need to specify the XSD patterns that correspond to the UML class relationships and then update the XSDs.

Defer to RTF

The resolution requires additional detail about what is "faulty" with the translations used as well as the heuristics used by the other specifications in the BPM+ family such as SCE and SDMN.

DateTimeValue and tDateTimeValue is defined in both PPMN and SCE Sematics XSD.

Recommend PPMN remove definition and reuse SCE definition

DateTimeValue and tDateTimeValue removed from SCE and PPMN.

DateTimeValue and tDateTimeValue will be removed from SCE and PPMN. They have already been removed from the specification and the metamodel and will be removed from the PPMN schema.

PPMN should reuse SCE definitions, remove from PPMN

Adornments removed from SCE and PPMN

These elements are part of the Adornments capability that has been removed from PPMN. Therefore these elements will be removed from the PPMN schema.

Remove from PPMN, PPMN reuses SCE's definition

Adornments removed from SCE and PPMN

These elements are part of the Adornments capability that has been removed from SCE and PPMN. They will be removed from the PPMN schema.

Remove from PPMN. PPMN reuses SCE

Remove tImport and Import from PPMN XSD

tImport and Import will be removed from the PPMN XSD.

Without those, interchange becomes less predictable.
The nsPrefixes need adding as mof:tags org.omg.xmi.nsPrefix.

Updating URIs

The metamodel had the URI and nsPrefix tags set but they may not have been exported to the XMI. The URIs were updated to include a current date.

The initial version was created using MOF2RDF rules, which are intended for metamodel management, not a deployable ontology.
Further, the ontology could use some documentation in the specification.

Defer to RTF

Defer to RTF.

This is odd and unnecessary, and could causes glitches in processing/searching

Unconfirmed in metamodel

Seems to be an issue with the export, not the metamodel. Close no change.

The spec doesn't clearly specify the constraints on the types of items that can be imported for a PPMN model.

Definition is part of SCE

The text is updated to reference the element from SCE. Further addition of constraints will be discussed in RTF.

Section 6.2 in bmi/22-09-01 (PPMN), section 6.2 in dtc/22-01-04 (SCE), and section 6.1.1 in formal/2011-01-03 (BPMN) show identical typographical conventions about references to graphical, non-graphical elements, and references to attributes or model associations. However, it appears that PPMN and SCE do not implement these conventions properly, certainly not in the manner observed in BPMN.

Comment too general.

The issue is too vaguely worded. Need more specific issues.

At line 993, Table 6 the text refers to a .formatRegistry, seemingly a class, which is not modeled or referenced in the text anywhere in PPMN or SCE.

Defer to RTF

Initial discussions show that further analysis and discussion of the resolution is required. Defer to RTF.

EntitySnapshot specifies an attribute creationDate when it already exists in its parent class Entity.

Issue already been addressed.

This issue was addressed in a previous resolution and is no longer an issue. The creationDate has been removed.

The statement in line 959, "Entities may represent some other thing of interest through EntityURI property," is ambiguous. What kind of relationship is "represent"? Is it a reference, correlation, or some undefined relationship? Depending on the definition of this relationship, we may introduce some inconsistencies in the metamodel.
Furthermore, table 5 in line 984 defines "entityURI" as "A URI to the Entity". This is ambiguous and difficult to reconcile with line 959.

Defer to RTF

Requires further discussion. Defer to RTF.

Section 8.11 Primitives shows UUID as a primitive (line 2356). However it does not appear anywhere in the document and may be unecessary.

Element already removed, Figure updated.

The element has already been removed from the primitives. However, the figure still showed the element. The figure will be updated.

In Fig. 3 UML diagram Entities and Entity Types, the class representing a snapshot of an Entity Type is incorrectly named EntitySnapshotType. The correct name should be EntityTypeSnapshot, i.e. a snapshot of an entity type rather than the type of an entity snapshot. This is further underscored in line 964, where the term EntityTypeSnapshots is used.

EntitySnapshotType is correctly named

The name is correct because it is the type of a Snapshot, not a Snapshot of a type.

Section 8.1 starting at line 965 contains references to EntityComposition and EntityTypeComposition relationships. These are not defined or modeled in bmi/22-09-01 or dtc/22-01-04.

EntityComposition and EntityTypeComposition names Fixed

EntityComposition and EntityTypeComposition names have been updated to their correct names - EntityRelationship and EntityRelationshipType, respectively.

The "EntityComposition relationship is referred to in the text at lines 961, 963, 965, and 1016, but is not defined in the specification and does not exist. The mechanism of composition is defined by SCE RelationshipKind class Composition.

Duplicate of PPMN 21

This is a duplicate of 21 and has already been fixed in PPMN-152. Unable to link the issue so just closing this issue.

Line 991, link to "SemanticReference" lands on section 10 "Parties Model" when it should land on section 12.6.2 SemanticReference. Perhaps it simply can be removed since section 12 SCE Model will be removed from bmi/22-09-01 and a reference to SCE might suffice.

SemanticReference already removed.

The element SemanticReference was removed from SCE and has been removed from PPMN as well in previous resolutions.

The property creationDate in Table 9, line 1021, is unnecessary. It already exists in parent class Entity.

Remove EntityShapshot.creationDate

The property creationDate of EntitySnapshot will be removed from Table 8 and the metamodel.

Line 1103 refers to an inherited property OccurrenceRole which does not exists. Rather, it should refer to inherited propery role which is of type OccurrenceRole

OccurrenceRole and OccurrenceRoleType are both defined

The issues says that OccurenceRole does not exist. However, the element is there in the specification.

The repeated text lines are next to each other. Figure 7 which uses lines 1078 and 1080 is the only thing that separated the identical verbiage.

Duplication not found

The duplication can't be found in the document. The text has been fixed in a previous resolution.

In figure 3, UML diagram Entities and EntityTypes, the name of the association owned by EntityType should be named "typeSnapshot" rather than "snapshotType". This naming format will also maintain consistency with the name "snasphot", the association end owned by Entity.

Already addressed

The diagram was updated in response to other issues and no longer needs to be addressed.

There are several issues with line 1015 sentence starting with: "Additionally, ...": the word "contain" (spelled "conain" in the doc) is used to mean composition, the attribute "parts" is used (no need to make part plural, it is already a collection), and finally it mentions an EntityComposition relationship which does not exist.

Issue already addressed

The text referenced is not in the document. This has already been addressed in previous resolutions.

Line 1006 reads as follows: "The kind of EntityTypeRelationship is specified by the type property inherited from ElementRelationship". There is no inheritance between these two classes.

Issue already addressed.

The issue was addressed by two other issues: PPMN-27/PPMN-106 and PPMN-71/PPMN-92.

They are shown on Figure 2.

Defer to RTF

This issue will be resolved in RTF after further discussion.

The content of 8.1 Entities lines 955 to 966 overlap with the content of 8.1.1 Entity.

Overlap is OK

The narrative of 8.1 is an overview of the section whereas 8.1.1 has the specifics for Entity. Therefore overlap in the narratives is actually expected.

Parties models should support creation of Org Chart type diagrams.

Defer to RTF

This issue will be deferred to the RTF.

Annex A contains an informal mapping, but there should also be a mapping ontology, mapping to the PROV-O ontology from W3C.

Defer Mapping to PROV-O

This issue is being deferred to RTF.

Line 1006 is the only reference to EntityTypeRelationship. This raises the question around the two class names "EntityRelationshipType" and "EntityTypeRelationship" mentioned in the same section 8.1.4. Combined with the fact that fig. 3 shows a derived attribute "part" for EntityTypes, i.e. an aggregation of Composition RelationshipKind amongst associations of an EntityType instance suggest we are missing some constructs in the diagram. At the very least, I believe a clearer text explanation is warranted.

Merged with PPMN 27

This is similar and addressed by PPMN-27/PPMN106.

At line 3574, the bookmark "RelationshipKinds" jumps to section 12.1.2 SCEElement. It does not provide any additional information about RelationshipKinds.

Resolved by removal of SCE Section

The SCE section has been removed as part of PPMN FTF2 Ballot 1. Therefore this issue has already been addressed.

The initial text in chapter 8 is redundant with the text in chapter 7. One or the other should be changed to remove the redundancy.

Text of Section 8 introduction Updated

The introductory text of section 8 will be updated to remove the redundancy. It will more specifically describe the elements of PPMN.

Specification says "All elements in PPMN are specializations of SCE BaseElement directly or NamedElement." This is not the case. PPMN elements specialize SCERootElement.

Addressed by PPMN-83

This issue has already been addressed by PPMN-83. SCE has been removed and captured in a separate specification. All references to it have been updated to address that resolution. No further change is needed.

Lines 908 and 909 specify that all elements in PPMN are specializations of SCE BaseElement or NamedElement. The SCE Metamodel has neither.

Addressed by PPMN-83

This issue was addressed by PPMN-83. SCE was moved to its own standard. References to those elements were updated per that specification. In doing so, this issue was addressed.

1. PPMN Class specifies a fill of light yellow. It is, in fact, a radial gradient. The border is a solid black line, but there is a bottom-right shadow that is not mentioned. If it is immaterial, it should be explicit, like "may or may not have a bottom-right shadow."

2. Parties Class is specified correctly and is consistent with the diagrams, but it differs from all others. For example, it has no fill gradient or shadow.

3. Why "Parties General Class"? Why not just "Parties Class"?

4. "Parentheses" is misspelled.

5. SCE Class has a radial gradient fill rather than solid, as implied. The figure in the table features a grey line. In diagrams, when an SCE class appears in a PPMN diagram, it has a solid black line. When shown in a diagram belonging to the SCE package, it has a grey line.

6. External class fill is light-colored radial gradient grey.

Fix Metamodel Color-Coding section

There are several issues raised within this one OMG issue. They will be addressed as follows:

1) No Change. The color is essentially yellow.
2) No Change.
3) Change "Parties General Class" element name to "Parties Class".
4) Fix spelling of "Parentheses"
5) Update the associated image to use an example from the model and update the text to include that the line around the box is black.
6) No change.

Occurrences need the ability to aggregate Occurrences sub-Occurrences without having them necessarily be in a sub-chain. This supports the tying together of different types of Occurrences such as a Custody Occurrence and a Pedigree Occurrence. An example is the loading of grain from a farm into a shipping truck that already has grain in it. This is a combination of the grain as well as custody of the grain passing from the farm or depot to the shipping company.

Modify OccurrenceRelationship and OccurrenceRelationshipType to include Composition

OccurrenceRelationship and OccurrenceRelationshipType are specializations of ElementRelationship and ElementRelationshipType, respectively. They are currently used to signify sequencing relationships between Occurrences. These elements could also be used to aggregate Occurrences as suggested by the issue. It would mean removing or changing how the predecessor relationship is calculated. This proposal suggests reusing "Transition" instance of RelationshipKind (from SCE) to represent "predecessor" occurrences. The predecessor property of Occurrence has therefore been updated to a derived property that will be calculated based on OccurrenceRelationships with kind set to Transition to account for that requirement. This also allows the use of other relationship kinds, especially "Composition" which would address the issue.

Table 4 includes the following acronyms:
BHMN : not used anywhere in this specification
SDMNDI: not used anywhere in this specification
RFC: the acronym is used but refers to "Request for Comments" rather than "Remote Function Call"

Erroneous or unused acronyms removed or fixed

Assuming this now refers to Table 3. Acronyms will be fixed.

PPMN doesn't have a way to graphically show relationships between elements that are otherwise captured as attributes. An example is the location of an Entity or a Party. The metamodel supports capturing the fact that an Entity is at a location and while locations do have a graphical representation, there isn't any given graphical notation for showing that the Entity is at that location. This significantly degrades the ability to graphically show where things are in relation to one-another.

Defer to RTF

This issue will be deferred to the RTF.

Figure 2 moves the Delegation and Additional Relationships packages beside Pedigree and Provenance packages. The two diagrams should be more consistent or one should be removed.

Just additional Detail

Figure 2 provides a bit more detail than what is needed in the previous Figure. Therefore, no change is needed.

Line 906 specifies: The PPMN specification is organized into a "number" of packages. Although minor and perhaps subjective, the statement might be clearer and more meaningful by stating "set of packages".

Current wording is sufficient

The current wording is sufficient.

PPMN section 6.6: Structure of this Document incorrectly copied section 6.6 of SDMN and its clauses.

Replace text of Section 6.6

Replace the text of Section 6.6 with the text contained herein that describes the structure of the PPMN specification.

The description of Entity attribute part which is a derived attribute says: the Entity or Entities that is/are contained by the Entity.
This may be ambiguous and misleading since the notion of containment differs from the notion of composition. The attribute part is derived so we should be explicit about its computation which in this case is the collection of all EntityRelationships of kind Composition from SCE ElementRelationship RelationshipKind.

Update text and diagrams to describe EntityRelationship and EntityRelationshipType

The current specification does not provide a detailed description of the relationships between Entities. These are intended to be specified by the EntityRelationship.kind property whose type is SCE RelationshipKind. the parts are the Entities pointed to by a EntityRelationship with a kind property set to "Composition". The text will be updated to describe this and a diagram will be added as well to show these relationships.

Lines 1006 uses the class name EntityTypeRelationship which does not exist.

Update EntityRelationshipType to inherit from ElementRe Mark this proposal as ready to be scheduled and voted in a ballot.After this action tlationshipType

EntityRelationshipType should inherit from ElementRelationshipType, not ElementRelationship. Also, the type is specified by the kind property, not the type property. Update the text to say this.

The description of attribute part of EntityType is ambiguous and needs elaboration. Additionally, part refers to the notion of composition while containment, a different concept, is mentioned in the text.

Update text to describe relationship of Part to EntityRelationshipType

The current specification does not provide a detailed description of the relationships between EntityTypes. These are intended to be specified by the SCE RelationshipKind. The text will be updated to describe this and a diagram will be added as well to show these relationships. The part derived property is computed based on the EntityRelationshipTypes that have a kind of "Composition".

Line 1105 refers to property outputEntities (plural). The property is singular output Entity and represents a collection. It must be noted that the symmetrical propety inputEntity is written in the singular form within the same paragraph.

Change outputEntities to outputEntity

Change the name in the text to match the attribute name "outputEntity". This occurs in multiple locations.

Annotation and tAnnotation are defined in both PPMN and SCE Semantics XSD.

Recommend PPMN remove definitions and reuse SCE definition

New SCE Specification Does Not Include Annotation

The new standard for SCE no longer includes the Annotation element so there will be no conflict once PPMN and PMN are updated with the new SCE specification.

Section 6.6 Structure of this Document overviews SDMN dtc/22-01-03 and its clauses. Rather, its topic should be PPMN and its clauses.

Duplicate of PPMN-3

This issue is a duplicate of issue PPMN-3 and will be closed or merged.

Lines 960/961 state "All entities-related classes are ultimately SCEElements and as such have a name, id, URI." SCEElement in the SCE Metamodel has the following attributes: name, id, aliasID, and humanID. There is no URI.

Text related to SCE will be updated to align to finalized SCE.

A separate specification has been created for SCE. Text will be updated to align with that specification. More specifically, references to SCEElement will be changed to either BaseElement, if the element is not intended to be a root element in the model, or RootElement, if it is intended to be a root element.

All "Adornment Value" links in section 8.7.1 resolve back to the Adornment Value header 8.7.1.1. They do not provide more information.
All "Annotation" links in section 8.7.2 resolve back to the "Annotation" header 8.7.1.2. They do not provide more information.

Extensions can be handled using MEF.

Adornments will be removed from PPMN since MEF provides a more flexible capability and is already a standard.

PPMN should reuse SCE definition, remove from PPMN

Adornments no longer necessary

Adornments were added to enable organizations to add their own metadata to PPMN and PMN elements. However, MEF is already a standard and supports the same capability. Therefore adornments will be removed from specification and from the XSDs. MEF will be used instead.

SCE is replacing the SCEVocabulary element with the SCEKindSet element (and related elements).
PPMN uses the vocabulary mechanism and thus will need to be updated appropriately.

Removing SCE from PPMN and Updating Dependencies

A separate standard has been created for SCE. PPMN and PMN will be updated to use that standard. Further, SCE vocabularies have been replaced by KindSets. PPMN and PMN will switch to that mechanism.

SCE is replacing the SCEVocabulary element with the SCEKindSet element (and related elements).
PMN uses the vocabulary mechanism and thus will need to be updated appropriately.

New SCE Standard

A separate standard has been created for SCE. PPMN and PMN will be updated to use that standard. Further, SCE vocabularies have been replaced by KindSets. PPMN and PMN will switch to that mechanism.

The SCE content is defined in the SCE specification (bmi/21-12-09).

Remove SCE sections from PPMN.

A separate specification has been created for SCE. That specification will be referenced from PPMN.

Lines 908 and 909 specify that all elements in PPMN are specializations of SCE BaseElement or NamedElement. The SCE Metamodel has neither.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

PPMN section 6.6: Structure of this Document incorrectly copied section 6.6 of SDMN and its clauses.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

All "Adornment Value" links in section 8.7.1 resolve back to the Adornment Value header 8.7.1.1. They do not provide more information.
All "Annotation" links in section 8.7.2 resolve back to the "Annotation" header 8.7.1.2. They do not provide more information.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Figure 2 moves the Delegation and Additional Relationships packages beside Pedigree and Provenance packages. The two diagrams should be more consistent or one should be removed.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Table 4 includes the following acronyms:
BHMN : not used anywhere in this specification
SDMNDI: not used anywhere in this specification
RFC: the acronym is used but refers to "Request for Comments" rather than "Remote Function Call"

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Line 906 specifies: The PPMN specification is organized into a "number" of packages. Although minor and perhaps subjective, the statement might be clearer and more meaningful by stating "set of packages".

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The content of 8.1 Entities lines 955 to 966 overlap with the content of 8.1.1 Entity.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The initial text in chapter 8 is redundant with the text in chapter 7. One or the other should be changed to remove the redundancy.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Specification says "All elements in PPMN are specializations of SCE BaseElement directly or NamedElement." This is not the case. PPMN elements specialize SCERootElement.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Section 6.6 Structure of this Document overviews SDMN dtc/22-01-03 and its clauses. Rather, its topic should be PPMN and its clauses.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Lines 960/961 state "All entities-related classes are ultimately SCEElements and as such have a name, id, URI." SCEElement in the SCE Metamodel has the following attributes: name, id, aliasID, and humanID. There is no URI.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The SCE content is defined in the SCE specification (bmi/21-12-09).

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Line 1006 is the only reference to EntityTypeRelationship. This raises the question around the two class names "EntityRelationshipType" and "EntityTypeRelationship" mentioned in the same section 8.1.4. Combined with the fact that fig. 3 shows a derived attribute "part" for EntityTypes, i.e. an aggregation of Composition RelationshipKind amongst associations of an EntityType instance suggest we are missing some constructs in the diagram. At the very least, I believe a clearer text explanation is warranted.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

In figure 3, UML diagram Entities and EntityTypes, the name of the association owned by EntityType should be named "typeSnapshot" rather than "snapshotType". This naming format will also maintain consistency with the name "snasphot", the association end owned by Entity.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

There are several issues with line 1015 sentence starting with: "Additionally, ...": the word "contain" (spelled "conain" in the doc) is used to mean composition, the attribute "parts" is used (no need to make part plural, it is already a collection), and finally it mentions an EntityComposition relationship which does not exist.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Section 8.1 starting at line 965 contains references to EntityComposition and EntityTypeComposition relationships. These are not defined or modeled in bmi/22-09-01 or dtc/22-01-04.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The statement in line 959, "Entities may represent some other thing of interest through EntityURI property," is ambiguous. What kind of relationship is "represent"? Is it a reference, correlation, or some undefined relationship? Depending on the definition of this relationship, we may introduce some inconsistencies in the metamodel.
Furthermore, table 5 in line 984 defines "entityURI" as "A URI to the Entity". This is ambiguous and difficult to reconcile with line 959.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

In Fig. 3 UML diagram Entities and Entity Types, the class representing a snapshot of an Entity Type is incorrectly named EntitySnapshotType. The correct name should be EntityTypeSnapshot, i.e. a snapshot of an entity type rather than the type of an entity snapshot. This is further underscored in line 964, where the term EntityTypeSnapshots is used.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The "EntityComposition relationship is referred to in the text at lines 961, 963, 965, and 1016, but is not defined in the specification and does not exist. The mechanism of composition is defined by SCE RelationshipKind class Composition.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Line 991, link to "SemanticReference" lands on section 10 "Parties Model" when it should land on section 12.6.2 SemanticReference. Perhaps it simply can be removed since section 12 SCE Model will be removed from bmi/22-09-01 and a reference to SCE might suffice.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

EntitySnapshot specifies an attribute creationDate when it already exists in its parent class Entity.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

At line 3574, the bookmark "RelationshipKinds" jumps to section 12.1.2 SCEElement. It does not provide any additional information about RelationshipKinds.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The property creationDate in Table 9, line 1021, is unnecessary. It already exists in parent class Entity.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Section 8.11 Primitives shows UUID as a primitive (line 2356). However it does not appear anywhere in the document and may be unecessary.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Line 1006 reads as follows: "The kind of EntityTypeRelationship is specified by the type property inherited from ElementRelationship". There is no inheritance between these two classes.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

At line 993, Table 6 the text refers to a .formatRegistry, seemingly a class, which is not modeled or referenced in the text anywhere in PPMN or SCE.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Lines 1006 uses the class name EntityTypeRelationship which does not exist.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

SCE is replacing the SCEVocabulary element with the SCEKindSet element (and related elements).
PPMN uses the vocabulary mechanism and thus will need to be updated appropriately.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

SCE is replacing the SCEVocabulary element with the SCEKindSet element (and related elements).
PMN uses the vocabulary mechanism and thus will need to be updated appropriately.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The description of Entity attribute part which is a derived attribute says: the Entity or Entities that is/are contained by the Entity.
This may be ambiguous and misleading since the notion of containment differs from the notion of composition. The attribute part is derived so we should be explicit about its computation which in this case is the collection of all EntityRelationships of kind Composition from SCE ElementRelationship RelationshipKind.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

Section 6.2 in bmi/22-09-01 (PPMN), section 6.2 in dtc/22-01-04 (SCE), and section 6.1.1 in formal/2011-01-03 (BPMN) show identical typographical conventions about references to graphical, non-graphical elements, and references to attributes or model associations. However, it appears that PPMN and SCE do not implement these conventions properly, certainly not in the manner observed in BPMN.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The description of attribute part of EntityType is ambiguous and needs elaboration. Additionally, part refers to the notion of composition while containment, a different concept, is mentioned in the text.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force