[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] WSDL / BPSS proposal
Duane, It was because of this that I did not want to see references to WSDL in the v2.0 spec but show outside of it how such an extension might be made. Martin Roberts xml designer, BT Exact e-mail: martin.me.roberts@bt.com tel: +44(0) 1473 609785 clickdial fax: +44(0) 1473 609834 Intranet Site :http://twiki.btlabs.bt.co.uk/twiki -----Original Message----- From: Duane Nickull [mailto:dnickull@adobe.com] Sent: 12 February 2004 17:03 To: Roberts,MME,Martin,XSG3 R Cc: anderst@toolsmiths.se; jeanjadu@Attachmate.com; ebxml-bp@lists.oasis-open.org Subject: Re: [ebxml-bp] WSDL / BPSS proposal I like the direction you are thinking. One of my main concerns is that BP* remains independent of other models. Duane martin.me.roberts@bt.com wrote: >IN my simplistic brain I am unable to carry all the variations that are >being proposed for the various links to various possible standards. I >therefore would like to make a simple proposal that might enable us to >focus on the BPSS yet allow for sensible extensions. > > 1) the BPSS does not attempt to go beyond the process layer that we >currently understand > 2) We rebuild the schema to allow for hooks for extensions at most >levels. > This would include both the ability to replace an item >using the Ventian Blind substitution group method as well as defined >hooks for lower level artifacts, such as the WSDL definitions. > 3) We produce a white paper showing how extensions work and possibly >prime it with an extension for WSDL > 4) we explicity define BusinessTransaction as an abstract class to be >overloaded with subclasses for each of the 6 known transcation >patterns, where the main difference is the default values for the flags >- This would allow for two things a) overriding of flag values even >when using a pattern and b) external new patterns for cases where the 6 >existing do not work. > > This would be a major departure from 1.01 and 1.05 and even UN 1.1 but >would lay a great foundation for other work in the future. > > What do people think? > >Martin Roberts >xml designer, >BT Exact >e-mail: martin.me.roberts@bt.com >tel: +44(0) 1473 609785 clickdial >fax: +44(0) 1473 609834 >Intranet Site :http://twiki.btlabs.bt.co.uk/twiki > > > >-----Original Message----- >From: Anders W. Tell [mailto:anderst@toolsmiths.se] >Sent: 12 February 2004 10:58 >To: Jean-Jacques Dubray >Cc: ebxml-bp@lists.oasis-open.org >Subject: Re: [ebxml-bp] WSDL / BPSS proposal > > >Jean-Jacques Dubray wrote: > > > >>You write that a OperationActivity is different from BT/BTA, since it >>looks very similar to RequestResponseTransaction could you elaborate >>on >> >> > > > >>the reasons why ? >>JJ>I responded to that in an ealier email (direction cannot be >>JJ>inverted >>like a BT in two different BTAs with opposite roles) >> >>secondly how does OperationActivity handle semantics and obligations >>related to dispatch, reach? >> >>JJ>What do mean with dispatch and reach? >> >> >> >> > >As defined by UNCITRAL Model Law on Electronic Commerce with Guide to >Enactment (1996), with additional article 5 /bis/ as adopted in 1998 >Article 15 and others. ><http://www.uncitral.org/english/texts/electcom/ml-ecomm.htm> > >Basically these legal conventions and other electronic act points out >the importance of separating sending and receiving of data messages. The > >"legal effect" may be defined at 6 point >1 Request.dispatch >2 Request.reach >3 Responce.dispatch >4 Responce.reach >5-6 Who has the risk when a data message has been dispatched and when >it > >has reached is also relevant. > >All above considerations affects a BT outcome. It appears that >specifying protocol error or method invocation exeception is not enough >in an eCommerce environment. > >/Anders > > > > >/anders > > > -- Senior Standards Strategist Adobe Systems, Inc. http://www.adobe.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]