RE: [ebxml-bp] [ebbp] 7/26/2004: Updated Draft Schema and Details

["Jean-Jacques Dubray" <jeanjadu@Attachmate.com>]

Dale, John:

I have a quick question about the //BusinessTransaction/@pattern
attribute. 

Now that we have concrete BusinessTransaction (RequestConfirm,
Notification, ...) do we still need this pattern attribute? (it also
appears on the concrete BT elements).

Is the BusinessTransaction element abstract now? Or can it still be used
in BTAs?

Jean-Jacques

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Monday, July 26, 2004 7:27 AM
To: ebXML BP
Subject: [ebxml-bp] [ebbp] 7/26/2004: Updated Draft Schema and Details

Thanks to Dale for the update. We'll discuss this today and in the
upcoming week(s).  Reminder that we meet today at 8 a.m. PDT (866 882
3998, 9081038, international 865 525 0769).

Regards.

========================================================================
==========================================
Hi Monica,

Here is a _draft_ schema incorporating the model rearrangement in
BinaryCollaboration, MultipartyCollaboration and BusinessCollaboration
(generic). And incorporating fixes to types in Signal and
SignalEnvelope. 

OperationMapping remains open.


This schema is not final and has not been extensively proofread. (Just a
validity check.)


I must have gotten off track at some point on Martin's changes at the
f2f or earlier. This should help David W. get back on track.



If we use this schema or a descendent of it, we should IMO add some WF
rules to constrain the notation{

[No stateless collaborations.]

Within any XXXCollaboration, there must be at least one state defined.

[A state is either a BTA, ComplexBTA, or CollaborationActivity.]

[Pseudostates unnecessary/deprecated.]

Links (FromLink, ToLink) should not reference linking constructs.


[Collaboration modularity constraint.]

Linking constructs (Start, Success, Failure, Transition, Fork, Join, and
Decision) must reference states in the collaboration.

Fixes on signals are now proposed as follows.

1. All BSI signals are to be extensions from SignalEnvelopeType. 

<xsd:complexType name="ReceiptAcknowledgementType">
	<xsd:complexContent>
		<xsd:extension base="SignalEnvelopeType">
			<xsd:attribute name="isPositiveReceipt"
type="xsd:boolean" fixed="true"/>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ReceiptAcknowledgementExceptionType">
	<xsd:complexContent>
		<xsd:extension base="SignalEnvelopeType">
			<xsd:attribute name="isPositiveSignal"
fixed="false"/>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="AcceptanceAcknowledgementType">
	<xsd:complexContent>
		<xsd:extension base="SignalEnvelopeType"/>
	</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="AcceptanceAcknowledgementExceptionType">
	<xsd:complexContent>
		<xsd:extension base="SignalEnvelopeType"/>
	</xsd:complexContent>
</xsd:complexType>


2. An element whose type is derived from SignalEnvelopeType has
attributes that can point to signals

<xsd:attribute name="signalDefinitionIDREF" type="xsd:IDREF"/>
<xsd:attribute name="signalDefinition" type="xsd:string"
use="required"/>

These Signal elements are defined in the BPSS instance in a list of
Signal (the Signals container 
is not needed.) These signals are of type Signal type and have a
required Specification element in their content. Is this all they need?
Should we permit the actual schema for the signal to be included in the
content model? Also there is an optional ConditionExpression element in
the signal.
I assume this was in there to maintain the parallelism between
DocumentEnvelope and Document with SignalEnvelope and Signal. Is it
needed though? I would like someone to suggest a use case for this? Can
a SignalEnvelopeNotation also be used somehow? If so we should have an
example of its usage