Re: [ebxml-jc] ebxml-jc 1/4/2006: Conformance or CompatibilityReferences Across Specs

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

In today's call, Pim, Kathryn and I discussed what possible minimal 
language could be proposed. We recognize that the focus of any given 
specification and its area of interest may differ. Therefore, Pim 
suggested we consider some minor language changes by specification.  I'd 
encourage your comments so this could be brought up as a discussion item 
in the different TC groups. As you know, the JC is supposed to 
coordinate across the groups, understanding that any given TC may choose 
otherwise. Any changes are focused on putting a possible and consistent 
context around whether the specs can (with no requirements inferred) be 
used together.  Thank you.

> mm1 1/4/2006: In our call 8 December 2005, Jacques, Kathryn and I 
> started to discuss what common language re: compatibility we could 
> have across the original set of ebXML specifications.  I had posted a 
> question to the jc on 7 December 2005 [1].  Jacques indicated that the 
> Committee Draft for ebMS v3.0 included language too. Here is what 
> language we currently have:
>
> ebMS v3.0 (0.7) [2]
>
>    "The ebXML infrastructure is composed of several independent, but
>    related, components. Specifications for the individual components
>    are fashioned as stand-alone documents. 

mm1: Suggest minor change to:

     From the onset, the ebXML framework has been composed of several
    independent, but related or aligned, components. Specifications for
    each component can be used individually, composed as desired, or
    integrated with other evolving technologies.

> Each specification is self-contained, meaning a conforming 
> implementation may ignore other
>    ebXML specifications. 

mm1: Suggest minor change to:

    Each specification is self-contained, as it pertains to a conforming
    implementation.

> Some references and bindings across ebXML
>    specifications should be interpreted as integration help, not
>    requirement to integrate. 

mm1: Suggest minor change to:

    Some references and bindings across ebXML specifications may be
    interpreted as guidance rather than as requirements to integrate.

> This applies to ebMS also, which may refer
>    in particular to CPPA specification, though does not require its
>    use: ebMS relies on a concept of "Agreement" the concrete
>    representation of which (e.g. CPA or other configuration
>    information) is left for implementors to decide."

mm1: Suggest minor change too:

    This applies to ebMS also, which may refer to or allow an
    implementation choice to use the CPPA specification: ebMS relies on
    a concept of "Agreement" the concrete representation of which (e.g.
    CPA or other configuration information) is left for implementors to
    decide.

> ebBP v2.0.1 [3]
>
>    "As with all the other specifications in the ebXML framework, an
>    ebBP process definition may be effectively used with other
>    technologies. From the onset, these specifications have sought to be
>    aligned as much as practical and capable of being composed together
>    and of being used with other technologies. 

mm1: Add (to align with ebMS proposed draft language):

    The ebXML framework has been composed of several independent, but
    related or aligned, components. Specifications for each component
    can be used individually, composed as desired, or integrated with
    other evolving technologies.

> That flexibility and composability are important aspects not only to 
> the adoption of
>    these standards but their effective use and successful deployment
>    into heterogeneous environments and across domains.  In the context
>    of this technical specification, Business Collaborations may be
>    executed using the ebBP process definition and/or used with other
>    technologies. As it relates to the other specifications in the ebXML
>    framework, an ebBP process definition supports the loose coupling
>    and alignment needed to execute Business Collaborations. This
>    specification may also be used when several other software
>    components are used to enable the execution of Business
>    Collaborations. One example is the use of web services mapped to
>    business transactions activities.  The ebBP technical specification
>    is used to specify the business process related configuration
>    parameters for configuring a BSI to execute and monitor these
>    collaborations. The ebBP business semantics and syntax are also
>    well-suited to enable definition of modular process building blocks
>    that are combined in complex activities to meet user community needs."

> ebRegRep 3.0 (RIM and RS): None 

mm1: Since there are no references perhaps that TC will consider some 
descriptive text in the Introduction (Section 1) such as:

     From the onset, the ebXML framework has been composed of several
    independent, but related or aligned, components such as ebXML
    Registry. Specifications for each component can be used
    individually, composed as desired or integrated with other evolving
    technologies. 

> ebCPPA v2.1 working draft
>
>    "As defined in the ebXML Business Process Specification
>    Schema[ebBPSS], a /Business Partner/ is an entity that engages in
>    /Business Transactions/ with another /Business Partner(s)/.

mm1: To generalize because the CPP/A has provided extensibility herein, 
suggest change to:

    In a Business Process Specification, a Business Partner engages in
    Business Transactions with other Business Partner(s).

> The /Message-/exchange capabilities of a /Party/ MAY be described by a
>    /Collaboration-Protocol Profile (CPP)/.  The /Message-/exchange
>    agreement between two /Parties/ MAY be described by a
>    /Collaboration-Protocol Agreement (CPA)./  A /CPA /MAY be created by
>    computing the intersection of the two /Partners/' /CPPs.  /Included
>    in the /CPP/ and /CPA/ are details of transport, messaging, security
>    constraints, and bindings to a /Business-Process-Specification/ (or,
>    for short, /Process-Specification/)/ /document/ /that contains the/
>    /definition of the interactions between the two /Parties/ while
>    engaging in a specified electronic /Business Collaboration/.
>
>    This specification contains the detailed definitions of the
>    /Collaboration-Protocol Profile/ /(CPP)/ and the
>    /Collaboration-Protocol Agreement /(/CPA)/.
>
>    This specification is a component of the suite of ebXML
>    specifications." 

mm1: Change proposed to:

     From the onset, the ebXML framework has been composed of several
    independent, but related or aligned, components. Specifications for
    each component can be used individually or composed as desired.

> Can we get to some minimal or common text that recognizes the business 
> benefit of compatibility between these specifications? I think updates 
> need to be made to CPPA, considered for addition in RegRep, and 
> possibly reworked in ebMS.  Jamie Clark was involved in helping guide 
> the language in ebBP. 
> Note, I had questioned the language specifically ('may ignore....') in 
> the ebMS Committee Draft. I raise the same concern again.
>
> Thanks.
>
> [1] Query on compatibility: 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-jc/email/archives/200512/msg00003.html 
>
> [2] ebMS: 
> http://www.oasis-open.org/committees/document.php?document_id=15688&wg_abbrev=ebxml-msg 
>
> [3] ebBP: 
> http://www.oasis-open.org/committees/download.php/16058/ebxmlbp-v2.0.1-Spec-pr-r03-en.zip 
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php