Issue 14775: Throughout Spec [Specification]: Define explicit separation of "modeling" vs "implementation" attributes (bpmn2-rtf)
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary: This is number 1 of 12 issues submitted by Bruce Silver:

Define explicit separation of "modeling" vs "implementation" attributes.  The current "core" vs "extended" is nowhere close to this, since modeling needs much of the extended set.  Modeling is about orchestration of "abstract" activities, abstract meaning they have a name (label), task type, perhaps markers like loop/MI/adhoc, and unique id of course, but not implementation properties.  Abstract sequence flow has name, source and target refs; if conditional, the label is sufficient - you don't require a conditionExpression.  Message flow or message event does not require a message attribute, timer event does not require TimeDate or TimeCycle (please rename it to Duration) attribute, error event does not require an error code attribute, etc.  Those are for implementation; in modeling it's the diagram that counts, i.e. the label. 

Resolution: 
Revised Text: 
Actions taken:
November 23, 2009: received issue
Discussion: 
The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF.
Disposition: Deferred
End of Annotations:=====
s is issue # 14775

[OMG 14775] Beta 1 Spec: Throughout Spec [Specification]: Define explicit separation of "modeling" vs "implementation" attributes

##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-298
##Original Info: (Severity: Significant - Nature: Enhancement)

This is number 1 of 12 issues submitted by Bruce Silver:

Define explicit separation of "modeling" vs "implementation" attributes.  The current "core" vs "extended" is nowhere close to this, since modeling needs much of the extended set.  Modeling is about orchestration of "abstract" activities, abstract meaning they have a name (label), task type, perhaps markers like loop/MI/adhoc, and unique id of course, but not implementation properties.  Abstract sequence flow has name, source and target refs; if conditional, the label is sufficient - you don't require a conditionExpression.  Message flow or message event does not require a message attribute, timer event does not require TimeDate or TimeCycle (please rename it to Duration) attribute, error event does not require an error code attribute, etc.  Those are for implementation; in modeling it's the diagram that counts, i.e. the label.