-
Notifications
You must be signed in to change notification settings - Fork 1
/
ModiscoWorkflow.history
374 lines (374 loc) · 32.5 KB
/
ModiscoWorkflow.history
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
<?xml version="1.0" encoding="ASCII"?>
<history:History xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:history="http://atlanmod.fr/collaboro/history" xmlns:notation="http://atlanmod.fr/collaboro/notation" language="transport">
<users id="hugo" votes="//@histories.0/@versions.0/@proposals.0/@sols.0/@votes.0 //@histories.0/@versions.0/@proposals.0/@votes.0 //@histories.0/@versions.0/@proposals.2/@comments.0/@votes.1 //@histories.0/@versions.0/@proposals.3/@comments.0/@votes.0 //@histories.0/@versions.0/@proposals.2/@votes.3 //@histories.0/@versions.0/@proposals.2/@sols.0/@votes.1 //@histories.0/@versions.0/@proposals.3/@votes.2 //@histories.0/@versions.0/@proposals.6/@votes.3 //@histories.0/@versions.1/@proposals.0/@votes.0 //@histories.0/@versions.1/@proposals.0/@sols.0/@votes.0 //@histories.0/@versions.1/@proposals.1/@votes.1 //@histories.0/@versions.1/@proposals.2/@votes.2 //@histories.0/@versions.1/@proposals.3/@votes.3 //@histories.0/@versions.1/@proposals.4/@comments.0/@votes.2 //@histories.0/@versions.1/@proposals.4/@comments.1/@votes.1 //@histories.0/@versions.1/@proposals.4/@comments.2/@votes.1 //@histories.0/@versions.1/@proposals.0/@sols.0/@comments.1/@votes.3 //@histories.0/@versions.1/@proposals.4/@sols.0/@votes.1 //@histories.0/@versions.1/@proposals.5/@sols.0/@votes.1 //@histories.0/@versions.1/@proposals.5/@votes.0 //@histories.0/@versions.1/@proposals.4/@votes.2 //@histories.0/@versions.0/@proposals.3/@sols.0/@votes.1 //@histories.0/@versions.0/@proposals.6/@sols.0/@votes.0" collaborations="//@histories.0/@versions.0/@proposals.0/@sols.0/@comments.0 //@histories.0/@versions.0/@proposals.1 //@histories.0/@versions.0/@proposals.1/@comments.0 //@histories.0/@versions.1/@proposals.0/@sols.0/@comments.0 //@histories.0/@versions.1/@proposals.2/@comments.1 //@histories.0/@versions.1/@proposals.3/@comments.2"/>
<users id="salva" votes="//@histories.0/@versions.0/@proposals.1/@votes.0 //@histories.0/@versions.0/@proposals.2/@votes.2 //@histories.0/@versions.0/@proposals.3/@votes.0 //@histories.0/@versions.0/@proposals.2/@comments.0/@votes.2 //@histories.0/@versions.0/@proposals.6/@votes.1 //@histories.0/@versions.0/@proposals.2/@sols.0/@votes.2 //@histories.0/@versions.0/@proposals.3/@comments.0/@votes.3 //@histories.0/@versions.1/@proposals.3/@votes.1 //@histories.0/@versions.1/@proposals.4/@votes.0 //@histories.0/@versions.1/@proposals.3/@comments.0/@votes.1 //@histories.0/@versions.1/@proposals.4/@comments.2/@votes.2 //@histories.0/@versions.1/@proposals.4/@comments.1/@votes.2 //@histories.0/@versions.1/@proposals.0/@votes.3 //@histories.0/@versions.1/@proposals.0/@sols.0/@votes.2 //@histories.0/@versions.1/@proposals.4/@sols.0/@votes.2 //@histories.0/@versions.1/@proposals.5/@sols.0/@votes.2 //@histories.0/@versions.1/@proposals.5/@votes.2 //@histories.0/@versions.0/@proposals.3/@sols.0/@votes.3 //@histories.0/@versions.0/@proposals.6/@sols.0/@votes.2" collaborations="//@histories.0/@versions.0/@proposals.5 //@histories.0/@versions.1/@proposals.2 //@histories.0/@versions.1/@proposals.0/@sols.0/@comments.1 //@histories.0/@versions.1/@proposals.3/@comments.1 //@histories.0/@versions.1/@proposals.4/@comments.0 //@histories.0/@versions.1/@proposals.6"/>
<users id="valerio" votes="//@histories.0/@versions.0/@proposals.1/@votes.2 //@histories.0/@versions.0/@proposals.2/@votes.0 //@histories.0/@versions.0/@proposals.5/@votes.0 //@histories.0/@versions.0/@proposals.5/@comments.0/@votes.0 //@histories.0/@versions.0/@proposals.3/@comments.0/@votes.1 //@histories.0/@versions.0/@proposals.2/@sols.0/@votes.3 //@histories.0/@versions.0/@proposals.2/@comments.0/@votes.3 //@histories.0/@versions.0/@proposals.3/@votes.3 //@histories.0/@versions.1/@proposals.2/@votes.0 //@histories.0/@versions.1/@proposals.0/@sols.0/@comments.1/@votes.1 //@histories.0/@versions.1/@proposals.4/@comments.2/@votes.3 //@histories.0/@versions.1/@proposals.5/@comments.0/@votes.0 //@histories.0/@versions.1/@proposals.0/@votes.2 //@histories.0/@versions.1/@proposals.6/@votes.0 //@histories.0/@versions.1/@proposals.0/@sols.0/@votes.3 //@histories.0/@versions.1/@proposals.4/@sols.0/@votes.3 //@histories.0/@versions.1/@proposals.5/@votes.3 //@histories.0/@versions.1/@proposals.5/@sols.0/@votes.3 //@histories.0/@versions.1/@proposals.4/@votes.3 //@histories.0/@versions.1/@proposals.4/@comments.0/@votes.3 //@histories.0/@versions.0/@proposals.3/@sols.0/@votes.2 //@histories.0/@versions.0/@proposals.6/@sols.0/@votes.3" collaborations="//@histories.0/@versions.0/@proposals.6 //@histories.0/@versions.1/@proposals.3"/>
<users id="elena" votes="//@histories.0/@versions.0/@proposals.1/@votes.3 //@histories.0/@versions.0/@proposals.0/@votes.1 //@histories.0/@versions.0/@proposals.0/@sols.0/@votes.1 //@histories.0/@versions.0/@proposals.0/@sols.0/@comments.0/@votes.0 //@histories.0/@versions.0/@proposals.2/@votes.1 //@histories.0/@versions.0/@proposals.2/@sols.0/@votes.0 //@histories.0/@versions.0/@proposals.3/@comments.0/@votes.2 //@histories.0/@versions.0/@proposals.6/@votes.2 //@histories.0/@versions.0/@proposals.4/@votes.0 //@histories.0/@versions.1/@proposals.0/@votes.1 //@histories.0/@versions.1/@proposals.0/@sols.0/@votes.1 //@histories.0/@versions.1/@proposals.1/@votes.0 //@histories.0/@versions.1/@proposals.0/@sols.0/@comments.0/@votes.0 //@histories.0/@versions.1/@proposals.4/@comments.0/@votes.1 //@histories.0/@versions.1/@proposals.3/@comments.1/@votes.1 //@histories.0/@versions.1/@proposals.3/@comments.0/@votes.0 //@histories.0/@versions.1/@proposals.3/@votes.2 //@histories.0/@versions.1/@proposals.0/@sols.0/@comments.1/@votes.2 //@histories.0/@versions.1/@proposals.4/@votes.1 //@histories.0/@versions.1/@proposals.4/@sols.0/@votes.0 //@histories.0/@versions.1/@proposals.5/@sols.0/@votes.0 //@histories.0/@versions.0/@proposals.3/@sols.0/@votes.0 //@histories.0/@versions.0/@proposals.6/@sols.0/@votes.1" collaborations="//@histories.0/@versions.0/@proposals.2/@comments.0 //@histories.0/@versions.0/@proposals.3 //@histories.0/@versions.0/@proposals.2/@sols.1 //@histories.0/@versions.1/@proposals.5 //@histories.0/@versions.1/@proposals.4/@comments.1 //@histories.0/@versions.1/@proposals.4/@comments.2 //@histories.0/@versions.1/@proposals.5/@comments.1"/>
<users id="javi" votes="//@histories.0/@versions.0/@proposals.1/@votes.1 //@histories.0/@versions.0/@proposals.2/@comments.0/@votes.0 //@histories.0/@versions.0/@proposals.1/@comments.0/@votes.0 //@histories.0/@versions.0/@proposals.5/@votes.1 //@histories.0/@versions.0/@proposals.6/@votes.0 //@histories.0/@versions.0/@proposals.3/@votes.1 //@histories.0/@versions.1/@proposals.2/@votes.1 //@histories.0/@versions.1/@proposals.0/@sols.0/@comments.1/@votes.0 //@histories.0/@versions.1/@proposals.3/@votes.0 //@histories.0/@versions.1/@proposals.4/@comments.0/@votes.0 //@histories.0/@versions.1/@proposals.3/@comments.1/@votes.0 //@histories.0/@versions.1/@proposals.4/@comments.2/@votes.0 //@histories.0/@versions.1/@proposals.4/@comments.1/@votes.0 //@histories.0/@versions.1/@proposals.5/@votes.1" collaborations="//@histories.0/@versions.0/@proposals.0 //@histories.0/@versions.0/@proposals.0/@sols.0 //@histories.0/@versions.0/@proposals.2 //@histories.0/@versions.0/@proposals.2/@sols.0 //@histories.0/@versions.0/@proposals.3/@comments.0 //@histories.0/@versions.0/@proposals.4 //@histories.0/@versions.0/@proposals.5/@comments.0 //@histories.0/@versions.1/@proposals.0 //@histories.0/@versions.1/@proposals.0/@sols.0 //@histories.0/@versions.1/@proposals.1 //@histories.0/@versions.1/@proposals.2/@comments.0 //@histories.0/@versions.1/@proposals.3/@comments.0 //@histories.0/@versions.1/@proposals.4 //@histories.0/@versions.1/@proposals.5/@comments.0 //@histories.0/@versions.1/@proposals.6/@comments.0 //@histories.0/@versions.1/@proposals.6/@sols.0 //@histories.0/@versions.1/@proposals.6/@comments.1 //@histories.0/@versions.0/@proposals.6/@sols.0 //@histories.0/@versions.0/@proposals.3/@sols.0 //@histories.0/@versions.1/@proposals.4/@sols.0 //@histories.0/@versions.1/@proposals.5/@sols.0"/>
<histories>
<versions id="0.1">
<proposals id="n0" rationale="giving a textual syntax" proposedBy="//@users.4">
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.3"/>
<sols id="n1" rationale="The simplest one is the one based on keywords and blocks" proposedBy="//@users.4">
<comments id="n3" rationale="OK for a first proposition.
I guess the syntax will have to be upgraded later." proposedBy="//@users.0">
<votes agreement="true" user="//@users.3"/>
</comments>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.3"/>
<changes xsi:type="history:Add">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//Workflow"/>
</referredElement>
<target xsi:type="history:ConcreteSyntaxElement">
<element xsi:type="notation:Composite" href="ModiscoWorkflow.notation#//@elements.0"/>
</target>
</changes>
<changes xsi:type="history:Add">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//Work"/>
</referredElement>
<target xsi:type="history:ConcreteSyntaxElement">
<element xsi:type="notation:Composite" href="ModiscoWorkflow.notation#//@elements.1"/>
</target>
</changes>
<changes xsi:type="history:Add">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//WorkParameter"/>
</referredElement>
<target xsi:type="history:ConcreteSyntaxElement">
<element xsi:type="notation:Composite" href="ModiscoWorkflow.notation#//@elements.2"/>
</target>
</changes>
</sols>
</proposals>
<proposals id="n12" rationale="I suggest to delete Proposals n2 & n4, and start from here a more focus discussion.
Your vote please?

IMHO, we should re-focus on the real objective of this DSL: allow users to easily design MDE workflows.
We are not going to redefine here a new version of BPMN or UML Activity Diagram...

" proposedBy="//@users.0" accepted="true">
<comments id="n18" rationale="Summary of past discussions:

 - How to name the base element of a Workflow instead of "Work"?
		"Task", "Action", etc
- Which granularity level do we need to address?
		"Process", "Activity", etc

" proposedBy="//@users.0">
<votes agreement="true" user="//@users.4"/>
</comments>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.2"/>
<votes agreement="true" user="//@users.3"/>
</proposals>
<proposals id="n13" rationale="I would remove the "ExportInfos" metaclass, in its current version, it is simply useless" proposedBy="//@users.4" selected="//@histories.0/@versions.0/@proposals.2/@sols.0" accepted="true">
<comments id="n14" rationale="Note that if this metaclass is removed, the generalization between "Workflow" and "ExportInfos" should also be removed." proposedBy="//@users.3">
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.2"/>
</comments>
<votes agreement="true" user="//@users.2"/>
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.0"/>
<sols id="n16" rationale="Removing "ExportInfos" metaclasss " proposedBy="//@users.4">
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.2"/>
<changes xsi:type="history:Delete">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#/"/>
</referredElement>
<target xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//ExportInfos"/>
</target>
</changes>
</sols>
<sols id="n23" rationale="Updating the "Workflow" metaclass in order to remove the inheritance relationship with the recently removed metaclass "ExportInfos".

@javi: I'm not sure how I should indicate this solution." proposedBy="//@users.3">
<changes xsi:type="history:Update">
<target xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//Workflow"/>
</target>
</changes>
</sols>
</proposals>
<proposals id="n15" rationale="Most attributes of all classes have lower multiplicity equal to 0. If the attributes are mandatory - I think most of them are - the lower multiplicity should be equal to 1. So I suggest replacing the minimum multiplicity 0 to 1. " proposedBy="//@users.3" selected="//@histories.0/@versions.0/@proposals.3/@sols.0" accepted="true">
<comments id="n17" rationale="I agree except for the "description" attribute in "WorkParameter", do we need to force to specify it?" proposedBy="//@users.4">
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.2"/>
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.1"/>
</comments>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.2"/>
<sols id="n40" rationale="Fixing cardinalities" proposedBy="//@users.4">
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.2"/>
<votes agreement="true" user="//@users.1"/>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="name" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="type" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="index" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="name" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="type" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EReference" name="direction" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="required" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="value" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="value" lowerBound="1" upperBound="-11"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="value" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="value" lowerBound="1"/>
</target>
</changes>
<changes xsi:type="history:Update">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EPackage" href="ModiscoWorkflow.ecore#"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="key" lowerBound="1"/>
</target>
</changes>
</sols>
</proposals>
<proposals id="n19" rationale="From the comment on proposal n12:

Maybe we can think of a main element called "Workflow" which can be composed of simple/composite elements, which could be could task/activity respectively.

Anyway, I'm afraid of over-complicating the language. Actually, the support for simple/composite elements is included with the work/workflow metaclasses
" proposedBy="//@users.4">
<votes agreement="true" user="//@users.3"/>
</proposals>
<proposals id="n20" rationale="We could need fork and joins. The can be introduced as a subclass of Element." proposedBy="//@users.1">
<comments id="n22" rationale="I really like this feature but I think that it would overcomplicate the language since we would need a "condition language" to set when forking and merging.

To limite the collaboration and discussion, I've voted against it" proposedBy="//@users.4">
<votes agreement="true" user="//@users.2"/>
</comments>
<votes agreement="true" user="//@users.2"/>
<votes user="//@users.4"/>
</proposals>
<proposals id="n21" rationale="I think each 'Work' should have a reference to the previous/next 'Element' preceding/following it in the workflow" proposedBy="//@users.2" selected="//@histories.0/@versions.0/@proposals.6/@sols.0" accepted="true">
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
<sols id="n26" proposedBy="//@users.4">
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.2"/>
<changes xsi:type="history:Add">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//Work"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EReference" name="previous"/>
</target>
</changes>
<changes xsi:type="history:Add">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//Work"/>
</referredElement>
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EReference" name="next"/>
</target>
</changes>
</sols>
</proposals>
</versions>
<versions id="0.2" previous="//@histories.0/@versions.0">
<proposals id="n0" rationale="giving a textual syntax" proposedBy="//@users.4" selected="//@histories.0/@versions.1/@proposals.0/@sols.0" accepted="true">
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.2"/>
<votes agreement="true" user="//@users.1"/>
<sols id="n43" rationale="The simplest one is the one based on keywords and blocks

I've modified the syntax of "Workparameter" according to comment n23" proposedBy="//@users.4">
<comments id="n3" rationale="OK for a first proposition.
I guess the syntax will have to be upgraded later." proposedBy="//@users.0">
<votes agreement="true" user="//@users.3"/>
</comments>
<comments id="n23" rationale="For work parameter, I will add more information, notably the direction of the parameter preceeding its name: e.g., in param p1, out param p2, inout param p3" proposedBy="//@users.1" included="true">
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.2"/>
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
</comments>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.2"/>
<changes xsi:type="history:Add">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//Workflow"/>
</referredElement>
<target xsi:type="history:ConcreteSyntaxElement">
<element xsi:type="notation:Composite" href="ModiscoWorkflow.notation#//@elements.0"/>
</target>
</changes>
<changes xsi:type="history:Add">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//Work"/>
</referredElement>
<target xsi:type="history:ConcreteSyntaxElement">
<element xsi:type="notation:Composite" href="ModiscoWorkflow.notation#//@elements.1"/>
</target>
</changes>
<changes xsi:type="history:Add">
<referredElement xsi:type="history:ExistingAbstractSyntaxElement">
<element xsi:type="ecore:EClass" href="ModiscoWorkflow.ecore#//WorkParameter"/>
</referredElement>
<target xsi:type="history:ConcreteSyntaxElement">
<element xsi:type="notation:Composite" href="ModiscoWorkflow.notation#//@elements.2"/>
</target>
</changes>
</sols>
</proposals>
<proposals id="n19" rationale="From the comment on proposal n12:

Maybe we can think of a main element called "Workflow" which can be composed of simple/composite elements, which could be could task/activity respectively.

Anyway, I'm afraid of over-complicating the language. Actually, the support for simple/composite elements is included with the work/workflow metaclasses
" proposedBy="//@users.4">
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
</proposals>
<proposals id="n20" rationale="We could need fork and joins. The can be introduced as a subclass of Element." proposedBy="//@users.1">
<comments id="n22" rationale="I really like this feature but I think that it would overcomplicate the language since we would need a "condition language" to set when forking and merging.

To limite the collaboration and discussion, I've voted against it" proposedBy="//@users.4">
<votes agreement="true"/>
</comments>
<comments id="n24" proposedBy="//@users.0"/>
<votes agreement="true" user="//@users.2"/>
<votes user="//@users.4"/>
<votes user="//@users.0" comment="//@histories.0/@versions.1/@proposals.2/@comments.1"/>
</proposals>
<proposals id="n24" rationale="In my opinion, "workflow", "work" and "workParameter" should appear with 3 different colors in the concrete syntax" proposedBy="//@users.2">
<comments id="n24" rationale="I would prefer to have one single color for each "keyword" in the language (as normal GPLs)." proposedBy="//@users.4">
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.1"/>
</comments>
<comments id="n24" rationale="As Javi, I prefer to have a single color for all the keywords" proposedBy="//@users.1">
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.3"/>
</comments>
<comments id="n25" proposedBy="//@users.0"/>
<votes user="//@users.4" comment="//@histories.0/@versions.1/@proposals.3/@comments.0"/>
<votes user="//@users.1" comment="//@histories.0/@versions.1/@proposals.3/@comments.1"/>
<votes user="//@users.3"/>
<votes user="//@users.0" comment="//@histories.0/@versions.1/@proposals.3/@comments.2"/>
</proposals>
<proposals id="n24" rationale="Color: red for keywords and black for the rest of elements.

This proposal has been incorportaed into the proposal n0. Please vote the n0 proposal for final agreement." proposedBy="//@users.4" selected="//@histories.0/@versions.1/@proposals.4/@sols.0" accepted="true">
<comments id="n24" rationale="The yellow color is not very easy to see in the screen. I would suggest black for the actual values" proposedBy="//@users.1" included="true">
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.2"/>
</comments>
<comments id="n26" rationale="Then, maybe the references should also appear in black instead of blue." proposedBy="//@users.3">
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.1"/>
</comments>
<comments id="n27" rationale="If comment n24 from salva is applied, I suggest to use red or purple instead of green for the keywords (because green and black may not be so obvious to distinguish)." proposedBy="//@users.3">
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.2"/>
</comments>
<votes user="//@users.1" comment="//@histories.0/@versions.1/@proposals.4/@comments.0"/>
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.2"/>
<sols id="n41" rationale="The syntax proposed by n0 has been updated" proposedBy="//@users.4">
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.2"/>
</sols>
</proposals>
<proposals id="n25" rationale="I think the concrete syntax of "Work" should include the information about the previous and next works.

I suggest a concrete syntax like: work <name> from <previous> to <next> <parameters>" proposedBy="//@users.3" selected="//@histories.0/@versions.1/@proposals.5/@sols.0" accepted="true">
<comments id="n24" rationale="I agree with the proposal, it would allow us to define work in any order. However, the problem that appears is: what happens if two (o more) "Works" have the same previous "Work"? We are creating forks/merges, which was a proposal rejected by the community.

Maybe the incorporation of previous/next references was not totally a good idea. Anyway, the solution could be to restrict the value of previous/next references in such a way that forks/merges cannot appear. The definition of this restriction is out of the scope of Collaboro :( " proposedBy="//@users.4">
<votes agreement="true" user="//@users.2"/>
</comments>
<comments id="n24" rationale="Then, I think the simplest solution is to remove the references previous/next from "Work". I guess the order of works is already known by its attribute "index"." proposedBy="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.4"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.2"/>
<sols id="n42" rationale="The syntax proposed by n0 has been updated" proposedBy="//@users.4">
<votes agreement="true" user="//@users.3"/>
<votes agreement="true" user="//@users.0"/>
<votes agreement="true" user="//@users.1"/>
<votes agreement="true" user="//@users.2"/>
</sols>
</proposals>
<proposals id="n29" rationale="For the Work element I propose to add two boolean attributes to mark is a given work constitutes the initial, the final or a middle work of the workflow." proposedBy="//@users.1">
<comments id="n24" rationale="I've proposed the solution but I'm still thinking that everything would be easier if the order of works/workflow is established implictly by the way they are defined in the textual definition" proposedBy="//@users.4"/>
<comments id="n24" proposedBy="//@users.4"/>
<votes agreement="true" user="//@users.2"/>
<sols id="n28" rationale="Two boolean attributes could be added to specify if the work is initial/final" proposedBy="//@users.4">
<changes xsi:type="history:Add"/>
<changes xsi:type="history:Add">
<target xsi:type="history:NewAbstractSyntaxElement">
<element xsi:type="ecore:EAttribute" name="final"/>
</target>
</changes>
</sols>
</proposals>
</versions>
</histories>
</history:History>