[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 6/29/2005: Updated InformationDistribution,Notification Patterns and Performs (Roles)
We discussed Novelli's case today at length to decide the optimal
approach that will serve v2.0.1 and future versions.
Hers is a summary of the proposed changes including the schema and
technical specification. Please send any comments to the TC list at
your earliest convenience (or to Dale Moberg and myself). As we agreed
in quorate meeting yesterday, I will post this to the list through close
of business tomorrow, and then initiate a vote on these proposed changes
on Kavi.
Per chance, there is any impacts for email formatting, I've attached a
.txt file that includes the description and proposed changes. Thank you
and please comment before the vote is initiated.
=======
In the working draft r04 schema [1], the patterns Notification and
InformationDistribution have a Requesting Business Activity (summary of
work item [2]). The Performs requires two roles be defined. However, no
Responding Business Activity existed.
What this uncovered were some subtle distinctions:
* There are still Requesting and Responding roles and two partners.
Even, the Responding role that receives has work to do. Roles
should be able to bind regardless of pattern. Both roles should be
present regardless of pattern, and the binding should be role to role.
* There is a Responding Business Activity. However, in these two
cases, there is not a Responding Business Document.
Options considered:
1. Change Performs such as to add an attribute to indicate that the
corresponding Role is linked to the receiving side of the BT.
2. Add Responding Business Activity that is able to bind that Role
regardless if any Business Document is sent.
Additional discussion points raised Tuesday:
1. A business action still exists in the receipt and processing of the
Request.
2. The Responding role does exist.
3. The actions may be (somewhat) implicit.
4. Adding a RespondingBusinessActivity on these two patterns will
enable us to be more flexible (in a standardized way) to
handle greater complexity with status visibility, multiparty
collaboration and ComplexBTA in the future.
Open question:
1. Should the additional attributes be restricted as well?
Proposed changes overview:
Clarify that a Responding role and Responding Business Activity exist
irrespective of concrete pattern. Note, we may not be able to dictate
this for the Data Exchange given the agreement of the parties.
Specific proposed changes:
Schema [snippet only] r04
=====================
Changes proposed:
a. Add annotation description to Information Distribution and
Notification Patterns.
b. Add constrained Responding Business Activity on both.
Change from:
<xsd:element name="InformationDistribution"
substitutionGroup="BusinessTransactionHead">
<xsd:annotation>
<xsd:documentation>A concrete Business Transaction Pattern
where an informal exchange
occurs between parties. Typically no residual obligation
between parties applies. No
response applies. Note: This concrete pattern was added
in v2.0.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="BusinessTransactionBaseType">
<xsd:sequence>
<xsd:element name="RequestingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction
base="RequestingBusinessActivityType">
<xsd:sequence>
<xsd:element
ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element
ref="DocumentEnvelope"/>
<xsd:element
name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType"
minOccurs="0"/>
<xsd:element
name="ReceiptAcknowledgementException"
type="ReceiptAcknowledgementExceptionType" minOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType"
minOccurs="0" maxOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgementException"
type="AcceptanceAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
</xsd:sequence>
<xsd:attribute
name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute
name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute
name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute name="retryCount"
type="xsd:int"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Notification"
substitutionGroup="BusinessTransactionHead">
<xsd:annotation>
<xsd:documentation>A concrete Business Transaction Pattern
where there is a formal
information exchange between parties that may affect the
previous completion of a
Commercial or Business Transaction (of the
BusinessTransactionType). For example,
when the Notification pattern is used for the
Notification of Failure Business
Transaction, this involves a business message. Another
example of a business
notification is an Advance Ship Notice. Note: This
concrete pattern was added in
v2.0.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="BusinessTransactionBaseType">
<xsd:sequence>
<xsd:element name="RequestingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction
base="RequestingBusinessActivityType">
<xsd:sequence>
<xsd:element
ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element
ref="DocumentEnvelope"/>
<xsd:element
name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType"/>
<xsd:element
name="ReceiptAcknowledgementException"
type="ReceiptAcknowledgementExceptionType"/>
<xsd:element
name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType"
minOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgementException"
type="AcceptanceAcknowledgementExceptionType" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute
name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute
name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute
name="isNonRepudiationRequired" type="xsd:boolean"/>
<xsd:attribute
name="isNonRepudiationReceiptRequired" type="xsd:boolean"/>
<xsd:attribute
name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute
name="timeToAcknowledgeAcceptance" type="xsd:duration"/>
<xsd:attribute name="retryCount"
type="xsd:int"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
Change to: [snippet only] r05
<xsd:element name="InformationDistribution"
substitutionGroup="BusinessTransactionHead">
<xsd:annotation>
<xsd:documentation>A concrete Business Transaction Pattern
where an informal exchange
occurs between parties. Typically no residual obligation
between parties applies. No
Responding Business Document (response) applies. It is
important to note that in this pattern there is a Responding Business
Activity and corresponding Responding Role irrespective of the fact
there is not a Responding Business Document. That Responding role
receives and processes (in an abstract sense) the Request. The
Responding Business Activity binds the associate role to the business
action. Note: This concrete pattern was added in v2.0.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="BusinessTransactionBaseType">
<xsd:sequence>
<xsd:element name="RequestingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction
base="RequestingBusinessActivityType">
<xsd:sequence>
<xsd:element
ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element
ref="DocumentEnvelope"/>
<xsd:element
name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType"
minOccurs="0"/>
<xsd:element
name="ReceiptAcknowledgementException"
type="ReceiptAcknowledgementExceptionType" minOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType"
minOccurs="0" maxOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgementException"
type="AcceptanceAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
</xsd:sequence>
<xsd:attribute
name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute
name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute
name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute name="retryCount"
type="xsd:int"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="RespondingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction
base="RespondingBusinessActivityType">
<xsd:sequence>
<xsd:element
ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element
ref="DocumentEnvelope" minOccurs="0" maxOccurs="0"/>
<xsd:element
name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType"
minOccurs="0" maxOccurs="0"/>
<xsd:element
name="ReceiptAcknowledgementException"
type="ReceiptAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType"
minOccurs="0" maxOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgementException"
type="AcceptanceAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
</xsd:sequence>
<xsd:attribute
name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute
name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute
name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute
name="isNonRepudiationReceiptRequired" type="xsd:boolean"/>
<xsd:attribute
name="isNonRepudiationRequired" type="xsd:boolean"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Notification"
substitutionGroup="BusinessTransactionHead">
<xsd:annotation>
<xsd:documentation>A concrete Business Transaction Pattern
where there is a formal information exchange between parties that may
affect the previous completion of a Commercial or Business Transaction
(of the BusinessTransactionType). For example, when the Notification
pattern is used for the Notification of Failure Business Transaction,
this involves a business message. Another example of a business
notification is an Advance Ship Notice. It is important to note that in
this pattern there is a Responding Business Activity and corresponding
Responding Role irrespective of the fact there is not a Responding
Business Document. That Responding role receives and processes (in an
abstract sense) the Request. The Responding Business Activity binds the
associate role to the business action. Note: This concrete pattern was
added in v2.0. </xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="BusinessTransactionBaseType">
<xsd:sequence>
<xsd:element name="RequestingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction
base="RequestingBusinessActivityType">
<xsd:sequence>
<xsd:element
ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element
ref="DocumentEnvelope"/>
<xsd:element
name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType"/>
<xsd:element
name="ReceiptAcknowledgementException"
type="ReceiptAcknowledgementExceptionType"/>
<xsd:element
name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType"
minOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgementException"
type="AcceptanceAcknowledgementExceptionType" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute
name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute
name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute
name="isNonRepudiationRequired" type="xsd:boolean"/>
<xsd:attribute
name="isNonRepudiationReceiptRequired" type="xsd:boolean"/>
<xsd:attribute
name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute
name="timeToAcknowledgeAcceptance" type="xsd:duration"/>
<xsd:attribute name="retryCount"
type="xsd:int"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="RespondingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction
base="RespondingBusinessActivityType">
<xsd:sequence>
<xsd:element
ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element
ref="DocumentEnvelope" minOccurs="0" maxOccurs="0"/>
<xsd:element
name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType"
minOccurs="0" maxOccurs="0"/>
<xsd:element
name="ReceiptAcknowledgementException"
type="ReceiptAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType"
minOccurs="0" maxOccurs="0"/>
<xsd:element
name="AcceptanceAcknowledgementException"
type="AcceptanceAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
</xsd:sequence>
<xsd:attribute
name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute
name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute
name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute
name="isNonRepudiationReceiptRequired" type="xsd:boolean"/>
<xsd:attribute
name="isNonRepudiationRequired" type="xsd:boolean"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
Technical specification:
Changes proposed:
a. Ensure text is clear about RespondingBusinessActivity on all concrete
patterns. Relate activity to Responding role and business actions.
Section 3.4.9.1:
Change from:
A Business Action, an abstract element, is the holder of attributes that
are common to both Requesting Business Activity and Responding Business
Activity. This element cannot appear in ebBP instances.
Change to:
[note preceding paragraphs talk about Request and Response, and Business
Documents.]
A Business Action, an abstract element, is the holder of attributes that
are common to both Requesting Business Activity and Responding Business
Activity. This element cannot appear in ebBP instances. Irrespective of
whether or not a Response Business Document is required (i.e. no
DocumentEnvelope), a Responding Business Activity exists to bind the
corresponding role and business action.
Section 3.4.9.5
Change from:
Request and Response Document Flows contain Business Documents that
pertain to the Business Transaction request and response. Business
Documents have varying structures. A Document Flow is not modeled
directly. Rather it is modeled indirectly as a Document Envelope sent by
one role and received by the other. The Document Envelope is always
associated with one Requesting Business Activity or one Responding
Business Activity to specify the flow.
Document Envelopes are named. There is always only one named Document
Envelope for a Requesting Activity. There MAY be zero, one, or more
mutually exclusive, named Document Envelopes for a Responding Activity.
For example, the Response Document Envelopes for a purchase order
transaction might be named PurchaseOrderAcceptance, PurchaseOrderDenial,
and PartialPurchaseOrderAcceptance.
Change to:
Request and Response Document Flows contain Business Documents that
pertain to the Business Transaction request and response. Business
Documents have varying structures. A Document Flow is not modeled
directly. Rather it is modeled indirectly as a Document Envelope sent by
one role and received by the other. The Document Envelope is always
associated with one Requesting Business Activity or one Responding
Business Activity to specify the flow.
Document Envelopes are named. There is always only one named Document
Envelope for a Requesting Activity. There MAY be zero, one, or more
mutually exclusive, named Document Envelopes for a Responding Activity.
For example, the Response Document Envelopes for a purchase order
transaction might be named PurchaseOrderAcceptance, PurchaseOrderDenial,
and PartialPurchaseOrderAcceptance. Irrespective if a Document
Envelope exists, the Responding Business Activity exists .
Appendix G Glossary
Change from:
Requesting Business Activity
A required component of a Business Transaction that is sent by the
requesting role as a Document Envelope; performed by the partner in a
role that is requesting business service from another business partner
in a role
Responding Business Activity
A component of a Business Transaction that is sent by the responding
role as a Document Envelope; performed by a partner in a role that is
responding to a request for a business service
Change to:
Requesting Business Activity
A required component of a Business Transaction that is sent by the
requesting role as a Document Envelope; performed by the partner in a
role that is requesting business service from another business partner
in a role. The Requesting Business Activity binds the roles to the
associated business action
Responding Business Activity
Is a component of a Business Transaction that may be sent in a Document
Envelope by the Responding role; performed by a partner in a role that
is responding to a request for a business service. The Responding
Business Activity binds the roles to the associated business action
irrespective of whether or not a Document Envelope (and Business
Document) exists
Reference:
[1] v2.0.1 schema:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=13235
(r04)
[2] Summary of work item:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200506/msg00040.html
We discussed Novelli's case today at length to decide the optimal approach that will serve v2.0.1 and future versions.
Hers is a summary of the proposed changes including the schema and technical specification. Please send any comments to the TC list at your earliest convenience (or to Dale Moberg and myself). As we agreed in quorate meeting yesterday, I will post this to the list through close of business tomorrow, and then initiate a vote on these proposed changes on Kavi.
In the working draft r04 schema [1], the patterns Notification and InformationDistribution have a Requesting Business Activity (summary of work item [2]). The Performs requires two roles be defined. However, no Responding Business Activity existed.
What this uncovered were some subtle distinctions:
* There are still Requesting and Responding roles and two partners.
Even, the Responding role that receives has work to do. Roles
should be able to bind regardless of pattern. Both roles should be
present regardless of pattern, and the binding should be role to role.
* There is a Responding Business Activity. However, in these two cases, there is not a Responding Business Document.
Options considered:
1. Change Performs such as to add an attribute to indicate that the
corresponding Role is linked to the receiving side of the BT.
2. Add Responding Business Activity that is able to bind that Role
regardless if any Business Document is sent.
Additional discussion points raised Tuesday:
1. A business action still exists in the receipt and processing of the Request.
2. The Responding role does exist.
3. The actions may be (somewhat) implicit.
4. Adding a RespondingBusinessActivity on these two patterns will enable us to be more flexible (in a standardized way) to
handle greater complexity with status visibility, multiparty collaboration and ComplexBTA in the future.
Open question:
1. Should the additional attributes be restricted as well?
Proposed changes overview:
Clarify that a Responding role and Responding Business Activity exist irrespective of concrete pattern. Note, we may not be able to dictate this for the Data Exchange given the agreement of the parties.
Specific proposed changes:
Schema [snippet only] r04
=====================
Changes proposed:
a. Add annotation description to Information Distribution and Notification Patterns.
b. Add constrained Responding Business Activity on both.
Change from:
<xsd:element name="InformationDistribution" substitutionGroup="BusinessTransactionHead">
<xsd:annotation>
<xsd:documentation>A concrete Business Transaction Pattern where an informal exchange
occurs between parties. Typically no residual obligation between parties applies. No
response applies. Note: This concrete pattern was added in v2.0.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="BusinessTransactionBaseType">
<xsd:sequence>
<xsd:element name="RequestingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction base="RequestingBusinessActivityType">
<xsd:sequence>
<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="DocumentEnvelope"/>
<xsd:element name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType" minOccurs="0"/>
<xsd:element name="ReceiptAcknowledgementException" type="ReceiptAcknowledgementExceptionType" minOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType" minOccurs="0" maxOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgementException" type="AcceptanceAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute name="retryCount" type="xsd:int"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Notification" substitutionGroup="BusinessTransactionHead">
<xsd:annotation>
<xsd:documentation>A concrete Business Transaction Pattern where there is a formal
information exchange between parties that may affect the previous completion of a
Commercial or Business Transaction (of the BusinessTransactionType). For example,
when the Notification pattern is used for the Notification of Failure Business
Transaction, this involves a business message. Another example of a business
notification is an Advance Ship Notice. Note: This concrete pattern was added in
v2.0.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="BusinessTransactionBaseType">
<xsd:sequence>
<xsd:element name="RequestingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction base="RequestingBusinessActivityType">
<xsd:sequence>
<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="DocumentEnvelope"/>
<xsd:element name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType"/>
<xsd:element name="ReceiptAcknowledgementException" type="ReceiptAcknowledgementExceptionType"/>
<xsd:element name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType" minOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgementException" type="AcceptanceAcknowledgementExceptionType" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute name="isNonRepudiationRequired" type="xsd:boolean"/>
<xsd:attribute name="isNonRepudiationReceiptRequired" type="xsd:boolean"/>
<xsd:attribute name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute name="timeToAcknowledgeAcceptance" type="xsd:duration"/>
<xsd:attribute name="retryCount" type="xsd:int"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
Change to: [snippet only] r05
<xsd:element name="InformationDistribution" substitutionGroup="BusinessTransactionHead">
<xsd:annotation>
<xsd:documentation>A concrete Business Transaction Pattern where an informal exchange
occurs between parties. Typically no residual obligation between parties applies. No
Responding Business Document (response) applies. It is important to note that in this pattern there is a Responding Business Activity and corresponding Responding Role irrespective of the fact there is not a Responding Business Document. That Responding role receives and processes (in an abstract sense) the Request. The Responding Business Activity binds the associate role to the business action. Note: This concrete pattern was added in v2.0.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="BusinessTransactionBaseType">
<xsd:sequence>
<xsd:element name="RequestingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction base="RequestingBusinessActivityType">
<xsd:sequence>
<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="DocumentEnvelope"/>
<xsd:element name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType" minOccurs="0"/>
<xsd:element name="ReceiptAcknowledgementException" type="ReceiptAcknowledgementExceptionType" minOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType" minOccurs="0" maxOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgementException" type="AcceptanceAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute name="retryCount" type="xsd:int"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="RespondingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction base="RespondingBusinessActivityType">
<xsd:sequence>
<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="DocumentEnvelope" minOccurs="0" maxOccurs="0"/>
<xsd:element name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType" minOccurs="0" maxOccurs="0"/>
<xsd:element name="ReceiptAcknowledgementException" type="ReceiptAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType" minOccurs="0" maxOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgementException" type="AcceptanceAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute name="isNonRepudiationReceiptRequired" type="xsd:boolean"/>
<xsd:attribute name="isNonRepudiationRequired" type="xsd:boolean"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Notification" substitutionGroup="BusinessTransactionHead">
<xsd:annotation>
<xsd:documentation>A concrete Business Transaction Pattern where there is a formal information exchange between parties that may affect the previous completion of a Commercial or Business Transaction (of the BusinessTransactionType). For example, when the Notification pattern is used for the Notification of Failure Business Transaction, this involves a business message. Another example of a business notification is an Advance Ship Notice. It is important to note that in this pattern there is a Responding Business Activity and corresponding Responding Role irrespective of the fact there is not a Responding Business Document. That Responding role receives and processes (in an abstract sense) the Request. The Responding Business Activity binds the associate role to the business action. Note: This concrete pattern was added in v2.0. </xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="BusinessTransactionBaseType">
<xsd:sequence>
<xsd:element name="RequestingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction base="RequestingBusinessActivityType">
<xsd:sequence>
<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="DocumentEnvelope"/>
<xsd:element name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType"/>
<xsd:element name="ReceiptAcknowledgementException" type="ReceiptAcknowledgementExceptionType"/>
<xsd:element name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType" minOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgementException" type="AcceptanceAcknowledgementExceptionType" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute name="isNonRepudiationRequired" type="xsd:boolean"/>
<xsd:attribute name="isNonRepudiationReceiptRequired" type="xsd:boolean"/>
<xsd:attribute name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute name="timeToAcknowledgeAcceptance" type="xsd:duration"/>
<xsd:attribute name="retryCount" type="xsd:int"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="RespondingBusinessActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction base="RespondingBusinessActivityType">
<xsd:sequence>
<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="DocumentEnvelope" minOccurs="0" maxOccurs="0"/>
<xsd:element name="ReceiptAcknowledgement" type="ReceiptAcknowledgementType" minOccurs="0" maxOccurs="0"/>
<xsd:element name="ReceiptAcknowledgementException" type="ReceiptAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgement" type="AcceptanceAcknowledgementType" minOccurs="0" maxOccurs="0"/>
<xsd:element name="AcceptanceAcknowledgementException" type="AcceptanceAcknowledgementExceptionType" minOccurs="0" maxOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="isAuthorizationRequired" type="xsd:boolean"/>
<xsd:attribute name="isIntelligibleCheckRequired" type="xsd:boolean"/>
<xsd:attribute name="timeToAcknowledgeReceipt" type="xsd:duration"/>
<xsd:attribute name="isNonRepudiationReceiptRequired" type="xsd:boolean"/>
<xsd:attribute name="isNonRepudiationRequired" type="xsd:boolean"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
Technical specification:
Changes proposed:
a. Ensure text is clear about RespondingBusinessActivity on all concrete patterns. Relate activity to Responding role and business actions.
Section 3.4.9.1:
Change from:
A Business Action, an abstract element, is the holder of attributes that are common to both Requesting Business Activity and Responding Business Activity. This element cannot appear in ebBP instances.
Change to:
[note preceding paragraphs talk about Request and Response, and Business Documents.]
A Business Action, an abstract element, is the holder of attributes that are common to both Requesting Business Activity and Responding Business Activity. This element cannot appear in ebBP instances. Irrespective of whether or not a Response Business Document is required (i.e. no DocumentEnvelope), a Responding Business Activity exists to bind the corresponding role and business action.
Section 3.4.9.5
Change from:
Request and Response Document Flows contain Business Documents that pertain to the Business Transaction request and response. Business Documents have varying structures. A Document Flow is not modeled directly. Rather it is modeled indirectly as a Document Envelope sent by one role and received by the other. The Document Envelope is always associated with one Requesting Business Activity or one Responding Business Activity to specify the flow.
Document Envelopes are named. There is always only one named Document Envelope for a Requesting Activity. There MAY be zero, one, or more mutually exclusive, named Document Envelopes for a Responding Activity. For example, the Response Document Envelopes for a purchase order transaction might be named PurchaseOrderAcceptance, PurchaseOrderDenial, and PartialPurchaseOrderAcceptance.
Change to:
Request and Response Document Flows contain Business Documents that pertain to the Business Transaction request and response. Business Documents have varying structures. A Document Flow is not modeled directly. Rather it is modeled indirectly as a Document Envelope sent by one role and received by the other. The Document Envelope is always associated with one Requesting Business Activity or one Responding Business Activity to specify the flow.
Document Envelopes are named. There is always only one named Document Envelope for a Requesting Activity. There MAY be zero, one, or more mutually exclusive, named Document Envelopes for a Responding Activity. For example, the Response Document Envelopes for a purchase order transaction might be named PurchaseOrderAcceptance, PurchaseOrderDenial, and PartialPurchaseOrderAcceptance. Irrespective if a Document Envelope exists, the Responding Business Activity exists .
Appendix G Glossary
Change from:
Requesting Business Activity
A required component of a Business Transaction that is sent by the requesting role as a Document Envelope; performed by the partner in a role that is requesting business service from another business partner in a role
Responding Business Activity
A component of a Business Transaction that is sent by the responding role as a Document Envelope; performed by a partner in a role that is responding to a request for a business service
Change to:
Requesting Business Activity
A required component of a Business Transaction that is sent by the requesting role as a Document Envelope; performed by the partner in a role that is requesting business service from another business partner in a role. The Requesting Business Activity binds the roles to the associated business action
Responding Business Activity
Is a component of a Business Transaction that may be sent in a Document Envelope by the Responding role; performed by a partner in a role that is responding to a request for a business service. The Responding Business Activity binds the roles to the associated business action irrespective of whether or not a Document Envelope (and Business Document) exists
Reference:
[1] v2.0.1 schema: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=13235 (r04)
[2] Summary of work item: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200506/msg00040.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]