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] Re: ebBP 2/7/2005: Updated Combined Summary of BSI-MSI



>> mm1: Section 4: Language Overview
>> ================
>> FROM:
>> The BSI is completely separate from the Message Service Interface 
>> (MSI). In particular an MSI MAY be used without a BSI. A CPA, which 
>> contains a reference to a ebBP definition serves as the basis for the 
>> configuration of the BSI to enforce the protocol and semantics of the 
>> ebBP definition, as depicted in Figure 1. 
>
> nickull: I would caution you that there are companies who have prior 
> use of the term "MSI" in the context of a programmers interface to 
> ebXML MS software.  Accordingly, it may be subject to trademark and/or 
> copyright.  I cannot verify this any further at this time.

mm2: So they have a copyright that was originally in the ebMS v2.0 
specification? Is it then a valid copyright (I don't know but am only 
asking) if existed in the ebMS specification under OASIS copyright? 
Perhaps this is a question for OASIS, Duane.

> Discussing concrete interfaces also violates one of the core 
> principles of ebXML in the architecture which was not to impose any 
> specific implementation style *where unnecessary* upon those building 
> software.  Prescribing interface based design is one constraint that 
> is not in alignment with either the core requirements or architecture 
> of ebXML.

mm2: These references are described logically (which was pointed out 
multiple times in the email discussions that occurred last week). I 
would propose a specific statement that explicitly states this. As an 
ancillary note, there are multiple times that interfaces are discussed 
or referenced in the 0.83 version of the ebXML architecture document.

> Accordingly, it may be a better idea to discuss this as the 
> association with the messaging component of the architecture, not the 
> interface.  Align the functionality abstract of the implementation.  
> Interface descriptions are probably better handled in a JSR type group 
> than the core standard.

mm2:  The logical boundary could be described as such and be broadly 
understood as an 'interface.' Thank you for your comments.



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