Via issue VF-50 the property isAtomic was introduced. It is desirable to add a small example to further explain its use.

Add example to the definition of property isAtomic of ValueElement class

Add a small example to the definition of property isAtomic of the ValueElement class. Note that this property was introduced via the already approved issue VF-50 in the now closed Ballot#1.

Some association ends do not have a name in the meta-model. These are:

• Opposite end of roleDefinition (in the association between Role and RoleDefinition)
• Opposite end of capability (in the association between CababilityMethod and Capability
• Opposite end of roleDefinition (in the association between RoleLibrary and RoleDefinition)
• Opposite end of roleCategory (in the association between RoleLibrary and RoleCategory)
• Opposite end of roleLibrary (in the association between ValueDeliveryModel and RoleLibrary)

These omissions are in XMI only, as these ends (as association-owned ends) are not specified in the specification document itself.

Specify missing association ends

Specify the missing association ends in the XMI file.

Capability theory of authors like Hamel, Prahalad and others, served as one of the inputs into VDML. It was forgotten so-far to include non-normative references related publications.

Add non-normative references to Capability theory publications

Include references to the following related publications:

• Grant, R. M.,The Resource-Based Theory of Competitive Advantage: Implications for Strategy Formulation. California Management Review, March 1991.
• Prahalad, C.K and Hamel, G., The Core Competence of the Corporation. Harvard Business Review, May/June 1990.
• Teece, D. J., Pisano, G. and Shuen, A., Dynamic Capabilities and Strategic Management. Strategic Management Journal, August 1997.
• Zollo, M. and Winter, S. G., Deliberate Learning and the Evolution of Dynamic Capabilities. Organization Science, 2002, Vol. 13, No. 3.

Sub-clause 7.1.15 says: "This integration might be viewed as providing a super-Scenario with a Collaboration that engages each Scenario from one of the line-of-business models with a Scenario of the other line-of-business model, so the line-of-business Scenarios essentially become AnalysisContexts of the “super” Scenario."

This is incorrect, and inconsistent with the meta-model, as an AnalysisContext is exclusively owned by the context tree of a single Scenario, and is not shared across multiple Scenarios (as node their context tree).

Revise integration suggestion to make it compliant to the meta-model

Revise the following sentence in sub-clause 7.1.15, to make it compliant to the meta-model: "This integration might be viewed as providing a super-Scenario with a Collaboration that engages each Scenario from one of the line-of-business models with a Scenario of the other line-of-business model, so the line-of-business Scenarios essentially become AnalysisContexts of the “super” Scenario."

The word "calling" in the following sentence in sub-clause 7.1.13 is wrong: "A DelegationContext defines aspects of the particular delegation to the sub-Collaboration referenced as the calling Collaboration.". Because the calling Collaboration is not the sub-Collaboration, but the parent one.

Correct wrongly worded sentence about delegation

Replace the words "calling Collaboration" with "contextCollaboration" in the erroneous sentence. This will make the sentence correct.

Sub-clause 7.1.9 says "ValueDefinitions are captured in a ValueLibrary, as are MeasuredCharacteristics (SMM Library)." This is wrong. SMM Library does not contain MeasuredCharacteristics, but Characteristics. MeasuredCharacteristics are in VDML itself.

Sub-clause 7.1.12 says "Thus a VDML element may have different Measurements for the same Characteristic in different AnalysisContexts". This is wrong also. Measurements are linked to MeasuredCharacteristics (VDML). Not to Characteristics (SMM) directly.

Correct typos in 7.1.9 and 7.1.12

Replace "MeasuredCharacteristics" with "Characteristics" in the sentence "ValueDefinitions are captured in a ValueLibrary, as are MeasuredCharacteristics (SMM Library)." in sub-clause 7.1.9.

Also, replace "Characteristic" with "MeasuredCharacteristic" in the following sentence in sub-clause 7.1.12: "Thus a VDML element may have different Measurements for the same Characteristic in different AnalysisContexts".

Figure 6 and Figure 11 show the class CalendarService. Participant and Pool are associated with CalendarService. But CalendarService itself is not defined.

Add sub-clause to define CalendarService class

A sub-clause has to be added to define the CalendarService class.

A ValueElement can be "typed" by reference to ValueDefinition. ValueElements can be aggregated flexibly, whereby a ValueElement can be aggregated from ValueElements of the same "type", as well as of different "types". It would be better to have an option to enforce whether or not a ValueElement can be aggregated from ValueElements of the same "type".

Add optional attribute to ValueElement, to help constraining value aggregation

Add attribute "isAtomic: Boolean [0..1] = true" to ValueElement.
Semantics: "When a ValueElement isAtomic, this means that it is a leaf in the structure of aggregation of ValueElements of the same type of value (i.e. of ValueElements that refer to the same ValueDefinition in the ValueLibrary). When a ValueElement is not atomic (i.e. isAtomic equals "false"), this means that it is an internal node in the structure of aggregation of ValueElements of the same type of value."
Add three constraints also:
1) "When valueDefinition of a ValueElement is empty, isAtomic MUST be empty also".
2) "The valueDefinition of a ValueElement that isAtomic MUST be different from the valueDefinition of aggregatedFrom of the ValueElement".
3) “At least one of the ValueDefinition-referring aggregatedFrom of a non-atomic (i.e., for which isAtomic equals “false”) ValueElement MUST refer to the same ValueDefinition as that non-atomic ValueElement refers to.”

Note: Though the system would be able to show this distinction for complete models, even without this attribute, it would not be able to do so during the development of models. Hence the attribute is introduced to ensure consistency.

AggregatedFrom / AggregatedTo is related to ValueAdd. This prohibits aggregation of ValuePropositionComponents.

Move aggregatedFrom / aggregatedTo association from ValueAdd to ValueElement

Move aggregatedFrom / aggregatedTo association from ValueAdd to ValueElement, so that value aggregation applies to both ValueAdds and ValuePropositionComponents, in any combination). The articulatedValue association becomes then redundant and can be removed. This more flexible aggregation of value also makes ValueImpactForProvider of ValuePropositionComponent redundant, so that it can be removed also. Value aggregation to a ValueProposition to the provider (the business) can be used instead.

Currently a Scenario (VDML) can only have one Observation (SMM). This blocks the possibility to e.g. periodically monitor based on the same Scenario. It should be possible that a Scenario (actually AnalysisContext) links to multiple Observations. 

Change multiplicity of the Observation end of the association between AnalysisContext (VDML) and Observation (SMM)

Multiplicity of the Observation end of the association between AnalysisContext (VDML) and Observation (SMM) should change from 0..1 to 0..*.  

The isDefault attribute means to express that the Measurements in the Observation of the Scenario are "common" across all Scenarios in the model (i.e., they are incorporated by reference unless modified for a specific Scenario). It is then better to rename the attribute into "isCommon".

Rename attribute isDefault of Scenario into isCommon.

Rename attribute isDefault of Scenario into isCommon. And revise text and figures (diagrams) accordingly.

It is currently possible that cyclical patterns occur in Role Assignments. These should be avoided. It should also be avoided that a Role provides a Value Proposition to itself, as this has no real meaning.

Include meta-model constraints in relation to Assignment, Collaboration, ValueProposition and ValueElement

Include the following meta-model constraints: 1) A Role MUST NOT be assigned itself (directly, or indirectly via other Assignments). 2) A Role MUST not be assigned its containing Collaboration. 3) The provider of a ValueProposition MUST NOT be the recipient of that ValueProposition..

Sub-clause 2.1 is clear and understandable, but 2.2 and 2.3 are too vague. It is for example not clear if compliance to 2.2 includes 2.3 or not, and 2.3 need to provide a better definition of collaboration.

Make levels of conformance more explicit

Add clause numbers to references.
2.1 remove exception that "optional" elements need not be included.
2.2 clarify that conformance with notation is not required and that this is a subset of 2.1
2.3 clarify that this is a subset of 2.2 and name the specific classes that must be included for conformance.

ValueImpactForRecipient of ValuePropositionComponent is conceptually redundant with satisfactionLevel.

Remove valueImpactForRecipient from ValuePropositionComponent.

Remove valueImpactForRecipient from ValuePropositionComponent.

Customer satisfaction is important business value. Hence it is essential that satisfaction of recipients (typically customers) in relation to a ValueProposition that they receive, is aggregated to business value, as part of a ValueProposition to the business (the provider of the ValueProposition). VDML does already support measurement of satisfaction (satisfactionLevel) of a recipient with a value (ValuePropositionComponent). It is also possible to define the relative weight (percentageWeight) of a value for the recipient. There is, however, no straightforward support, based on the meta-model, to e.g. aggregate the "overall satisfaction" (typically the weighted average satisfaction of the ValuePropositionComponents) to business value (value as embodied in a ValueProposition to the provider of the ValueProposition). Resolution of this issue will depend on resolution of issue VF-1.

Handle ValueProposition related (satisfaction) measurement via an additional ValuePropositionComponent

Resolution has the following elements: 1) Add optional (0..1) association between ValueProposition and ValuePropositionComponent (called “overallSatisfaction" on the ValuePropositionComponent end). 2) Add a constraint to it: The overallSatisfaction of a ValueProposition MUST be a ValuePropositionComponent of the ValueProposition. 3) And also this constraint: The overallSatisfaction of a ValueProposition MUST not itself have percentageWeight. 4) As the overallSatisfaction component makes value measurement at ValueProposition header level redundant, the following associations can be removed from ValueProposition: propositionValue, satisfactionLevel, valueImpactForProvider and valueImpactForRecipient.

Page 15, last paragraph says: “but it provides a more abstract view than BPMN “ . It should say “ different “ . Rather than “ more abstract”.

Change the wording according to the suggestion in the Description

Change the wording according to the suggestion in the Description

You use color and fancy graphics in many places. This is misleading and has no place in a normative clause. All graphics and diagrams must be in pure black-and-white by default, unless color or special graphic styles are part of the normative syntax. You may use color to emphasize a certain fact in a graphic, but then you have to state in a legend to that graphic that this is not part of the syntax, explain the meaning of the color and what you are emphasizing. Particularly bad in figures 35, 39, 64, 65, 66, 76, 91. Marginal in figures 81, 95. Also in 89 and 90.

Remove color from graphics in figures 35, 39, 64, 65, 66, 76, 81, 89, 90, 91 and 95.

Remove color from graphics in figures 35, 39, 64, 65, 66, 76, 81, 89, 90, 91 and 95.

You have ownership violations in your diagrams specifying libraries. You need to have multiplicity [0..1] at the black diamond ends of the associations between the library class and the contained elements, or else these element could not legally exist outside the library. This pattern repeats for all library specifications.

No need to change meta-model and specification.

No need to change meta-model and specification. Library elements do not need to live outside the library. They are only referenced from other elements that comprise the actual design of the business.

VdmElement is the root of the VDML metamodel. However, In the first diagram in Figure 6, VdmElement is shown parallel to MeasurableElement (which is actually a subclass of VdmElement). Over the course of the following diagrams, the reader gets the feeling that VdmElement must be the true root, but it takes until figure 19 that you let the cat out of the bag... While Figure 6 is syntactical legal UML, I suggest to show MeasurableElement as a subclass of VdmElement in Figure 6 to establish clarity about root position of VdmElement from the very beginning.

Show MeasurableElement as a subclass of VdmElement in Figure 6

Show MeasurableElement as a subclass of VdmElement in Figure 6 to establish clarity about root position of VdmElement from the very beginning

Sub-clause 7.1 reads a bit dry, until you hit the first UML diagram. There is nothing technically wrong, but the FTF could improve the text.

Requirements to resolve "dryness" are not clear and are subject to further discussion

The sub-clause is accurate and provides useful understanding of how the elements of VDML work together. Thus there is not a technical need for change, but the issue should be deferred for further discussion in the RTF.

Your specification is a MOF metamodel and uses UML notation to specify the metamodel, therefore you need to add MOF and UML to your list of normative references.

Add MOF and UML to your list of normative references.

Add MOF and UML to your list of normative references.

It should not be possible that Ports of Activities of different Collaborations are directly connected via DeliverableFLows. That should not be allowed. Because flow of deliverables across Collaborations should go either via delegation from parent activities or via stores.

Add constraint to DeliverableFlow

Add the following constraint to 7.2.1.2.4 (DeliverableFlow class): "A DeliverableFlow MUST NOT connect Ports of Activities that are contained in different Collaborations.".

In 7.2.1.1.3, the following constraint on the Collaboration class is too strict: "All Ports of a Collaboration MUST be mapped to Ports of Activities that are contained in the Collaboration, via internalPortDelegations".

Remove constraint from Collaboration

Remove the following constraint from 7.2.1.1.3 (Collaboration class): "All Ports of a Collaboration MUST be mapped to Ports of Activities that are contained in the Collaboration, via internalPortDelegations".

In CapabilityLibrary, Characteristic (SMM) can be linked to both CapabilityDefinition and CapabilityCategory, and hence to the parent abstract class of both. In BusinessItemLibrary however, though there is a parent abstract class for both BusinessItemDefinition and BusinessItemCategory, Characteristic (SMM) can only be linked to BusinessItemDefinition. This is inconsistent.

Move association to Characteristic (SMM) to other class.

Move association to Characteristic (SMM) from BusinessItemDefinition to BusinessItemLibraryElement.

ValueProposition is mandatorily contained in Role. This makes re-use of VDML ValueProposition in other meta-models hard. Containment of ValueProposition in Role should rather be optional ("0..1" instead of "1").

Make ValueProposition - in - Role containment optional

Change multiplicity of the end of provider in the association between provider and providedProposition from "1" into "0..1".

Attribute valueMargin is conceptually redundant. ValueProposition (with ValuePropositionComponents) provides a generic structure that can express such values as margin and profit also.

Remove attribute valueMargin from the Party class

Remove attribute valueMargin from the Party class in sub-clause 7.2.2.1.2, as well as references from the text in other (sub-)clauses.

The text in the sub-clause that defines the ValuePropositionClass (7.2.1.3.1) refers to the attribute "componentValue" that does no longer exist in the meta-model.

Remove reference to obsolete attribute

As the text in sub-clause 7.2.1.3.1, that references the obsolete attribute "componentValue", is removed per resolution of issue VF-2, no further revision is required for this issue.

VDML beta1 refers to SMM 1.0. The SMM revision (SMM 1.1 RTF) enables for better integration and improves SMM on aspects relevant to VDML. Hence VDML 1.0 (FTF result) should refer to SMM 1.1 instead. This will impact the VDML 1.0 XMI also.

Refer to SMM 1.1 from Normative References and from VDML 1.0 XMI

Refer to SMM 1.1 from Normative References and from XMI. The Package diagram (Figure 28) has to be updated also.

In the table in sub-clause 8.4, port shapes are denoted as "rectangle". They are "squares" however.

Use the right word to denote the shape of a Port

Replace the word "rectangle" with "square" in the table in sub-clause 8.4 (it is used six times there to denote the shape of a Port).

In 7.2.2.3.1 (OrgUnit class), the following constraint is too strict: "When an OrgUnit provides more than one CapabilityOffer, these CapabilityOffers MUST provide different Capabilities".

Remove constraint from OrgUnit class

Remove the following constraint from 7.2.2.3.1 (OrgUnit class): "When an OrgUnit provides more than one CapabilityOffer, these CapabilityOffers MUST provide different Capabilities".

It is currently allowed that a Port of an Activity that is contained in a Collaboration, can be connected to multiple Ports of the containing Collaboration. That should not be allowed.

Add constraint to InputDelegation and OutputDelegation Classes

Add the following constraint to 7.2.4.4.2 (InputDelegation Class): "An InputPort of an Activity that is contained in a Collaboration MUST NOT be mapped, via InputDelegation, to more than one InputPort of the containing Collaboration", and add the following constraint to 7.2.4.4.3 (OutputDelegation Class): "An OutputPort of an Activity that is contained in a Collaboration MUST NOT be mapped, via OutputDelegation, to more than one OutputPort of the containing Collaboration".