ebBP 3/27/2005: Comment re: Signal Reason (wd10-schema 2/22)

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

As we discussed in Tuesday's call, was there a need for a signal 
exception reason. Sacha Schlegel had asked the original question. The 
actual reason for an exception signal is held in the signal schema itself.

    * Reference: Signal schema draft attached.
    * Proposed change: None.

Sacha, if you have other questions, please advise. Thanks for your input 
and suggestions.
<?xml version="1.0" encoding="UTF-8"?>
<!-- By Himagiri Mukkamala(himagiri@sybase.com) . This schema has the element definitions for the signal messages used in the run time execution of BPSS.-->
<xsd:schema targetNamespace="http://www.ebxml.org/BusinessProcess/BPSS_SIGNALS"; xmlns="http://www.ebxml.org/BusinessProcess/BPSS_SIGNALS"; xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns:bpssignal="http://www.ebxml.org/BusinessProcess/BPSS_SIGNALS"; xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" attributeFormDefault="qualified" version="2.0">
	<xsd:import namespace="http://www.w3.org/1999/xlink"; schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/xlink.xsd"/>
	<xsd:annotation>
		<xsd:documentation>
The version of digital signature specification supported is identified using the namespace and schemalocation denoted below		</xsd:documentation>
	</xsd:annotation>
	<xsd:import namespace="http://www.w3.org/2000/09/xmldsig#"; schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
	<xsd:simpleType name="non-empty-string">
		<xsd:restriction base="xsd:string">
			<xsd:minLength value="1"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:complexType name="PartyInfoType">
		<xsd:annotation>
			<xsd:documentation>
This type defines the structure for PartyInfo Definition. The "type" attribute identifies the type of PartyId 
which is the content for PartyInfo type being defined here.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:simpleContent>
			<xsd:extension base="non-empty-string">
				<xsd:attribute name="type" type="non-empty-string"/>
			</xsd:extension>
		</xsd:simpleContent>
	</xsd:complexType>
	<xsd:complexType name="RoleType">
		<xsd:annotation>
			<xsd:documentation>
This type defines the structure for Role Definition.
			 </xsd:documentation>
		</xsd:annotation>
		<xsd:attribute name="name" type="non-empty-string" use="required"/>
		<xsd:attributeGroup ref="xlink.grp"/>
	</xsd:complexType>
	<xsd:attributeGroup name="xlink.grp">
		<xsd:annotation>
			<xsd:documentation>
	The "xlink:type" attribute has a FIXED value of "simple". This identifies the element as being an XLINK simple link. The "xlink:href" attribute SHALL have a value that is a URI that conforms to [RFC2396]. It identifies the location of the element or attribute within the Process-Specification document that defines the role in the context of the Business Collaboration. 
			</xsd:documentation>
		</xsd:annotation>
		<xsd:attribute ref="xlink:type" fixed="simple"/>
		<xsd:attribute ref="xlink:href" use="required"/>
	</xsd:attributeGroup>
	<xsd:complexType name="ProcessSpecificationType">
		<xsd:annotation>
			<xsd:documentation>
	This defines the content structure for identiying the ProcessSpecification for which this signal
	is being sent. 
	
	"Version" attribute refers to version of ProcessSpecification identified by the "name" attribute.
	The "name" attribute MUST be set to the name for the corresponding ProcessSpecification element within the Business Process Specification instance.
	
	The "xlink:type" attribute has a FIXED value of "simple". This identifies the element as being an XLINK simple link. The "xlink:href" attribute SHALL have a value that is a URI that conforms to [RFC2396]. It identifies the location of the Process-Specification document that defines the Business Collaboration. 

	The "uuid" attribute captures the unique identifier given to the process specification document that is being referred.
	It corresponds to the uuid attribute of "ProcessSpecification" element in the BPSS instance document
			</xsd:documentation>
		</xsd:annotation>
		<xsd:attribute name="version" type="non-empty-string"/>
		<xsd:attribute name="name" type="non-empty-string"/>
		<xsd:attributeGroup ref="xlink.grp"/>
		<xsd:attribute name="uuid" type="xsd:anyURI"/>
	</xsd:complexType>
	<xsd:complexType name="SignalIdentificationInformation">
		<xsd:annotation>
			<xsd:documentation>
	This defines the content structure for identiying various parameters pertaining to the business signal. 
	"OriginalMessageIdentifier" captures the value of the message identifier for original message to which this signal is being sent. 
	If business message has an identifier, that can be captured by the "OriginalDocumentIdentifier" attribute.
	"OriginalMessageDateTime" is the time when the original message was sent.
	"ThisMessageDateTime" is the time when this signal message is being sent.
	
	The following optional elements are there to provide access to information that can be used
	by processing logic outside the business process engine. One example of this could be
	a monitoring application which can use this information to provide status of a collaboration.
	
	"FromPartyInfo" describes the party id that is sending the signal message.
	"ToPartyInfo" describes the party id that is being sent the signal message.
	
	The roles described below are based on the implicit relationship between the partner sending
	the signal message and the  partner who sent the original message to which this particular signal
	is being sent. The role relationship between partner sending the business message and the
	 partner receiving it is captured in the BPSS document.
	
	"FromRole" captures the role being played by the party that is sending the signal message.
	"ToRole" captures the role played by the party that is being sent the signal message.	
	"ProcessSpecificationInfo" type descibes the BPSS information which defines the runtime collaborations for which this signal is being sent
	"CollaborationIdentifier" is the unique identifer that associates the signal with a particular collaboration. 
	This could come from the business message itself or in case of ebXML MSH, could be the messaging
	level header "ConversationId"
	"BusinessActivityIdentifier" identifies the business requesting or responding activity to which
	this signal is being sent. This would identify the "BusinessAction" from the BPSS document and
	could be implemented using the "name"  attribute on either the REquestingBusinessActivity or the 
	RespondingBusinessActivity
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OriginalMessageIdentifier" type="bpssignal:non-empty-string"/>
			<xsd:element name="OriginalDocumentIdentifier" type="bpssignal:non-empty-string" minOccurs="0"/>
			<xsd:element name="OriginalMessageDateTime" type="xsd:dateTime"/>
			<xsd:element name="ThisMessageDateTime" type="xsd:dateTime"/>
			<xsd:element name="FromPartyInfo" type="bpssignal:PartyInfoType" minOccurs="0"/>
			<xsd:element name="ToPartyInfo" type="bpssignal:PartyInfoType" minOccurs="0"/>
			<xsd:element name="FromRole" type="bpssignal:RoleType" minOccurs="0"/>
			<xsd:element name="ToRole" type="bpssignal:RoleType" minOccurs="0"/>		
			<xsd:element name="ProcessSpecificationInfo" type="bpssignal:ProcessSpecificationType" minOccurs="0"/>
			<xsd:element name="CollaborationIdentifier" type="bpssignal:non-empty-string" minOccurs="0"/>
			<xsd:element name="BusinessActivityIdentifier" type="bpssignal:non-empty-string" minOccurs="0"/>	
		</xsd:sequence>
	</xsd:complexType>
	<xsd:element name="Exception">
		<xsd:annotation>
			<xsd:documentation>
	This defines the content structure for messages that need to send an exception signals as a business message to a trading partner. For description of first nine elements, refer to documentation on SignalIdentificationInformation.

	"ExceptionType" is used to identify various exceptions that can occur during the execution of binary collaboration.
	Run time processing engine executing BPSS based collaborations generates a "ReceiptException" if request message results in a negative receipt acknowledgment cause of various problems like "Syntax validation" of business message",
"Unauthorized execution of process", "Failure of Signature validation in incoming message", "Out of sequence message" corresponding respectively to "Syntax", "Authorization", "Signature", "Sequence".

	Run time processing engine executing BPSS based collaborations generates a "AcceptanceException" if request message results in a negative acceptance acknowledgment cause of various problems. Please refer the the specification for various reasons why negative acceptance acknowledgment may be sent.

	Run time processing engine executing BPSS based collaborations can send a "GeneralException" if processing of a  request message results in a state where further processing can not continue. 

	"Reason" can be used to send a message to convey the reason for exception being generated.
	
	"ExceptionMessage" can include a descriptive message corresponding to the exception
			</xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:complexContent>
				<xsd:extension base="bpssignal:SignalIdentificationInformation">
					<xsd:sequence>
						<xsd:element name="ExceptionType">
							<xsd:complexType>
								<xsd:choice>
									<xsd:element name="ReceiptException">
										<xsd:simpleType>
											<xsd:restriction base="xsd:string">
												<xsd:enumeration value="Syntax"/>
												<xsd:enumeration value="Authorization"/>
												<xsd:enumeration value="Signature"/>
												<xsd:enumeration value="Sequence"/>
											</xsd:restriction>
										</xsd:simpleType>
									</xsd:element>
									<xsd:element name="AcceptanceException">
										<xsd:simpleType>
											<xsd:restriction base="xsd:string">
												<xsd:enumeration value="Business"/>
												<xsd:enumeration value="Performance"/>
											</xsd:restriction>
										</xsd:simpleType>
									</xsd:element>
									<xsd:element name="GeneralException">
										<xsd:simpleType>
											<xsd:restriction base="xsd:string"/>
										</xsd:simpleType>
									</xsd:element>
								</xsd:choice>
							</xsd:complexType>
						</xsd:element>
						<xsd:element name="Reason" type="bpssignal:non-empty-string"/>
						<xsd:element name="ExceptionMessage" type="bpssignal:non-empty-string" minOccurs="0"/>
						<xsd:any namespace="##other" minOccurs="0"/>
					</xsd:sequence>
				</xsd:extension>
			</xsd:complexContent>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="ReceiptAcknowledgment">
		<xsd:annotation>
			<xsd:documentation>
	This defines the content structure for messages that need to send an ReceiptAcknowledgment signals as a business message to a trading partner. Please refer to BPSS document for detailed description of ReceiptAcknowledgment.
	This element is used for complying with  NonRepudiationofReceipt(NRR) by including the "NonRepudiationInformation" 
	child element as described below. For NonRepudiationofOrigin the originating business message will have
	nonrepudiation information and signals don't cater to that requirement.

	 For description of first nine elements, refer to documentation on SignalIdentificationInformation.
	 
	 ReceiptAcknowledgment signals can include non-repudiation information if requested in the process definition. 
	 "NonRepudiationInformation" captures this data for each of the message parts that comprise the request message that was sent. Each "MessagePartNRInformation" describes non-repudiation information for a message part identified by "MessagePartIdentifier" using "Reference" described by XML Digital Signature Specification. Each part of the request message will have a corresponding "MessagePartNRInformation".

	If necessary, digital signature can be computed for this signal message and included using "Signature" element from XML Digital Signature namespace.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:complexContent>
				<xsd:extension base="bpssignal:SignalIdentificationInformation">
					<xsd:sequence>
						<xsd:element ref="bpssignal:NonRepudiationInformation" minOccurs="0"/>
						<xsd:element ref="ds:Signature" minOccurs="0"/>
						<xsd:any namespace="##other" minOccurs="0"/>
					</xsd:sequence>
				</xsd:extension>
			</xsd:complexContent>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="NonRepudiationInformation">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element ref="bpssignal:MessagePartNRInformation" maxOccurs="unbounded"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="MessagePartNRInformation">
		<xsd:complexType>
			<xsd:choice>
				<xsd:element name="MessagePartIdentifier" type="bpssignal:non-empty-string"/>
				<xsd:element ref="ds:Reference"/>
			</xsd:choice>
		</xsd:complexType>
	</xsd:element>
	<xsd:element name="AcceptanceAcknowledgment">
		<xsd:annotation>
			<xsd:documentation>
	This defines the content structure for messages that need to send an AcceptanceAcknowledgment signals as a business message to a trading partner. Please refer to BPSS document for detailed description of AcceptanceAcknowledgment.

	 For description of first nine elements, refer to documentation on SignalIdentificationInformation.
	 
	If necessary, digital signature can be computed for this signal message and included using "Signature" element from XML Digital Signature namespace.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:complexContent>
				<xsd:extension base="bpssignal:SignalIdentificationInformation">
					<xsd:sequence>
						<xsd:element ref="ds:Signature" minOccurs="0"/>
						<xsd:any namespace="##other" minOccurs="0"/>
					</xsd:sequence>
				</xsd:extension>
			</xsd:complexContent>
		</xsd:complexType>
	</xsd:element>
</xsd:schema>