[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Signal alignment
Below please find the proposed language to resolve the signal issue. Please
note that the TRP implementation of signal controls and digest is
semantically and syntactically equivelant to RNIF 2.0 signal construction.
The signals described below for insertion into the BPSS (and carried in the
signal payload) meet business semantic and legal requirements. The solution
offered below allows both simple transaction implementation and robust legal
eBusiness. Note that the signal payloads are now the RNIF 1.1 versions with
their additional legal and business capabilities.
BPSS changes:
Insert after line 403:
"The Business Process Specification Schema provides both the choreography of
business signals, and the structure definition of the business payload of a
business signal. The TRP Message Service Specification signal structures
provide business service state alignment infrastructure, including unique
message identifiers and digests used to meet the basic process alignment
requirements. The business signal payload structures provided herein are
optional and normative and are intended to provide business and legal
semantic to the business signals."
Insert after line 439:
"Relationship to TRP
The Business Process Specification Schema will provide choreography of
business messages and signals. The TRP Message Service Specification
provides the infrastructure for message / signal identification, typing, and
integrity; as well as placing any one message in sequence with respect to
other messages in the choreography."
Replace lines 3075 - 3079 with the following:
"The TRP Message Service Specification signal structures provide business
service state alignment infrastructure, including unique message identifiers
and digests used to meet the basic process alignment requirements. The
business signal payload structures provided herein are optional and
normative and are intended to provide business and legal semantic to the
business signals. Since signals do not differ in structure from business
transaction to business transaction, they are defined once and for all, and
their definition is implied by the conjunction of the Business Process
Specification Schema and Message Service Specification. Here are the DTD’s
for business signal payload for receiptAcknowledgment (from the RosettaNet
website, courtesy of RosettaNet, and Edifecs). and for
acceptanceAcknowledgement and exception."
Replace lines 3084 - 3106 with the following:
"<!--
RosettaNet XML Message Schema.
http://www.rosettanet.org
RosettaNet XML Message Schema.
Receipt Acknowledgement
Version 1.1
This document has been prepared by Edifecs (http://www.edifecs.com/)
based On the Business Collaboration Framework from requirements
in conformance with the RosettaNet methodology.
-->
<!ENTITY % common-attributes "id CDATA #IMPLIED">
<!ELEMENT ReceiptAcknowledgement (
fromRole ,
NonRepudiationInformation? ,
receivedDocumentDateTime ,
receivedDocumentIdentifier ,
thisMessageDateTime ,
thisMessageIdentifier ,
toRole ) >
<!ELEMENT fromRole
( PartnerRoleDescription ) >
<!ELEMENT PartnerRoleDescription (
ContactInformation? ,
GlobalPartnerRoleClassificationCode ,
PartnerDescription ) >
<!ELEMENT ContactInformation (
contactName ,
EmailAddress ,
telephoneNumber ) >
<!ELEMENT contactName
( FreeFormText ) >
<!ELEMENT FreeFormText
( #PCDATA ) >
<!ATTLIST FreeFormText
xml:lang CDATA #IMPLIED >
<!ELEMENT EmailAddress
( #PCDATA ) >
<!ELEMENT telephoneNumber
( CommunicationsNumber ) >
<!ELEMENT CommunicationsNumber
( #PCDATA ) >
<!ELEMENT GlobalPartnerRoleClassificationCode
( #PCDATA ) >
<!ELEMENT PartnerDescription (
BusinessDescription ,
GlobalPartnerClassificationCode ) >
<!ELEMENT BusinessDescription (
GlobalBusinessIdentifier ,
GlobalSupplyChainCode ) >
<!ELEMENT GlobalBusinessIdentifier
( #PCDATA ) >
<!ELEMENT GlobalSupplyChainCode
( #PCDATA ) >
<!ELEMENT GlobalPartnerClassificationCode
( #PCDATA ) >
<!ELEMENT NonRepudiationInformation (
GlobalDigestAlgorithmCode ,
OriginalMessageDigest ) >
<!ELEMENT GlobalDigestAlgorithmCode
( #PCDATA ) >
<!ELEMENT OriginalMessageDigest
( #PCDATA ) >
<!ELEMENT receivedDocumentDateTime
( DateTimeStamp ) >
<!ELEMENT DateTimeStamp
( #PCDATA ) >
<!ELEMENT receivedDocumentIdentifier
( ProprietaryDocumentIdentifier ) >
<!ELEMENT ProprietaryDocumentIdentifier
( #PCDATA ) >
<!ELEMENT thisMessageDateTime
( DateTimeStamp ) >
<!ELEMENT thisMessageIdentifier
( ProprietaryMessageIdentifier ) >
<!ELEMENT ProprietaryMessageIdentifier
( #PCDATA ) >
<!ELEMENT toRole
( PartnerRoleDescription ) >"
Replace line 3112 - 3128 with the following:
"<!--
RosettaNet XML Message Schema.
http://www.rosettanet.org
RosettaNet XML Message Schema.
Acceptance Acknowledgement Exception
Version 1.1
This document has been prepared by Edifecs (http://www.edifecs.com/)
based On the Business Collaboration Framework from requirements
in conformance with the RosettaNet methodology.
-->
<!ENTITY % common-attributes "id CDATA #IMPLIED">
<!ELEMENT AcceptanceAcknowledgementException (
fromRole ,
reason ,
theMessageDatetime ,
theOffendingDocumentDateTime ,
theOffendingDocumentIdentifier ,
thisMessageIdentifier ,
toRole ) >
<!ELEMENT fromRole
( PartnerRoleDescription ) >
<!ELEMENT PartnerRoleDescription (
ContactInformation? ,
GlobalPartnerRoleClassificationCode ,
PartnerDescription ) >
<!ELEMENT ContactInformation (
contactName ,
EmailAddress ,
telephoneNumber ) >
<!ELEMENT contactName
( FreeFormText ) >
<!ELEMENT FreeFormText
( #PCDATA ) >
<!ATTLIST FreeFormText
xml:lang CDATA #IMPLIED >
<!ELEMENT EmailAddress
( #PCDATA ) >
<!ELEMENT telephoneNumber
( CommunicationsNumber ) >
<!ELEMENT CommunicationsNumber
( #PCDATA ) >
<!ELEMENT GlobalPartnerRoleClassificationCode
( #PCDATA ) >
<!ELEMENT PartnerDescription (
BusinessDescription ,
GlobalPartnerClassificationCode ) >
<!ELEMENT BusinessDescription (
GlobalBusinessIdentifier ,
GlobalSupplyChainCode ) >
<!ELEMENT GlobalBusinessIdentifier
( #PCDATA ) >
<!ELEMENT GlobalSupplyChainCode
( #PCDATA ) >
<!ELEMENT GlobalPartnerClassificationCode
( #PCDATA ) >
<!ELEMENT reason
( FreeFormText ) >
<!ELEMENT theMessageDatetime
( DateTimeStamp ) >
<!ELEMENT DateTimeStamp
( #PCDATA ) >
<!ELEMENT theOffendingDocumentDateTime
( DateTimeStamp ) >
<!ELEMENT theOffendingDocumentIdentifier
( ProprietaryDocumentIdentifier ) >
<!ELEMENT ProprietaryDocumentIdentifier
( #PCDATA ) >
<!ELEMENT thisMessageIdentifier
( ProprietaryMessageIdentifier ) >
<!ELEMENT ProprietaryMessageIdentifier
( #PCDATA ) >
<!ELEMENT toRole
( PartnerRoleDescription ) > "
Comments requested, soon please.
Thanks!
John
-----Original Message-----
From: John Yunker
Sent: Thursday, April 26, 2001 10:11 AM
To: ebxml-bp@lists.ebxml.org
Cc: 'James Bryce Clark'; 'Karsten Riemer'
Subject: RE: Signal alignment
As discussed on this mornings call:
Issues that Jamie and John will try to resolve today. Please send your
preference if you have one:
1) Reference TRP as meeting technical requirements for state alignment. The
TRP implementations of acknowledgement and exception are necessary and
sufficient to tie together the unique identifiers of the business messages
being acknowledged or excepted. The TRP implementation also provides a
mechanism to transport digests that meet the requirements for technical
non-repudiation of receipt.
2) Choose between:
a) Normative requirement of signal content in the payload, as described in
the BPSS
b) Non-normative optional signal content in the payload, as described in
the BPSS or agreed between partners
3) Choose between:
a) Show signals as in current version of BPSS
b) Replace acknowledgement signals with RNIF 1.1 versions
4) Do we discuss that partners that decide not to use TRP can meet the
business objectives of non-repudiation through use of the BPSS signal
content? (note that there is a big problem with this: We don't place a
requirement for digest in the original content for non-repudiation of origin
and content, and have not addressed placing this requirement on Core
Components -> we have NOT done sufficient analysis nor specification for
implementations that don't use TRP to be legal e-business)
Jamie and I will send out a post with our recommendations by 1:00 Pacific
time.
Thanks,
John
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC