ebBP 3/27/2005: Comment re: 'quality' attribute group (wd 10/schema2/22)

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

In Tuesday's call, we discussed the documentSecurity and quality 
attribute groups. I had sent an inquiry to the list 21 March 2005 about 
the latter as we had resolved our focus on documentSecurity.  Reference: 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200503/msg00070.html.

Quality group includes:

    * isIntelligibleCheckRequired
    * isNonRepudiationRequired
    * isNonRepudiationReceptRequired
    * timetoAcknowledgeAcceptance
    * timetoAcknowledgeReceipt
    * isAuthorizationRequired
    * retryCount

Discussion summary:

    * The operational semantics around use of the concrete BT patterns
      may place conditions on these attributes. For example, if a
      Receipt Acknowledgement signal is used, there would be a
      timeToAcknowledgeReceipt.
    * These attributes place requirements on the business document and
      attachments.
    * Our premise has been to encourage more user community feedback
      before inferring any other specific operational semantics on the
      matrices in relationship other exchange criteria. These criteria
      will likely be used by the process modeler in defining their
      shared collaboration.
    * Most of these are already inferred or specifically referenced in
      the matrices.

Proposed resolution:

    * No changes will be made to the BT patterns matrices.
    * No changes will be made to the XML schema (structural) although an
      annotation added to the quality group.
    * Add complementary text to the technical specification to support
      the annotation change.

====================================================================================
Schema
Annotation on quality group:
Change from:
- <#> <xsd:attributeGroup name="*quality*">
- <#> <xsd:annotation>
  <xsd:documentation>The attributeGroup related to quality of service 
attributes. Note: This attributeGroup was added in 
v2.0.</xsd:documentation>
  </xsd:annotation>

Change to:
- <#> <xsd:attributeGroup name="*quality*">
- <#> <xsd:annotation>
  <xsd:documentation>The attributeGroup related to quality of service 
attributes. These attributes relate to the BT patterns and the 
operational semantics surrounding their use. Note: This attributeGroup 
was added in v2.0.</xsd:documentation>
  </xsd:annotation>

Change from:
- <#> <xsd:attributeGroup name="*documentSecurity*">
- <#> <xsd:annotation>
  <xsd:documentation>The attributeGroup related to document security, 
quality of service attributes.</xsd:documentation>
  </xsd:annotation>

Change to:
- <#> <xsd:attributeGroup name="*documentSecurity*">
- <#> <xsd:annotation>
  <xsd:documentation>The attributeGroup related to document security, 
quality of service attributes. These attributes relate to the BT 
patterns and the operational semantics surrounding their use. 
</xsd:documentation>
  </xsd:annotation>
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Technical specification
Section 4.6.6.1 Key Semantics of a Business Transaction [before Table 1 
after the paragraph below]

Change from: The Business Transaction patterns are described in further 
detail in the succeeding matrices. Table 1 represents each pattern and 
their relationship to business signals and responses. The remaining  
matrices actually provide greater detail of the 6 concrete Business 
Transaction Patterns (excluding the extensible and conversion patterns 
available for use). These matrices provide relevant capabilities 
associated with the six concrete patterns, but do not enforce how 
trading partners use those capabilities. Obligation herein is described 
as a responsibility to provide accordant information, which differs from 
residual obligation (obligation to a subsequent action).

Change to:
The Business Transaction patterns are described in further detail in the 
succeeding matrices. Table 1 represents each pattern and their 
relationship to business signals and responses. The remaining  matrices 
actually provide greater detail of the 6 concrete Business Transaction 
Patterns (excluding the extensible and conversion patterns available for 
use). These matrices provide relevant capabilities associated with the 
six concrete patterns, but do not enforce how trading partners use those 
capabilities. For example, other quality of service related, operational 
semantics may be selected by the parties (such as 
isIntelligibleCheckRequired or retryCount). These are further described 
later in Section 4.  Obligation herein is described as a responsibility 
to provide accordant information, which differs from residual obligation 
(obligation to a subsequent action).

Section 4.6.6.3 Business Signals
Change from:

The type of Business Transaction specifies whether a Receipt 
Acknowledgement and/or an Acceptance Acknowledgement signal is required. 
Business transaction protocol signals are independent from lower 
protocol and transport signals such as reliable messaging.

Change to:

The type of Business Transaction specifies whether a Receipt 
Acknowledgement and/or an Acceptance Acknowledgement signal is required. 
Business transaction
protocol signals are independent from lower protocol and transport 
signals such as reliable messaging. The business signals are important 
for state alignment, and relate to the characteristics inherent in the 
BT patterns described earlier in Section 4.

Section 4.7 Core Business Transaction Semantics
Change from:
Each of the above characteristics of the concept that we call an ebXML 
Business Transaction semantics is discussed in detail below.

Change to:
Each of the above characteristics of the concept that we call an ebXML 
Business Transaction semantics is discussed in detail below. These 
characteristics are related to the BT patterns and supporting matrices 
referenced earlier in Section 4.6.6.1.