[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bpel4people] Dieter's Analysis of Mark Ford's PRD 2 Comments
In response to the first comment (encoding QNames + Org Entity for HT
Advanced query operations), I suggest the following clarification.
In section 7.1.2 Simple Query Operations, replace the first occurence of
the following paragraph (for the getMyTaskAbstracts operation):
The where clause is optional. If specified, it MUST reference exactly
one column using the following operators: equals (“=”), not equals
(“<>”), less than (“<”), greater than (“>”), less than or equals (“<=”),
and greater than or equals (“>=”), e.g., “Task.Priority = 1”).
with the following new paragraph:
The where clause is optional. If specified, it MUST reference exactly
one column using the following operators: equals (“=”), not equals
(“<>”), less than (“<”), greater than (“>”), less than or equals (“<=”),
greater than or equals (“>=”), and the IN operator for multi-valued
user/group elements of generic human roles. An example of a where clause
is “task.priority = 1”. A value of type xsd:QName MUST be specified as
string in the format "{namespaceURI}localName", e.g., "task.name =
'{http://example.com}ApproveClaim'". A comparison with a value of type
htt:tOrganizationalEntity MUST be performed using its user/group child
elements, e.g., "task.potentialOwner.user IN ( 'Joe', 'Fred' ) OR
task.potentialOwner.group = 'approvers'".
and the second occurence (for the getMyTaskDetails operation) with:
The where clause is optional. If specified, it MUST follow the same
rules described for the getMyTaskAbstracts operation.
In section 7.1.3 Advanced Query Operation, add the following paragraph to
the description column (for the query operation):
For data of type xsd:QName or htt:tOrganizationalEntity in a where
clause, see the description of the getMyTaskAbstracts operation in
section 7.1.2 Simple Query Operations.
Kind Regards
Dieter Koenig
Senior Technical Staff Member, WebSphere BPM Architecture, Standardization,
Integration Quality Assurance
IBM Software Group, Application and Integration Middleware Software
WSS Business Process Solutions
Phone: +49-7031-16-3426 IBM Deutschland (Embedded
image moved
to file:
pic21442.gif)
E-Mail: dieterkoenig@de.ibm.com Schönaicher Str. 220
71032 Böblingen
Germany
IBM Deutschland
Research &
Development
GmbH /
Vorsitzender des
Aufsichtsrats:
Martin Jetter
Geschäftsführung:
Dirk Wittkopp
Sitz der
Gesellschaft:
Böblingen /
Registergericht:
Amtsgericht
Stuttgart, HRB
243294
From: Dave Ings <ings@ca.ibm.com>
To: bpel4people@lists.oasis-open.org
Date: 30.03.2010 22:20
Subject: [bpel4people] Dieter's Analysis of Mark Ford's PRD 2 Comments
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
name="{http://example.com}ApproveClaim";
(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]
