bpel4people message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Dieter's Analysis of Mark Ford's PRD 2 Comments
- From: Dave Ings <ings@ca.ibm.com>
- To: bpel4people@lists.oasis-open.org
- Date: Tue, 30 Mar 2010 16:20:13 -0400
As per my 3/31 agenda email, here is Dieter's analysis of Mark's comments.
Sincere thanks to Dieter for volunteering to do this analysis on behalf of the TC. :-)
Dieter is of the view that only the first comment has the potential to trigger a third public review draft.
encoding QNames + Org Entity for HT Advanced query operations
http://lists.oasis-open.org/archives/bpel4people-comment/201003/msg00000.html
<dk>
(values in where-clauses - we need to add a clarification here)
(1) For QName instances, we should expect values of the form
(2) For tOrganizationalEntity instaces, we must split the complex value into separate simple-typed values and should expect them in the form
potentialOwner.user="userid"
potentialOwner.group="groupid"
potentialOwner.user IN ( "userid1", "userid2" , ..., "useridN" )
potentialOwner.group IN ( "groupid1", "groupid2", ..., "groupidN" )
which can be combined using AND / OR in the usual way.
</dk>
tUser in task results vs xsd:string
http://lists.oasis-open.org/archives/bpel4people-comment/201003/msg00001.html
<dk>
Ok
Change xsd:string to htt:tUser (2x)
Change xsd:tUser to htt:tUser
Also check the XML Schema (spec and separate file) !!!
</dk>
BP-141: Type of IDs not consistently defined
http://lists.oasis-open.org/archives/bpel4people-comment/201003/msg00002.html
<dk>
Ok - editing for BP-141 should have done this - change these two IDs as well
</dk>
Schema definition for Organizational Entities
http://lists.oasis-open.org/archives/bpel4people-comment/201003/msg00003.html
<dk>
Disagree - this comment is wrong and contradicts the resolution of BP-125
</dk>
minor editorial suggestions
http://lists.oasis-open.org/archives/bpel4people-comment/201003/msg00004.html
<dk>
(all editing; all ok for me except for the tStatus type change; see "==>" below)
470 In general sub tasks are human tasks, inheriting all attributes that a human task has, and each behaving
471 the way that a human task does.
- Are there tasks other than human tasks?
==> say "... are *regular* human tasks"
524: In a well-defined order using Routing Patterns (see Routing Patterns)
- Reference to Routing Patterns section needed.
==> ok
853 The attachedBy element indicates who added the attachment. It could be a user, not a group or a list of
854 users or groups.
- just write "htt:tUser" since "could be a user" implies that it could also be something also.
- same comment for line 891
==> ok
1074 <xsd:simpleType name="tStatus">
1075 <xsd:restriction base="xsd:string" />
1076 </xsd:simpleType>
- tStatus would be better defined as a union of xsd:string and tPredefinedStatus. My assumption is that an enum isn't used here to allow for extensions but the result is that tPredefinedStatus isn't referenced explicitly.
==> not sure - a union of string and enum is still a string, so this does not add any additional insights
1177: For routing tasks his attribute MUST be set to....
- "this", not "his"
==> ok
1125: Removing closing "/"
==> ok
1409: This optional attribute specifies the way how sub-tasks are instantiated
- remove "how"
==> ok
1528: double period
==> ok
1535: (this assignment could have with n potential owners)
-- remove "with" or rephrase
==> ok
1542: I would move this line up above the bullets. I got stuck on 1532-1536 trying to understand the difference between single and all and it would have been much clearer if the notion of separate sub-tasks was stated prior. same comment for Sequential
==> ok
1549: missing closing element
1584: missing closing element
==> ok (2x)
1628: manual | automatic should be blue
==> ok
1675: make bullet
==> ok
1764: reference to list of supported functions?
==> ok
2290 Start
- change to lowercase
==> ok
</dk>
task completion conditions
http://lists.oasis-open.org/archives/bpel4people-comment/201003/msg00005.html
<dk>
1676 (1670 in .doc) The sentence "Completion conditions of a task MUST use only time functions." came in with BP-103. It talks about top-level tasks as opposed to subtasks. Maybe we should add "top-level" here in order to clarify.
</dk>
missing part attribute in htd:to
http://lists.oasis-open.org/archives/bpel4people-comment/201003/msg00006.html
<dk>
(looks right to me)
1825 (in .doc): add part="NCName" attribute
</dk>
minor B4P edits
http://lists.oasis-open.org/archives/bpel4people-comment/201003/msg00007.html
<dk>
(editing only - all ok)
472 (470 in .doc): change ws-ht (!) reference to 3.5
473 (471 in .doc): change to two variants
480 (478 in .doc): "using variable" -> "using a variable"
</dk>
Regards, Dave Ings,
Emerging Software Standards
Email: ings@ca.ibm.com
Yahoo Messenger: dave_ings
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]