[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] [ebBP] 3/19/2004: External Content/Context Mechanism [RSD]
drrw@ Monica, Maybe I went the extra mile here - just responding to everyones "wish lists" as talked about on various conference calls that occurred - and figuring - we can do that - for minimal syntax cost! My own sense is that Use Case #5 - definately is a bridge too far for now - (eg - the idea of allowing a BPSS to start to an initial state and then just sit there awaiting a signal to "go"). I'd be happy with a simpler two use case initial cut - that just looks at using CAM to provide transaction validation as one, and then transaction assembly as the other - for V2.0 In any case those are clearly the two big uses - and that meshes nicely with ebMS V3.0 support for payload handling service extensions. Beyond that the functionality around the use of the bpss: namespace in the context driver XML - can clearly be put back to V3.0 till we feel more comfortable about that. However - I would mention that while it may appear we have allowed unshackled ability to change an aspect of BPSS function at runtime - this is actually more perscribed - since the context driver XML - with all these rules and conditions in - has to be signed off on between collaboration parties - so anything must pass that level of business validation and scrutiny and agreement. This is what I see makes the approach so powerful. Schema syntax extensions in the BPSS level are largely invisible to the collaboration parties - agreeing to the CPA. However - when you use the context driver XML - that document must be agreed to -and the intent is that any overrules for the BPSS are then exposed and very apparent at that level. Anyway - clearly we need to ensure checks-and-balances to guarantee deterministic and predictable behaviours from BPSS for business users. Thanks, DW ----- Original Message ----- From: "Monica J. Martin" <Monica.Martin@Sun.COM> To: "ebXML BP" <ebxml-bp@lists.oasis-open.org> Sent: Friday, March 19, 2004 4:34 PM Subject: [ebxml-bp] [ebBP] 3/19/2004: External Content/Context Mechanism [RSD] > Discussion|OASIS.ebBP.ExternalContextMechanism; > Topic; > Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00062.html; > > Point|; > > mm1@ > David, > In further reviewing the earlier input you provided, Content Management > Rendering as XML for BPSS Refinement and Business Agreement, that you > have positioned CAM as an extension point for many things: business > document, transaction assembly, late binding parameters, etc. > And, in last week's meeting you referenced, you further described Figure > 3 [1]. I am uncertain at this point that positioning CAM so broadly > helps realize its potential strength in content assembly. Should we not > separate the business document, content assembly influenced by context > from the transaction patterns, control flow and other aspects defined in > BPSS? My point is that CAM could be used to influence the business > document which BPSS can use to assist in directing the business > process. Your document talks about defining the static setting of a > BPSS and allowing, cart blanche, its redefinition, with some > interaction/interface with BPSS, CPPA and CAM. At this point, we have > allowed an element reference to change the TTP that an external > mechanism such as CAM could be used influence. However, changing the > BPSS to assemble transactions, revise what you call a 'static setting', > and other more complex changes do not account for the restrictions > required to map to defined economic commitments for which BPSS may be > responsible. > > I am uncertain if such a broad approach is warranted at this time. > > [1] See attachement reference above. > > @mm1 > > @drrw
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]