OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ebBP 3/27/2005: Comment re: documentSecurity (addl) [wd10/schema 2/22]


In two recent calls we discussed and accepted some minor changes related 
to documentSecurity. In a review of the patterns matrices, schema and 
the business signals (Between Dale, myself and Hima last week, and with 
a note from John Yunker), we identified some suggested updates. 
Reference: 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200503/msg00066.html.

==============================================================================================
Technical specification
Section 4.6.6.1 Key Semantics of a Business Transaction
[add before Table 1 in addition to quality group addition which is also 
herein]

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. 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).

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.  In the succeeding tables, some usage 
recommendations are made such as the use of an Acceptance 
Acknowledgement business signal. The accompanying XML schema for ebXML 
BPSS supports these recommendations. In some cases (i.e.. where a 
capability is optional and other alternate capabilities may be chosen by 
the parties),  the usage is to be specified by those parties. For 
example, isGuaranteedMessageDeliveryRequired has a default of 'false' 
although it is recommended.

Note: Obligation herein is described as a responsibility to provide 
accordant information, which differs from residual obligation 
(obligation to a subsequent action).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Schema

    * On all concrete patterns, specify documentSecurity or an
      appropriate subset. No change required for pattern matrices.
          o BusinessTransaction, Notification: Required.
          o InformationDistribution, RequestResponse, RequestConfirm,
            QueryResponse: Optional
    * On all concrete patterns, ensure quality attribute group or an
      appropriate subset apply.
          o Notification: Add non-repudiation on receipt.
          o RequestResponse: Need to add retryCount.

==============================================================================================
Open question: Do we specify an AA on an AA when minOccurs=0 or if not 
allowed or applicable? For example:

    * InformationDistribution: Not applicable.
    * RequestResponse: Not allowed explicitly.
    * RequestConfirm: Not allowed explicitly.

JOHN, if you could input here it would be greatly appreciated.






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]