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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

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


Subject: Re: [ebsoa] Re: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gapbetween MSI and BSI and move on


David:

Not sure exactly what you are implying.  BSI is BSI is BSI.  Does 
someone want to make it into something different now?  If so, I may have 
missed that.

Next thing we will be writing position papers comparing BSI to various 
types of wood ;-0  (if we do, I get "Maple").

D

David Webber (XML) wrote:

>Duane,
>
>As I said earlier - its clear we have moved a long way from the original
>early work - and this all needs updating.
>
>DW
>
>----- Original Message ----- 
>From: "Duane Nickull" <dnickull@adobe.com>
>To: "Dale Moberg" <dmoberg@cyclonecommerce.com>
>Cc: "Monica J. Martin" <Monica.Martin@Sun.COM>; "David Webber (XML)"
><david@drrw.info>; "Sacha Schlegel" <sschlegel@cyclonecommerce.com>; "ebXML
>BP" <ebxml-bp@lists.oasis-open.org>; <ebxml-msg@lists.oasis-open.org>;
>"ebsoa" <ebsoa@lists.oasis-open.org>
>Sent: Friday, February 04, 2005 4:37 PM
>Subject: [ebsoa] Re: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap
>between MSI and BSI and move on
>
>
>  
>
>>Dale:
>>
>>No problem, let me explain.  BSI is an abstract, all inclusive
>>architectural term used to describe how another party can engage with
>>the party.  It was used rather than tying the architecture specifically
>>to CPP, CPA, BPSS and anything else.  We used this for a number of
>>reasons.  One was at the time, it was clear that Core Components would
>>not produce Schemas or other payload metadata.  Such is clearly needed
>>at the concrete level to build an implementation.  Also BPSS told the TA
>>group that they were not working on a serializable format for BPSS,
>>something that has since been corrected.   It was a catch-all concept
>>(business items, technical parameters, etc.) but no explicit set of
>>parameters was named to make up the concept.
>>
>>Instead of interfaces to java classes (which do usually use the
>>convention of the class name), think of it like an abstract java class
>>that is not for implementation.  It gets implemented using other
>>concrete classes.  In a UML class view diagram, when one uses the
>><<abstract>> stereotype, I think the convention is not to duplicate the
>>abstract class name in the concrete class name.
>>
>>To implement the concept, one would inherit the concept into their
>>specific ebXML architectural model, then specialize and elaborate it
>>using things like CPA, BPSS, SOAP, WSDL etc. In short, it is best
>>described as a component of a reference model that architecture, even
>>though it does talk about it within the architecture quite a bit.
>>
>>There is no really need to worry about it unless someone starts trying
>>to discuss building a concrete BSI spec ;-)
>>
>>Duane
>>
>>
>>
>>Dale Moberg wrote:
>>
>>    
>>
>>>Hi Duane,
>>>
>>>It seems a bit confusing to me to say that something that implements an
>>>interface cannot use the name of the interface when indicating what
>>>interface it is implementing.
>>>
>>>E.g., java classes implement interfaces and use the name of the
>>>interface to indicate the interface(s) so implemented.
>>>
>>>Puzzled what your point is. Too abstruse for me. Not going to worry
>>>about it unless you clearly explain the badness.
>>>
>>>If there is a gap, I guess it means that there needs to be a realignment
>>>of the outgrown 1.04 draft with what is going on. Too bad we don't have
>>>a replacement yet :-)
>>>
>>>Dale
>>>
>>>
>>>-----Original Message-----
>>>From: Duane Nickull [mailto:dnickull@adobe.com]
>>>Sent: Friday, February 04, 2005 1:53 PM
>>>To: Monica J. Martin
>>>Cc: David Webber (XML); Sacha Schlegel; ebXML BP;
>>>ebxml-msg@lists.oasis-open.org; ebsoa
>>>Subject: Re: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap
>>>between MSI and BSI and move on
>>>
>>>
>>>
>>>Monica J. Martin wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>mm2: Education is always an opportunity Duane. Remember that the/these
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>>>interface(s) may actually become physical in a deployable logical
>>>>environment. I believe our original text surrounding this relationship
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>>>was clear after all. However, I will in more detail review the many
>>>>posts last night and today to see what can be improved upon in the
>>>>text that was agreed to yesterday morning. Thanks.
>>>>
>>>>
>>>>        
>>>>
>>>Monica:
>>>
>>>When they become physical, they should be called CPA, eb MS and BPSS.
>>>
>>>There is no concrete BSI.  BSI is an abstract concept - it would be very
>>>
>>>bad practice (and most confusing) for someone to develop a concrete
>>>thing and give it the same name.
>>>
>>>Education attempt:
>>>When modeling, BSI is an abstract concept.
>>>When implementing, can be done via CPA, MS and BPSS.
>>>
>>>Duane
>>>
>>>
>>>
>>>
>>>      
>>>
>>-- 
>>***********
>>Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
>>Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
>>Adobe Enterprise Developer Resources  -
>>    
>>
>http://www.adobe.com/enterprise/developer/main.html
>  
>
>>***********
>>
>>
>>
>>    
>>
>
>
>  
>

-- 
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Adobe Enterprise Developer Resources  - http://www.adobe.com/enterprise/developer/main.html
***********



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