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: RE: [ebxml-iic] Minutes and next call April 5th


Title: Minutes and next call April 5th

Jacques and all,

 

   I’ve provided spec references to your itemized list below.  There are a few items

that do not have a spec reference.   This should allow people to quickly get up to speed

on the relevant parts of the spec that may require some additional work prior to voting.

 

Cheers,

Mike

 

 

Please be ready to express feedback on:

A- Script extensions
- filter-results notation.  -  Section  7.1.4.1  and Appendix D (schemas )
- split / join ops – Defined in section 7.1  table 9, section  7.1.1, table 10
- conditional ops, where used. – Section 7.1.8
- exception catching best practice – All tables in the spec
- timing of test steps, timeout vs "sleep". – Two different things completely , described as “stepDuration” section 7.1.3  table 11 and “Sleep”, section 7.1.8, table 32

B- Message store and getMessage semantics
- masking / unmasking the events that are selected. – Section 7.1.4.1
- scope of a store. – Not defined in spec
- time limit for a getMessage op – Defined as “stepDuration”, section 7.1.3, table 11

C-Parameters / variables
- how are they set.. Section 7.1.4.1
- pre-processing model, especially in filters – Section 7.1.3.1 ( for GetMessage )… but not defined for PutMessage

D- Interfaces
- assumed communication model. – Section 3.2.5, assumes an RPC communication model
- how ebMS-independent – Section 3.2.5 describes RPC communication model, ebMS independent..with SOAP binding example
- schema for message data. – Appendix F.. but needs to be explained in the specification text, also need to break apart RPC messages from Test Service ebXML messages ( i.e. make 2 separate schemas )

E- General execution model
- how do we execute an entire test suite. -  No overall semantic definition of how a test suite executes. Just Test Case execution (section 7.1)
- possible outcomes for a test case, meaning for the test suite. – Section 7.1
- when a test has threads that don't join. – Not defined in spec
- best practices for Exception threads?
(e.g. verify we get either an Acceptance or a Reject, but not both?) No examples in spec.  Suggest  creating sample Test Case performing “if”, “then” , “else” to accomplish illustrate handling this particular test case ( since there is no “orJoin”)


 

-----Original Message-----
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, April 01, 2004 9:09 PM
To: ebXML IIC - main list (E-mail) (E-mail)
Subject: [ebxml-iic] Minutes and next call April 5th

 

All:

1. Minutes March 22 attached.

2 Next call:
Time: Monday April 5, 2004, 2pm PT
Host: Fujitsu
Toll - : 1-512-225-3050
Passcode: 89772#
See agenda below, with points to look at...

3. Mike, in order to help people focus on the new features, can you
associate section numbers with each of the features I have listed inthe agenda below? (under A,B,C,D,E)

4. Normally, we should put the spec to vote as Committee Draft by this Monday,
for a 1-week vote period (vote ending April 12).
But if we identify serious-enough issues that need be fixed, what we'll vote on is the
decision to start the vote as soon as a new draft that addresses these issues is released.
This means, some updates may be requested at Monday review,
that will take a couple of days to address, so the new draft is posted on Wednesday,
and the chair will declare the vote open starting Wednesday (for 1 week).

There might also be some non-normative additions (e.g. examples, best practices)
that could be voted later.

Jacques

------------ Agenda April 5th:

1. Review of latest Test Framework draft posted by Mike (Tuesday 3/30)
In particular, we'll review the following points (even if they are settled by now,
their editorial treatment needs review and comments !)
If review overall OK (no major flaw uncovered) I'll put the spec
to vote (email), else we may vote on a list of issues to be addressed
by the editor, and starting the vote as soon as a new draft is posted.

Please be ready to express feedback on:

A- Script extensions
- filter-results notation.
- split / join ops
- conditional ops, where used.
- exception catching best practice
- timing of test steps, timeout vs "sleep".

B- Message store and getMessage semantics
- masking / unmasking the events that are selected.
- scope of a store.
- time limit for a getMessage op

C-Parameters / variables
- how are they set.
- pre-processing model, especially in filters

D- Interfaces
- assumed communication model.
- how ebMS-independent
- schema for message data.

E- General execution model
- how do we execute an entire test suite.
- possible outcomes for a test case, meaning for the test suite.
- when a test has threads that don't join.
- best practices for Exception threads?
(e.g. verify we get either an Acceptance or a Reject, but not both?)

<<IIC_March_22_04_minutes.txt>>



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