[ebxml-iic] IIC Conf Call Monday,Sept 23th at 10:00AM , and more

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: IIC Conf Call Monday, August 12th at 10:00AM PT (1:00PM ET)

All:

 

1. Minutes of last call attached,

 

2. We need a host for next conf call Monday...

 

3. Attached also, a summary from Pim van der Eijk (OASIS Europe) of teleconf we had last Friday,

about e-Centre initiative from EAN-UK. Yet another ebXML initiative...

We need to follow-up with our test suites!

 

Regards,

 

jacques

>  
Minutes of IIC September 16, 2002
-------------------------------
 
Call info:
---------

Host: GXS , Jeff Eck
Time: Monday Sept 16th, 10am Pacific 
Dial-in number 1-877-434-7266 or 1-301-340-5190 
Meeting ID#    32965 (ebXML) 
Minute taker: Jacques Durand


Present:
--------

Mike Kass (NIST)
Jeff Eck (GXS)
Jaques Durand (Fujitsu)
Pete Wenzel (SeeBeyond)
Hatem El-Sebaaly (IPNet)
Ryan (IPNet)
Steve Yung (Sun)
Monica Martin (DrakeCertivo)


Agenda:
-------

1. test Case material:
- finalizing : test errors, test case depndencies, mesg expressions syntax
- status on: CPA representation (and element referencing in mesg expressions)

2. Conformance Test suite:
- status on: currnent conversion of test reqs in detailed test cases.
- status on: conformance profiles (Jeff)

3. Interoperability Test suite:
- status on: recap sent out by Jacques on iic-interop list (a set of interop test cases 
with test steps details, for initial profile(s))
- status on: comparison with UCC/DGI

4. Deployment templates:
- status on: template doc from Pete.
- input from EAN (Thomas?)



Minutes:
--------

1. Test Case Material: (Edited by Michael Kass)

- A few remaining issues still to fix before proceeding further on MS test case
definitions.
- Several test case verifications really are covered by Schema validation:
shouldn't they be consolidated? redundant with Schema validation of messg envelope?
(We need to look into these. Redundancy is not necessarily a problem,
if it brings us flexibility and autonomy of test cases. Consolidation maybe
tricky - not a V1.0 issue.)
- Some test cases are difficult: hard to implement or even describe with test material.
(We'll address this. test material may provide for plain English descriptions
in some cases.) (e.g. #47) .
- Some very specific tests require system manipulation (e.g. shutdown, for
recovery) cannot be expressed with current test material: need manual description.
- CPA attributes need to be resolved. (We'll propose a simple solution.)
- need to review some tests that are not easy to interpret (e.g. #62)
- Action: We'll try to finalize all these issues this week... becauase they block
work on remaining MS test cases.


2. Conformance Test suite:

- test definition material (above) to be finalized this week
before proceeding further (total 216 test cases... only ~70 have been drafted,
and need to be refined based on latest updates to test material.)
- Conformance profiles need to be agreed upon. (Jacques:)Should be looked at
in the perspective of "certification", supporting few interoperable combinations.
- Jeff proposal: reduced to three levels that are quite consistent 
with Spec core/additional features.


3. MS Interoperability Suite:

- Jacques: latest draft (sent out on iic-interop list) 
currently reviewed by testing group at ECOM, for comparison with their tests.
- status on: comparison with UCC/DGI: Hatem will send update on this.
- Steve: will review latest draft, finalize the basic interoperability
profiles (and check test cases and their steps), check whether the "Ack" 
interop test cases can work well without need to "sniff" on the wire 
(would make the test harness considerably more complex for interop), 
or check MSH logs (hard to require...)


4. MS Deployment templates / EAN guidelines.

- Pete draft doc on template posted by Peter (with jacque's comments)
for broader review.
- The template still needs reformatting. May allow for
definition of several "sub-profiles" of deployment: CPA-related,
MSH-implementation/configuration related, Message-content-related...
Idea is that some options will concern MSH vendor or operating IT,
some options will concern the business users. Some others will have
to be expressed ultimately in the CPP/A. So it may be useful to group
accordingly.
- Nevertheless, this deployment template is focused on MSH: should
not try to cover integrated deployment with BPSS, RegRep, etc. Only
the MSH-related CPA subset will be addressed, even if separately
addressed in same doc.
- some text will be added in table format, pointing at "recommendation"
from the spec, in case some option is "preferrerd".


5. External initiatives.

- ECOM: currently comparing version of our interop tests, with their own.
- Monica: WS-Security is working along a similar approach to ebXML: need a notion 
of deployment templates, implementation guidelines. Our ebXML work has been mentioned
in this committee. To follow.
- teleconf with EAN / "e-Centre" ebXML initiative in Europe (still different from CEN/ISSS...)
Summary from Pim van der Eijk (OASIS Europe) attached.


Reminders:
---------

- Next teleconference planned for Monday, September 23rd, 10am Pacific time.
Now will be weekly until we wrap-up our specs.
 

Jacques Durand
ebXML IIC chair







Conference call on EAN UK ebXML interoperability project
(Friday 13, 2002)
--------------------------------------------------------

Attending:

David Weatherby, e-Centre
Justin Webster, e-Centre
Bolivar Pereira, EAN International
Jacques Durand, Fujitsu, chair of OASIS IIC TC
Pim van der Eijk, OASIS

Note: I have not attempted to give a verbatim report of the dialog,
but instead give a summary of the various discussions.

We started by exchanging information on the various groups and their
activities: 

E-Centre (member organization of EAN in the UK) is running an ebXML
interoperability project with a number of vendors. The project was
initially set up as an ebXML demonstration project for the UK
market. It focuses on ebXML messaging for practical reasons, but the
longer term ambition is to move to application-level functionality as
relevant to e-Centre members.  E-centre is considering setting up
testing facilities to facilitate vendors as a (commercial) service, but
the current project is small-scale and has limited resources. E-Centre
is also involved in work on Core Components and UMM in UN/CEFACT. For
interoperability projects, the ebXML Registry would be the next step
after messaging.

The scope of the project is changing from being mostly UK-centric to
become of use to the wider EAN community.  Some participants in the UK
project have argued for a closer alignment with the Implementation,
Interoperability and Conformance (ICC) Technical Committee, using and
providing feedback to the guideline documents that TC is working on,
and e-Centre very much supports aligning its project with other
initiatives internationally, within EAN and OASIS.

EAN International has recently become an OASIS member to better
integrate its work with other OASIS members working in the ebXML IIC
TC.  The current question is whether or not the e-Centre project
should move into OASIS as well.

The IIC TC work focuses on Conformance, Interoperability and
Implementation (or rather Deployment).

The work on Conformance has produced test suites for ebXML Messaging,
including tools and resources to support automated, routine,
repeatable testing. This is because it is anticipated that routine
testing will be a requirement for production environments, to verify
that ebXML systems continue to work correctly even in a context of
updates of software, setting up relations with new business partners
etc.

The work on Interoperability has focussed on defining basic
interoperability levels and test suites for any levels or user
community, plus profiles that provide information on how to configure
an ebXML service for specific businesses or types of
applications. Third parties, like EAN, should be able to define their
own profile on top of this.

The work on Implementation is now increasingly (as a result of the
work with EAN) being viewed as support for deployment. The generic
ebXML specification will in general offer many options, which in a
given situation will need to be constrained. For example: EAN has
conventions for identifying parties. It therefore makes sense that a
deployment template for EAN applications specifies that <PartyID /> in
ebXML messaging uses those conventions rather than others.

Now that many initiatives are being started to promote and apply
ebXML, the IIC TC wants to support and have liaisons with those
various ebXML related projects, such as this project, a similar
initiative in Asia (NIIC), and the CEN ISSS eBES project that OASIS
supports and that will start later this month (this project was
mentioned but not further discussed).  The goal is to maintain an
agreement on the basic interoperability issues, share test suites
(using the test suite configuration mechanisms designed in IIC), and
therefore support easy deployment (customization for industries or
applications). 

IIC itself does not do any certification. This is left to third parties,
OASIS members or others. The basis test suites should be free and
support self-testing. More complex tests, specific to specific
industries, applications etc. should be done by third parties or
certification authorities.

After these various introductions, we discussed the idea of continuing
the e-Centre ebXML project within OASIS, as a technical activity
closely aligned with the IIC TC.  A main benefit is visibility:
OASIS is very good at promoting its technical work, and could direct 
more media and end-user attention to the participating vendors.

We identified a number of issues that would need to be addressed to make 
this possible:

-) Costs: 
Participation in an OASIS TC requires the participants to be OASIS
members. Not all current participants are OASIS members, so this would
require them make a membership payment. However, not requiring those
companies to become OASIS members would not be fair to the companies
who are (and pay to be) members. OASIS membership also cannot
realistically be argued to be unaffordable given its small-contributor
and individual membership categories.

-) Control:
EAN c.q. e-Centre currently have a lot of influence on the scope and
content of the project. An OASIS TC is a more open environment. Care
would need to be taken to make sure a TC remains focussed on the needs
and requirements of the EAN user community and stays within the
overall framework of EAN standards. 

Next steps:

Pim will meet with Bolivar later this month in Brussels to look at the
various alternatives for moving this forward and to see which (if any) 
of these best meets the various requirements.