OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-bp] RSD (WSDL / BPSS proposal)


Discussion|oasis.ebBP;
Topic|Issue 12
Point|Boundaries of 2.0 WSDL definition;
mm1@

Martin, please put your proposal that mentions WI 12 and 17.  I believe 
you have started on a draft schema. I can post to ebBP document area if 
you forward.
JJ, you have provided your proposal for the WSDL based on the support 
for WI 9-10 on Multi-Party Collaboration. Can we take that proposal and 
integrate it with Martin's for a combined schema?

Let's have this as a first-class discussion to seek resolution in the 
call on Monday, 16 February 2004.
This will be the topic of discussion for Monday's meeting except for 
closure of WI 7.

Please use RSD if you can remember.

Thanks.

martin.me.roberts@bt.com wrote:

>Anders,
>	So what you are saying is that we should in fact have seven
>concrete subclasses?
>
>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 12:51
>To: ebxml-bp@lists.oasis-open.org
>Cc: Roberts,MME,Martin,XSG3 R
>Subject: Re: [ebxml-bp] WSDL / BPSS proposal
>
>Martin,
>First I have to say that I support your simple proposal of defining BT 
>as abstract with 6 concrete subclasses. I also support another proposal 
>to create separate descriptions for each signal and message.
>
>However the referenced document is NOT a standard it is UN model LAW 
>which has been implemented more or less all over the world. In may 
>countries similar/same considerations has been included even in US 
>Uniform Electronic Transaction Act of 99.
>
>In case of dispute it is most likelly that an eCommerce LAW is superior 
>to an technical specification / protocol specification such as BPSS.
>
>Dispute and Reach are prime considrations. Who did what, when and who 
>fault,risk was it when something did go wrong? Who was responsible for 
>making a data message reach its addressee? Simply stating a protocol 
>failure is not enough.
>
>/anders
>
>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 transaction 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
>>
>>-----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
>
@mm1



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]