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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

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


Subject: [ebxml-iic] 7/31/2003: 4 August 2003 Mtg and Tentative Agenda


Call in details and tentative agenda for 4 August 2003 11 a.m. PT below. 
Provide any comments and additions, thanks.

>Time: Monday 4 August 2003, 11am PT
>Host: Sun Microsystems 
>Toll Free - : 1-866-882-3998
>Toll - : 1-865-525-0769
>Participant code: 9081038
>
>Agenda: 
>1. Status of MS conformance test suite spec. (Mike Kass editor) 
>- review current draft of MS conf test suite, and specific issues:
>. Issue #1: the problem of "app-level" test cases: See those denoted in conformance document by Mike Kass. Be ready to discuss.
>. Issue #2: ordering / partitioning based on config/CPA? (how to avoid too many reconfigs).  Be ready to discuss current list.
>. Issue #3: conformance profiles or levels (detailed content?) - See 28 July minutes.  Three profiles suggested: core, more reliability and full. Suggest a decision.
>. Issue #4: message correlation details: Action to Durand and Kass.
>. Issue #5: check / fix parameter tables: Agreement reached; confirm.
>
>2. BPSS test update (Serm K., Monica M.): 
>- Discuss BSI testing definition.
>- Discuss further idea of a prototype.
>
>3. Implementers corner, and PR: 
>- Drake Certivo test driver status (if Sakach present)
>- IIC members demo (Test Framework, test suites) at XML 2003, 7-12 December
> 
>
===========================================================================================================

>Detailed agenda and actions:
>1. Status of MS conformance test suite spec. (Mike Kass editor) 
>- review current draft of MS conf test suite, and specific issues:
>. Issue #1: the problem of "app-level" test cases: See those denoted in conformance document by M
>. Issue #2: ordering / partitioning based on config/CPA? (how to avoid too many reconfigs)
>. Issue #3: conformance profiles or levels (detailed content?)(please read last minutes, we'll decide)
>. Issue #4: various editorial issues. Differentiate editors from contributors.
>. Issue #5: message correlation details.
>. Issue #6: check / fix parameter tables.
>
>2. BPSS test update (Serm K., Monica M.): 
>- spreadheet from Serm / Monica, BSI testing definition.
>- what cooperation/feedback with/to the BPSS team 
>(emphasis on testing operations).
>- idea of prototype.
>
>3. Implementers corner, and PR: 
>- Drake Certivo test driver status. 
>- KwareSoft question on ErrorURLNotify 
>- presence at AutoTech: who demoes, IIC visibility... 
>- IIC members demo (Test Framework, test suites) at XML 2003, 7-12 December
> 
> 
>[Action Item]: go through this list and reassess them. Pete W. (and Jacques) are
>challenging some, like Req #50: the "manifest" values are actually set by the MSH,
>as the app only decides of the payloads. So in that case, the test case is OK.
>For others, the ability of the test framework to execute the test case is "contingent",
>i.e. the feature to test may manifest depending on the implementation.
>(e.g. the option to use straight SOAP without attacht, for messages with a single payload,
>cannot be tested if impl decides not to.) 
>
>Issue #2: ordering / partitioning based on config/CPA.
>
>[Action Item]: go through current list and see where the discontinuities are, for
>CPA refs. Jacques suggest each test case header could more explicitly point
>to the CPA it uses ("test case" lines of the abstract test suite), instead of
>just relying on the CPAid burried inside the message expression of each step.
>
>Issue #3: conformance profiles or levels. Agreement that :
>Profile #1 covers "core" features,(security, errors, SOAP env)
>Profile #2: #1 + covers mostly reliability,
>Profile #3: "full" conformance (all spec, icluding supprot for ping, 
>status request, multi-hop). Seems odd as a profile, as it is the entire spec.
>(should not be called a profile)
>Question on whether SyncReply modes other than mshSignalsOnly should be
>excluded from Profile #1 (which is the minimal set of mandatory features),
>based on possible evolution of ebMS spec. (Shifting some features from Core to Additional)
>
>[Action Item]: Jacques will ask the ebMS TC to clarify their position.
>
>Issue #5: message correlation details. 
>Jacques and Mike to get closure on the message correlation issue, by email.
>
>Issue #6: check / fix parameter tables. This is related to the correlation
>discussion. We seem to have an agreement on wht to do.
>
>
>2. BPSS test update (Serm K., Monica M.): 
>
>- Questions provided BPSS editing team. ebXML dev list had also some issues on BSI definition...She also sent the BSI definition.  The discussion was brought to BPSS team and feedback is pending.
>- Team provide feedback on what to support in test suite, test framework 
>for transaction state management, req/response activities in BPSS.
>- Team provide comments (to Serm/Monica) on the BPSS spreadsheet (test suite).
>
>3. Other business
>
>- Reg/Rep is drafting some example assertions for our review after 7/24 Reg/Rep TC discussion.  S- Monica: will send out - Monica: Sent ebXML-lite proposal from Covisint. Team provide comments and/or any concerns (such as that is might not be just an ebXML profile, but may be non-conforming with the spec, e.g. if ack mechanism relies solely on sync responses at transport level).
>
>  
>
>------------------------------------------------------------------------
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/leave_workgroup.php
>




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