Re: ebBP 2/23/2005: Early Notice of Pre-Committee Draft OASIS ebXMLBPSS Tech Spec (ebBP!)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>Yano: Monica,
>
>Thank you for the notification of pre-Committee Draft.
>My comments are below.
>
mm1: We very much appreciate your comments.

>---
>* Comment: In XML fragments through the spec, nameID attribute
>values should start with a letter, not a digit, because of the 
>xsd:ID type definition.
>
mm1: Examples will be updated to conform to the schema in wd 11.

>* Comment: line 404:
>"A Business Collaboration is a set of Business Transactions"
>should be "a set of Business Activities executing Business Transactions".
>IMO, the distinction between Business Transaction and Business Transaction
>Activity is a critical point to understand BPSS.
>
mm1: Done.

>* Comment: Appendix A should conform to the BPSS 2.0 schema.
>
mm1: Part of harmonization process-examples and tech spec to schema.

>* Comment: Section 4.6.4: It is not clear to me what are
>specificationVersion and instanceVersion. My guess is that
>specificationVersion is the version of BPSS (that is, it will be 2.0)
>and instanceVersion is the version of the BPSS instance identified
>by the uuid attribute.  If that guess is right, line 730 should be
>"Versioning by specification schema".
>  
>
mm1: Will address this further in subsequent email as we had long 
discussions on this and I would like to review the historical notes 
before answering. Log as comment.

>* Comment: line 1118: mimeType="XML" should be 
>mimeType="application/xml". (see RFC 3023)
>  
>
mm1: Done.

>* Comment: line 1118-1120: This Attachment element instance
>lacks a Specification element mandatory by the schema.
>Suggestion: Remove Specification from Attachment in the schema
>because the referenced BusinessDocument by Attachment has a
>Specification. Also, the location attribute of the Specification 
>element should be optional because some types of attachment such
>like images don't have the location of specification.
>  
>
mm1: I have to review this further to see if this is a question for the 
harmonization between the examples and the schema or a schema issue. 
Stay tuned. Log as comment.

>* Comment: line 1183: "The is no limit ..." should be
>"There is no limit ..."
>  
>
mm1: Done.

>* Comment: line 1207: "This examples shows ..." should be
>"This example shows ..."
>  
>
mm1: Done.

>* Comment: line 1435: There must be one more Performs element
>because BTA has at least two Performs elements according to the
>schema. (Or, the schema should be changed so that minOccurs of
>Performs in BusinessTransactionActivityType should be "1".)
>  
>
mm1: I have to review this further to see if this is a question for the 
harmonization between the examples and the schema or a schema issue. 
Stay tuned. Log as comment.

>* Comment: line 1436: TimeToPerform element should be placed
>before Performs elements according to the schema.
>  
>
mm1: Schema-example harmonization. Log as comment.

>* Comment: line 1229: TimeToPerform element should be placed
>before Performs elements according to the schema.
>  
>
mm1: Schema-example harmonization. Log as comment.

>* Comment: line 1476: "An XOR a fork means ..." should be
>"An XOR fork means ..."
>  
>
mm1: Done.

>* Comment: line 1480: "Several path are ..." should be 
>"Several paths are ..."
>  
>
mm1: Done.

>* Comment: line 1488: "A fork has a timeToPerform element"
>should be "A fork has a TimeToPerform element". (The element name
>starts with 'T', not 't'.)
>  
>
mm1: Done.

>* Comment: line 1502: "timeToPerform attribute" should be
>"TimeToPerform element".
>  
>
mm1: Done. Thanks for the catch.

>* Comment: line 1504: In the table, the comment of OR-Fork
>and waitForAll="false" Join says "The duration of the fork
>TimeToPerform SHALL NOT be null." This restriction should be 
>relaxed. (Please consider the case that one path in a Fork-Join
>block is a normal sequence and another path is optional. In this
>case, we don't need TimeToPerform timeout to reach the Join.)
>  
>
mm1: Log as comment for discussion.

>* Comment: line 1532-1533: Which expression language is used here?
>  
>
mm1: I assume you mean the pseudo example here. It may need 
harmonization with schema and technical specification. Can you verify 
the section you are specifying as we have been making changes and I'd 
like to make sure I can associate your comment to the proper 
text/example. Log as comment.

=================================================
<variable name = “original.PO” 
expression=”document($order.request,’/message/order/@orderID’)”/>

<variable name = “invoice.PO” 
expression=”document($invoice.request,’/message/order/@orderID’)”/>

A transition condition can be created:

“$original.PO = $invoice.PO”
=================================================

>* Comment: line 1569: There is not Section 6.4 in the spec.
>Examples of timing redefinition should be provided here or in 
>another section.
>  
>
mm1: We have since added a note about this in the same section (Section 
4.6.8.1):

In this version, the condition expression and variable functions allow 
assignment of the TimeToPerform value through the process lifecycle to 
enable late binding. The TimetoPerform element MAY specify a duration 
and a type (for example, the value MAY be specified at design time). 
More requirements will be gathered to further understand the definition, 
use and other scenarios where variables may apply.

>* Comment: Schema: The TimeToPerform element should have a reference
>to a Variable, not the Variable element, for late binding.
>  
>
mm1: Log as comment for discussion.

>* Comment: line 1625-1626, 1630-1631, 1645-1646: ToLink
>elements don't conform to the schema. These examples are intended
>to use guards in ToLink element, however conditionGuard attribute
>is allowed only in FromLink element according to the schema.
>Also, the ToLink elements of line 1645-1646 have expression
>attribute, while a condition expression have to be expressed as
>an element.
>
mm1: Schema-example harmonization. Log as comment.

>* Comment: line 2129: "IsIntelligibleCheckRequired" should
>be "isIntelligibleCheckRequired" (starts with lower case 'i') like 
>line 2132.
>
mm1: Done.

>* Comment: line 2145: "IsAuthorizationRequired" should be
>"isAuthorizationRequired" (starts with lower case 'i').
>  
>
mm1: Done.

>* Comment: line 2155: "IsNonRepudiationRequired" should be
>"isNonRepudiationRequired" (starts with lower case 'i').
>  
>
mm1: Done.

>* Comment: line 2181: "An expression whose evaluation results
>in TRUE or FALSE." should be "A parameter that takes the value 
>true or false." because isPositiveResponse is a boolean attribute.
>
mm1: Done.

>* Comment: line 2249-2250: "defined as the name or ID of a 
>document envelope" should be "defined as the nameID of a document
>envelope" as described in line 1564-1565.
>  
>
mm1: Done. We had already corrected this in the schema but didn't catch 
this update. Thanks.

>* Comment: line 2261, 2265-2266: Attribute names "Name" and "NameID"
>should be "name" and "nameID" respectively, according to the schema.
>  
>
mm1: Done.

>* Comment: line 2829: "BSIMAY" should be "BSI MAY".
>  
>
mm1: Done.

>* Comment: line 2903: Please correct my name.  "Yeisuke" should be
>"Keisuke" (the first letter is 'K', not 'Y').
>
>  
>
mm1: Done.

>---
>
>Thanks,
>
>Yano K.
>  
>