[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Re: Updated InformationDistribution, NotificationPatterns and Performs (Roles
Hi, I have difficulty understanding why responding role is to be bound with responding activity. My simplistic belief has been that both of two roles are bound when initiator initiates Requesting Activity. Could anyone direct me to good reading/ML posting for understanding modeling rationale? I need to fully understand this for casting right vote. Thanks and sorry for the mess Kenji Monica J Martin wrote: > Thanks, Sally for the feedback and I see where you are going with this. > Let's try a modified wording that may be clearer. We can then ask the TC > to approve the text. The concepts were agreed upon in detail Tuesday. > See inline. Full updated proposal is attached for everyone's preview as > the vote will be initiated after this email. Sorry for delay - laptop > problems. Thanks. > >> st. amand: Monica I made some changes to your wording. My intent to >> was to make it clear that a responding activity has 2 functions: role >> binding and Document Envelope >> >> Change from: >> 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 >> >> Change to: >> Responding Business Activity >> >> Is a component of a Business Transaction that IS sent by the >> Responding role; IT IS performed by a partner in THE role that >> is responding to a request for a business service. The Responding >> Business Activity binds the roles to the associated business action and >> MAY or may not include a Document Envelope (and Business >> Document). >> > > > mm1: Is a component of a Business Transaction. It is performed by a > partner in > the role that is responding to a request for a business service. The > Responding > Business Activity binds the roles to the associated business action > and may or may not include a Document Envelope (and Business > Document) > >> Also I looked at Document Envelope in the glossary and it should be >> revised as: >> >> >> Named representation of the business Document Flow; is always one >> Document Envelope for a Requesting Activity. Can be zero, one or more >> mutually exclusive named Document Envelope for Responding Activity. >> Each contains one Business Document and one or more attachments >> > mm1: Will update. > >> My clearer may be muddying so please comment. >> Sally > > > mm1: In addition, I made one change to reference directly back to the BT > patterns in Section 3.4.9.5. Note clarifications to require both activities > 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. If used, 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 MUST 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. A Requesting and Responding Business > Activity MUST exist for each Business Transaction (and associated > Business Tranaction pattern). This condition even applies to the > Notification or Information Distribution where a Document Envelope and > Business Document are not used. > > > ------------------------------------------------------------------------ > > 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. If used, 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 MUST 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. A Requesting and Responding Business Activity MUST exist for each Business Transaction (and associated Business Tranaction pattern). This condition even applies to the Notification or Information Distribution where a Document Envelope and Business Document are not used. > > 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 > > Document Envelope > Change from: > Named representation of the business Document Flow; is always one Document Envelope for a Requesting Activity. Can be zero, one or more exclusively named Document Envelope for Responding Activity. Each contains one Business Document and one or more attachments > > Change to: > Named representation of the business Document Flow; is always one Document Envelope for a Requesting Activity. Can be zero, one or more mutually exclusive named Document Envelope for Responding Activity. Each contains one Business Document and one or more attachments > > 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. It is performed by a partner in the role that is responding to a request for a business service. The Responding > Business Activity binds the roles to the associated business action and may or may not include a Document Envelope (and Business > Document) > > 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]