RE: [ebxml-bp] WSDL / BPSS proposal

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

I favor the "Garden of Eden rewrites" (Venetian blind) which means we
have both complexTypes and elements for them globally available.

That also means substitution is easily available for elements as we
evolve BPSS transaction type. Rather than inhibiting or disallowing the
available extensibility mechanisms, I think we should support them. We
can add any elements and anyAttributes
if we need to if it does not water things down too much and if the
grammars remain deterministic. Keep the X in xml!

I also favor the explicit subclassing Martin proposes for BT.

My only concern is whether we have some limitations in commonly used
tools. However, lately I have seen much better performance of tools when
substitution groups are used. The subtype constraint is being handled
much better now than it used to be, and usually there are workarounds so
that the "picky" implementations can be made happy. 

Dale Moberg


-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: Thursday, February 12, 2004 7:33 AM
To: martin.me.roberts@bt.com; anderst@toolsmiths.se;
jeanjadu@Attachmate.com
Cc: ebxml-bp@lists.oasis-open.org
Subject: Re: [ebxml-bp] WSDL / BPSS proposal


Martin,

I like the concepts - but all this Venitian Blinds and abstract class
overloading sounds too much like unnatural acts!?!

Why don't we just support the 6 transaction patterns 
directly with a simple transactionType enumerated choice approach,  and
have set of associated criteria then 
selected and configured by that.

Notice - if people then need subtle variations away from 
these 6 for local considerations - they can use the context mechanism to
define those and agree them with their
business partners.   Since these extensions are agreed
at the business level - this should go a long way to 
solving Anders concerns over the legal liability issues..

Thanks, DW.

----- Original Message ----- 
From: <martin.me.roberts@bt.com>
To: <anderst@toolsmiths.se>; <jeanjadu@Attachmate.com>
Cc: <ebxml-bp@lists.oasis-open.org>
Sent: Thursday, February 12, 2004 6:23 AM
Subject: RE: [ebxml-bp] WSDL / BPSS proposal


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 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

-- 
/////////////////////////////////////
/ Business Collaboration Toolsmiths /
/ website: <www.toolsmiths.se>      /
/ email: <anderst@toolsmiths.se>    /
/ phone: +46 8 545 885 87           /
/ mobile: +46 70 546 66 03          /
/////////////////////////////////////