Re: [ebxml-bp] [ebBP] 4/30/2004: Keeping the Momentum for v2.0 [RSD]

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>mm1: (from notes) In addition, we will have the following either tailored TC or special
>  
>
>>sessions over the next two weeks for:
>>
>>    * Conditionality of attributes: What attributes should be changed to
>>      elements to allow for conditionality. What are the parameters for
>>      conditionality (offshoot from our discussion on late binding and TTP).
>>    
>>
>Webber: This is *exactly* the ugly side-effect that I strongly cautioned we should
>be avoiding.   This will cause havoc and chaos across the whole structure.
>  
>
mm1: David this is not the context or transformation but the process 
specifying whether or not those values can be changed and when. The 
latter is clearly within the scope of ebBP.

>I understand member implementers need to have a "quick-fix" for their
>time-to-perform issue, but then having this influence the entire schema,
>and have to support this in-perpetua - is exactly what we do not need -
>especially with attendent interoperability issues.  This can potentially
>hamstring BPSS in one stroke.
>  
>
mm1: Believe me this is not a quick fix but a recognition of the 
business level requirements placed on process definition itself. This 
does not preclude CAM or another mechanism usage.

>The long term solution is a consistent context mechanism that works
>seamlessly with elements and attributes.  We already have this
>designed and detailed.  Obviously this requires a context aware
>software component - and I understand that managers never
>want anyone developing more code.  However - since the code
>for this is already available as open source - there is no severe
>development barrier here.
>  
>
mm1: David, these conditionality definitions relate to the process 
itself not the mechanism that applies them. The process definition has 
to state whether or not the element can be changed and when. How that is 
implemented is not being specified.

>So in summary - context mechanism - good; re-wiring our entire
>schema structure - not good.
>
>Thanks, DW
>
>  
>