FW: [ebxml-bp] Business Transaction definition

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

[ RePosting minus attachments because response failed to be remailed.
I can send the modified schema to anyone interested.]


I have added an element called "DataExchange" to the current draft
schema, and placed the original example in 2.0 syntax to test. 


I am /s/attaching/appending the file "text.xml" which is the BPSS 2.0
instance and a schema file for the 2.0 namespace that adds the
DataExchange element. This exercise is to give an example of JJ's point
about adding patterns.


<ProcessSpecification
xmlns="http://www.oasis-open.org/committees/ebBP/BPS/2.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.oasis-open.org/committees/ebBP/BPS/2.0
c:\Schemas\ebBPSS-2_x.xsd" name="PurchasingCluster" nameID="PC23"
uuid="urn:purchasingcluster" version="2">
	<BusinessDocument name="Invoice" nameID="bd-invoice">
		<Specification type="schema"
location="http://purchasingcluster.com/Invoice.xsd"; name="Invoice"
nameID="invoice32"/>
	</BusinessDocument>
	<BusinessDocument name="InvoiceResponse"
nameID="bd-invoiceResponse">
		<Specification type="schema"
location="http://purchasingcluster.com/InvoiceResponse.xsd";
name="InvoiceResponse" nameID="invoice33"/>
	</BusinessDocument>
	<DataExchange name="BT:Invoice" nameID="bt-invoice">
		<RequestingBusinessActivity name="ReqBA:SendInvoice"
nameID="reqba-invoice" timeToAcknowledgeReceipt="PT6H"
timeToAcknowledgeAcceptance="PT12H">
			<DocumentEnvelope name="DE:ProcessInvoice"
nameID="de-invoice" businessDocumentRef="bd-invoice"/>
		</RequestingBusinessActivity>
		<RespondingBusinessActivity name="ResBA:ReceiveInvoice"
nameID="resba-invoice">
			<DocumentEnvelope
name="DE:ProcessInvoiceResponse" nameID="de-invoiceResponse"
businessDocumentRef="bd-invoiceResponse"/>
		</RespondingBusinessActivity>
	</DataExchange>
</ProcessSpecification>

If the original example and the text.xml example are compared, several
small syntax changes (such as attribute name changes) are also
illustrated.


However, the original example raises important and basic issues that
need resolution before we have production deployment of 2.0 to the
installed base. 

1. Our new specialized business transactions are much more semantically
precise than anything we previously used. They are "unforgiving" in
their documentation of QOS and signal specifications. Earlier BP
instances will not map easily into these new contexts. Should we:
a. create a new very open element, something like the "DataExchange"
element I cooked up for this problem, and use this for earlier BT
conversions?
b. adopt one of our current business transaction as the default to map
into and thus "strengthen" any conversion to the more demanding type?
c. other?

2. (Technical) The element "BusinessTransaction" currently serves as the
substitution group head for all subsequent specializations by
substitution.
In CPPA 2.1, all the substitution group names end in "xxxHead" and are
declared to be "abstract" so that they are not used in any real CPP or
CPA-- only their substitution group alternatives can be used in valid
instances. 

For BPSS should we do something like the CPPA technique so that people
don't actually use the substitution group head? If we did this, we could
then define a BusinessTransaction with weak semantics for use in
conversion from previous BPSS instances (see point 1). TC feedback on
this issue is really needed because it probably will be a source of
confusion going forward to leave the head named "BusinessTransaction".
For technical reasons related to the subtype constraint on substitution
elements, the BusinessTransaction element itself has _no_ Requesting or
Responding activities, for example. It is itself a kind of useless piece
of xml schema machinery that must have certain features so that
constraints do not get violated by the subtyping used for the real
business transactions.


-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] 
Sent: Monday, November 08, 2004 1:57 AM
To: YANO Keisuke (????)
Cc: ebXML BP
Subject: RE: [ebxml-bp] Business Transaction definition

Kesuke-san:

I assume that you are talking about the fact that the signals are
predefined in v2.0 and the example BT that you give has signals on the
request but not on the response?

Is it a desirable feature? What would be the problem of using a
CommercialTransaction which has signals on both? (I understand that an
acceptance signal is normally issued by a back end system via the BSI,
therefore requires to modify or develop the back end system for this
requirement).

In 2.0 you can also define your own patterns which could support this
one.

Jean-Jacques

-----Original Message-----
From: yano@jp.fujitsu.com [mailto:yano@jp.fujitsu.com] 
Sent: Monday, November 08, 2004 12:27 AM
To: ebxml-bp@lists.oasis-open.org
Subject: [ebxml-bp] Business Transaction definition

Folks,

Please let me put a question.  Can BPSS v2.0 allow a user to define
the following Business Transaction valid for 1.01 and 1.05?

The points are:
  - using both receipt and acceptance acknowledgment signals
  - without response

  <BusinessTransaction name="BT:Invoice" nameID="bt-invoice">
      <RequestingBusinessActivity
          name="ReqBA:SendInvoice" nameID="reqba-invoice"
          timeToAcknowledgeReceipt="PT6H"
          timeToAcknowledgeAcceptance="PT12H">
          <DocumentEnvelope name="DE:ProcessInvoice" nameID="de-invoice"
              businessDocument="BD:ProcessInvoice"
              businessDocumentIDRef="bd-invoice"/>
      </RequestingBusinessActivity>
      <RespondingBusinessActivity
          name="ResBA:ReceiveInvoice" nameID="resba-invoice"/>
  </BusinessTransaction>

The answer for the question should be "yes".  However, it seems that
the v2.0 draft schema is saying "no".

If the answer is "yes", could anyone show an example of the BPSS 2.0
instance fragment?

Thanks,

Yano Keisuke