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] 1/5/2004: Late Binding ....


Monica,

I think we're a little bit out of synch' here.

I'm focusing on XML level facilitation to make
sure the XML syntax itself of BPSS is capable
of supporting the business functionality - and 
a BPSS engine can consume and use it - while
you seem to be thinking at a logical business level.

That's OK- we need both - but I think the logical
level is largely clear - at least the big picture - what's
critical though is now making sure the XML has
the underpinning there too to accomplish that.

Just making an observation - no bad here ; -)

Sometimes though I'm seeing responses that may
be confusing - so I guess we need to make clear
in our emails whether we're at the [XML] or
[Model] context level!

Thanks, DW.

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "David RR Webber" <david@drrw.info>
Cc: <ebxml-bp@lists.oasis-open.org>
Sent: Thursday, January 08, 2004 5:14 PM
Subject: Re: [ebxml-bp] 1/5/2004: Late Binding ....


> David RR Webber wrote:
> 
> >Monica,
> >
> >I know its nice to think of peer to peer - but certain
> >transactions clearly one peer has to be the arbitator and
> >make critical decisions.   GM/Nissan with their suppliers
> >and dealerships is hardly Peer-to-Peer, but the BPSS
> >model makes sense, but right now - GM / Nissan would
> >only want to share the sub-BPSS for dealership with
> >them - and not everyone else, and vice versa.
> >  
> >
> mm1: There is also work ongoing in CPA negotiation where some of the 
> business transaction characteristics are negotiated (after v1.0).  I 
> would assume this is where GM or Nissan assert their muscle and indicate 
> that only a minimum set of details are negotiable.
> 
> >There's complex interactions here - and we can model
> >them and make them run smoothly.  Similarly - re-usable
> >'chunks' do not resolve solely around a business document
> >exchange.
> >
> >I believe we fundamentally need an <include> statement,
> >along with all that entails - versioning, a sub-BPSS 
> >best-practices, and worked examples.
> >  
> >
> mm1: See 5.12.1, Packages and Includes and 6.1.17 where the Include 
> element is defined. Thanks.
> 
> >This is obviously something we need to discuss further
> >as you indicated.   Hopefully most of the pieces for this
> >already exist - we merely need to document the 
> >'how to' and provide some 'glue' syntax to bring it all
> >together quickly and easily.
> >
> >Thanks, DW.
> >
> >  
> >
> >>> 
> >>>
> >>>      
> >>>
> >>mm2: The main point of my response Dave is that you are mixing BPEL 
> >>concepts in BPSS. You talked about a controlling party - in BPSS the 
> >>relationship is peer-to-peer. Thanks
> >>
> >>    
> >>
> >
> >  
> >
> 
> 
> 


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