BACM relies on VDML to address the operational business design of a BACM business architecture. This requires a VDML interface specification for exchange of relevant model elements of business-architecture and business design

VDML spec section 7.2.3.1.1 says AnalysisContext is the superclass of VdmlElement, but section 7.2.3.2.1 says, and Figure 7.18 shows AnalysisContext as a sub-class of VdmlElement.

Right under Figure 8-63, we can read: "Revision of includes adding a property influence to MeasureRelationship (the class in SMM that “types” MeasurementRelationships)."

This sentence is hard to understand and is probably not correct grammatically, either.
I suggest to rewrite, such as:
"MeasureRelationship (the class in SMM that “types” MeasurementRelationships) has a property influence."

A Collaboration is both Participant and PortContainer.
Not only Figure 7.6 tells that, but also the following text:
• In 7.2.1.1.3: "Collection of Participants joined together for a shared purpose or interest."
• In 7.2.1.1.4: "Participants can be Actors (human or automatons) or Collaborations or Roles of Actors or Collaborations."
• Probably on more places (I expect so).
However, in 7.2.1.1.3, under the SuperClass heading, only PortContainer is listed, and Participant has been overlooked.
This is an omission and should be fixed.

The VDML 1.0 specification integrates with SMM 1.1. Meanwhile SMM has been upgraded to SMM 1.1.1. But, as VDML needs to be revised, to a new revision VDML 1.1, and meanwhile SMM is revised to SMM 1.2, the integration of VDML 1.1 should be with SMM 1.2

*Integrate VDML 1.1 with SMM 1.2 *

This impacts both the VDML 1.1 xmi and the specification. In the specification, both the reference in the references list is updated and the Package diagram that shows the integration.

Sub-clause 8.4 (Activity Network), in the caption of Figure 8.20, page 90, says “Shape of OutputPort, with ValueAdd, on boundary of Activity OutputPort”. It does not seem correct. The word ”OutputPort” at the end should be removed.

Remove the wrong word from the Figure's caption

Remove the wrong word "OutputPort" from the Figure's caption

Sub-clause 7.2.4.1, right above Figure 19, on page 59, says: "This diagram begins to show integration with SMM, discussed later.". But already in an earlier sub-clause, about Analysis Context and Scenario, integration with SMM was specified (to Observation). So it is not true that "this diagram (i.e., Figure 19) begins to show integration with SMM". Removing the sentence would be the easiest way to fix this.

Remove incorrect statement

Remove the incorrect statement. It can safely be removed without losing essential information.

VDML 1.0 integrates with SMM 1.1. In the SMM specification, in Figure 71, it is demonstrated that Element (CMOF) does not own measurement (the opposite association end, but rather the association owns it. However, when the same association is shown in the VDML 1.0 specification, in Figure 7.19, on page 59 of sub-clause 7.2.4.1, it shows with the measurement owned by Element (CMOF). This does not seem correct. The same problem is there in Figure 7.29, on page 82, in sub-clause 7.2.6.2.

Fix SMM association in diagrams in VDML

Show SMM association correctly in two diagrams in the VDML specification.

Figure 7.16, in sub-clause 7.2.2.4 (Capability Methods), page 51, shows the class “Performer”, but it appears that it is never defined. Consider adding its Class definition to the VDML specification.

Define the class Performer

Add a new Sub-clause to define the class Performer

There must be consistency between the Capability Method to which an Activity delegates (in a particular Delegation Context) and the Capability Offer that is applied by the Activity. A constraint, to enforce this consistency, is missing in the specification. It should be added.

Add missing constraint

Add the missing constraint.

Constraint “Activities that are performed by a Role MUST be contained in the same Collaboration that also contains the Role.” in Constraints of sub-clause 7.2.1.1.5 (Role Class), on page 31, is redundant with constraint “The Role that performs an Activity MUST be contained in the Collaboration that also contains the Activity.” in Constraints of sub-clause 7.2.1.2.1 (Activity Class), on page 34

Remove redundant constraint from Role

Remove the redundant constraint from the Role Class.

The VDML specification specifies that the name of the deliverable on the Deliverable Flow is shown alongside the connector that represents the Deliverable Flow. This is bit limited, and can easily be extended to make it more useful.
Furthermore, the text that specifies connectors in Activity Network Diagrams contain a few text errors, such as "along the alongside the connector", as well as a redundantly repeated phrase "Also here, the name along the alongside the connector represents the name of the deliverable.". Please fix that also.

Extended form of text alongside connector

Extend text alongside the connector with state of the deliverable.
Fix the text errors in the text about connectors in Activity Network Diagram.

The explanation of Figure 7.2 (Capability Offers), in last paragraph of sub-clause 7.1.8 (Capability Method), is a bit difficult to read (page 19). Can the readability of it be improved. Similarly, the first paragraph of sub-clause 7.1.9 (Activity) is a bit difficult to read (also on page 19). Can you improve readability there as well.

Improve readability of sub-clause 7.1

Update text, so that things are more clearly explained.

In sub-clause 7.1.8 (Capability Method) the specification talks about CMMN, but it is not listed as reference.
More-over, BPMN is included as reference twice.

Add reference to CMMN

Add a normative reference to CMMN to sub-clause 3.1, and remove redundant reference to BPMN from sub-clause 3.2.

Sub-clause 7.1.7 (Organization Unit) says "A Capability may produce value directly for a customer or it may contribute value when it is engaged in a specific Activity of a value stream.".
It is unclear what the first half of the sentence means. The second part of the sentence talks about concepts that will be dealt with, and will be dealt with more clearly, in later sub-clauses, and are referred to too early here therefore.

Remove confusing and redundant sentence

This sentence will be removed, as it is indeed unclear and redundant.

Sub-clause 7.1.6 (Business Networks) talks about the net economic value for a party, and how it can be modeled. This statement is a bit fuzzy and is influenced by some elements in the VDML beta1 meta-model around Value Propositions and Business Networks, that got changed in VDML 1.0.

Make statement about net economic value more clear

Make statement in sub-clause 7.1.6, about net economic value, more clear, and more obvious in the light of the meta-model.

In the VDML 1.0 specification, the definition text in the specification assumes the UML predefined type “String” (with capital “S”), however, the meta-model diagrams expose the type “string” (lower case “s”). This means that the meta-model (and so the XMI) actually use the type “string”. This has several problems. Firstly, it is not a predefined UML type, and the VDML specification neither defines it, so, it is basically undefined. Secondly, SMM 1.1 is integrated into VDML 1.0, and SMM 1.1 uses the predefined UML type “String” (with capital “S”). Hence VDML has better also use the UML type “String”.

Replacing string by String in diagrams and in the model

Replacing undefined "string" type by the predefined UML type "String", in the model (and hence in the XMI) and in some diagrams in the specification.

In sub-clause 7.2.5.1 (BusinessItemLibrary), in Figure 7.23, page 68, the multiplicity on end of BusinessItemLibraryElement (of association to Characteristic) is not shown. It should be shown as (0..*). The same problem also occurs in the following three places:
1) In sub-clause 7.2.5.2 (ValueLibrary), in Figure 7.24, page 70, the multiplicity on end of ValueDefinition (of association to Characteristic) is not shown. It should be shown as (0..*).
2) In sub-clause 7.2.5.3 (CapabilityLibrary), in Figure 7.25, page 73, the multiplicity on end of Capability (of association to Characteristic) is not shown. It should be shown as (0..*).
3) In sub-clause 7.2.5.5 (RoleLibrary), in Figure 7.27, page 79, the multiplicity on end of RoleDefinition (of association to Characteristic) is not shown. It should be shown as (0..*).

Show multiplicity on association ends in four places

Add the missed visualization of multiplicity on the four association ends.

In sub-clause 7.1.9 (Activity), page 22, it says: "Conversely, all values can be traced back to their contributors. This is possible, because VDML is not representing the actual paths of each unit of production, but rather the statistical use of various Activities that contribute to results achieved over some period of time. That representative set of results includes some Activities that are only active for some units of production due to product features, operating exceptions, defects, repairs, sample testing, machine failures, and so on." The word "includes" (see above in bold) sounds strange to me. Because Activities are not included in a set of results. Is maybe a different verb meant or was it meant to say something different ?

Revise imprecise statement

Imprecise statement about Activity Value contributions revised.

In sub-clause 7.1.9 (Activity), page 20, it says: "A BusinessItem (...) may flow through a delegation to a sub-Collaboration, or be the input or output of a Collaboration." How is the following meant: "be the input or output of a Collaboration" ? Is that only saying in other words what is said with "may flow through a delegation to a sub-Collaboration"? Similar doubt regarding the immediate next sentence: "Flow of BusinessItems into and out of Activities as well as Collaborations is depicted by DeliverableFlows." The phrase of "as well as Collaborations" is a bit arguable. As known, DeliverableFlows do not connect Ports of Collaborations directly.

Revise unclear statements

Unclear statements about Business Items and Deliverable Flows revised.

The second and third paragraph of sub-clause 7.1.14 (Staff Collaborations), on page 26, are suggesting that VDML can be used to model transformation work, involved in transformation of the business that is also modeled. This is bit misleading and tends to overpromise.

Remove false expectations about modeling of actual transformation work

Rewrite sentences to remove false expectations about modeling of the actual transformation work

In sub-clause 7.1.13 (Scenarios and Contexts), page 25, right above Figure 7.5, it says: "Since Assignments can also be context dependent, the delegations of one Scenario can differ from those of another Scenario thus forming a different tree." But the phrase "Since Assignments can also be context dependent" is irrelevant here, because: delegations of one Scenario (i.e., sub-Collaborations in DelegationContext nodes in the Scenario tree) can be different from those of another Scenario anyway.

Give statement on Scenarios and context trees better meaning

Give statement on Scenarios and context trees better meaning, by removing some words.

In sub-clause 7.1.11 (Resources and Stores), page 22, it says: “The cumulative duration of these uses will determine the consumption of available resource time. This, along with the rate of production, will determine if the Pool of resources will always have resources available or will introduce some additional wait-time for assignment of a resource.”. This only talks about assigning a resource. But before it can be assigned, one may need to wait till it gets released. Can this be worked into the sentence, to make it better reflecting that also.

Make statement about resources complete

Make statement about the use of resources more complete, referring also to the concept of releasing of a resource.

Sub-clause 7.1.12 (Measures), page 22, says: “A Measure is applied to a Characteristic, such as weight of a part, to determine a Measurement that expresses the value of the Characteristic for a particular VDML model element.” And a bit further, on the same page: “VDML Characteristics reflect statistical Measurements per unit of production.”. In the light of Figure 7, this does not seem correct. Because VDML has MeasuredCharacterstic, referring to Characteristic in SMM. Strictly spoken there is no "VDML Characteristic".

Use MeasuredCharacteristic instead of Characterstic in two sentences

Fix two sentences, by referring to MeasuredCharacteristic, instead of Characteristic.

Point 3 in sub-clause 7.1.15 (Model Integration), and the last paragraph of that sub-clause, both on page 27, contain incorrect and confusing statements. It talks about "direct and indirect delegations" and "non-delegation inputs and outputs". In the context of the meta-model, it is unclear what these mean. It also says: "A branch of a delegation tree in one Scenario may then be assigned as a delegation from an Activity in the other Scenario.” The word “assigned” is mis-used here, as, in the VDML specification this term is reserved for assignment of a role. It is also unclear, with the actual meta-model in mind, what the sentence actually means.

Making explanation more clear and consistent with the meta-model

Making explanation more clear and consistent with the meta-model.

Sub-clause 7.2.1.2.3 (Assignment Class), page 36, has a constraint that says, page 37: “A Role MUST NOT be assigned to more than one Participant that is a Collaboration, unless the additional Assignments are context-based, i.e., contained by DelegationContext”. This constraint has several problems. It ignores the fact that participations can be indirect, through a chain of assignments (“roles of roles”). It also ignores the fact that context-based assignments are not only possible with delegation contexts (i.e., children in the context tree), but also with scenarios (the top of context tree). Furthermore, this constraint was written with Position roles in mind, but leaves too much room for invalid situations for other types of roles.

Replace constraint

Replace the problematic constraint by three other constraints.

Sub-clause 7.1.13 (Scenarios and Contexts), page 23, says: “When the Activity of a Collaboration delegates to another Collaboration in order to engage a shared Capability, that particular use of the sub-Collaboration may be one of many.” It is confusing to talk about “the” Activity of a Collaboration. A Collaboration may contain any number of Activities.

Withdraw false suggestion from the text about Activities

Fix the text, so that it no longer attaches false connotation to Activities.

Clause 8 (Notation) is not mentioned in sub-clause 6.3 (Guide to the Specification).

No change needed

This missing information was actually added in the formal VDML 1.0 specifiation, though it was missing in the Word version that was delivered by the submission team and that was the basis for adoption. We just overlooked that. So this issue is actually no issue.

Add VDML logo to the VDML specification

Add VDML logo

The VDML logo is added to the front page of the VDML specification.

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".