Minutes of 2001-04-25 XMLP WG teleconference held on 25 April 2001

1. ROLL CALL

PRESENT 34/29 EXCUSED REGRETS ABSENT

2. AGENDA REVIEW

* Minutes from last week being finalized, so skip item 3
* Item 5 Agreed to make go/no decsion on abstract model description
* Item 6, If we publish docs then we need to resolve the issues, quite large
   number of issues, need to prioritize
* Item 7. Have postponed several times conformance proposal - need to work on
  it during this call

3. REVIEW OF MINUTES IS POSTPONED

4. ACTION ITEMS


* Item 1 Noah - Completed last week
* Update issue list - Henrik to do, however is not yet finished as Henrik is 
  waiting for it to be republished on the public list. Action - Hugo to update
  public list. Henrik will then update. David Fallside and Henrik are to give
  information to Hugo off-line.
* Action items 3&4. No progress, remain open
* Action item 5. JackK & Jeff Kay. EricJ to work with Jeff to make sure there
  is progress.
* Action item 6. (Do we keep separate header and body blocks) Mark Jones.

  Mark was asked at the previous telconf to close issue 82, since a
  workaround existed.
  However, Hervé Ruellan later in the week brought the issue again
  on the mailing list, pointing to requirements (simplicity &
  resource constraint devices) that he thought were not completely
  satisfied by the proposed resolution.
  Mark added the current workaround was "less than ideal". He proposed
  to reopen the issue, and to add a link to Hervé's mail.
  Jean-Jacques added that Hervé had also found a further scenario that
  would cause problems.
  Resolution:
  - mark the issue as pending or postponed (from close)
  - add a link to Hervé's mail
  - modify the resolution to say something like "to be revisited
    during the design phase".

* Action item 7. Done.

6. MOVING FORWARD

David F: Moving forward with the issues list. We have a large number of issues.
  Even within design issues there are many and we need to prioritise these. 
  Would like to get a general sense of peoples opinions now on the call. Also 
  would like to get a small group together to confer and make a proposal on 
  which issues to tackle first. Opens the floor.

Henrik: 3 categories: Editorial; Abstract Issues related to Modeling process; 
  More concrete design issues. Having been round the requirements loop and 
  modeling loop, suggest we focus on some more concrete design issues. 

Frank D: Does that include doing some preliminary implementation to 
  demonstrate that we understand these issues.

Henrik: Don't quite understand?

Frank D:  

Frank D: Would like to focus first on MustUnderStand and Actor. Would like to
  have pointer to implementation that do it right.

Henrik: Not sure it is appropriate to single out an implementation. Would be
  better to reference a body of expertise.

David F: Can we return to prioritising issues.

Frank D: High priority to MustUnderstand and Actor.

....

Frank D: I actually believe that MustUnderstand and Actor will lead us back to
  the abstract stuff.

Noah: I think that regardless of abstract or concrete these two issues will
  take us to other places like message path and processing order. I would be
  happy to start with some small number of issues, but we must allow ourselves
  to think outside the strict scope of the issue to discuss related issues.

Henrik: That's is the intent.

Noah: ????

Glen: I very ???

Paul C: Want to support Franks notion of doing some notion of doing some up
  front testing based around sample inputs and outputs.

Glen: I think that's a great idea.

Paul C: This is exactly what the new QA activity is trying to encourage WGs 
  to do.

Frank D: This is fine. If we have some notion of inputs and required outputs.

Mark N: I agree with Henrik's notion that we need to get our feet wet.

David F: Noah, can you comment on this notion of defining inputs and outputs.
  You expressed some concern that we might focus too narrowly on particular
  concrete issues and 'box' ourselves in a way that prevents us addressing 
  other issues in a coherent way (paraphrase).

Noah: Hmmm.... more concerned that we address issues in a coherent way.

Paul C: Here's the query; heres the query response... etc.

Noah: ...we need to discuss all this stuff so that we understand these layers.
  We need to leave ourselves some freedom over where we do some slicing. ...
  Sign this message implies that the we might have to manipulate this message.
  May at some point wish to 

Mark N: I think its a good idea to do that. A concern is that the SOAP dev 
  community is very active and folks are using SOAP in a production 
  environment. I'm concerned that we be careful in putting test case to that
  community.

Frank D: I'd like to make a proposal about how we go forward with this with
  a sender/receiver and two intermediaries and define exactly how messages pass
  through such a set up.

David F: Sounds like one of our usage scenarios.... I think Franks suggestion
  is a good one. What I'm proposing to do over the next couple of day is to
  assign owners to the relevant issues in the list. As stated in the agenda
  for a few names for people to work with me to come up with a proposal.

John Ibbotson, Henrik, GlenD, Mark Nottingham, Marc Hadley volunteered.

7. CONFORMANCE PROPOSAL

David F: Hugo please walk us through it and its status

Hugo: Where did this proposal come from.... basically there is a requirement
  that states that we need to be able to test the conformance R302. Also at CR
  stage we need to convince the director that the specification works. 
  Standard way is to present two interoperable implementations... but that
  really doesn't cover conformance. Came up with the idea that we need to come
  up with some test cases and tools...

Noah has suggested that we might not want to test a generic XMLP implementation
  - we might want to test for gross errors. Also, the charter places no 
  obligation on us to provide an implementation.

Noah: ... lets think about TCP streams. It would be a big mistake to mandate
  a sockets API, however it does talk in more abstract terms about a 
  bytestream. We want to talk in similarly abstract terms... Whether it is in 
  the perview of the WG to specify what the test rigs look like... 
  I'm somewhat doubtful.

Hugo: I'm concerned about the CR stage and our ability to test for a few 
  well-behaved things.

David F: One of the suggestions in earlier conversations were input/output 
  pattern... how do you think such a thing would fit into a conformance spec.

Hugo: That sounds about right.

Henrik: Isn't it more like a sequence of test suites. Some defined tools that
  you can put the input in crank the handle and get the output out...

Vidur: In think this is more like a validator... 

David F: ????

Noah: If I think about the TCP thing, I think about a bytestream... what I
  think we can do is describe some more abstract notion of the test....
  doesn't solve everything... must really be careful to do nothing to preclude
  simple focussed implementations.

PaulC: If Noah is right then the conformance statements in our spec must be 
  stated in a way that is is sensitive to these devices.

Henrik: I definitely think that this is something that we have to keep in the
  test suites, not the conformance requirements.

8. AOB

TELCON CANCELLATIONS
David F: Had no (serious) email on the proposal....

Paul C: I think it quite reasonable to cancel a telecon after a F2F... and for
  the chair to schedule a vacation at that time.

David F: Please let me know of other potential cancellations that might 
  come up.

Jean-Jacques: What about next week in HK...

David F: Well I'm proposing to get up at 4am in HK and run the call.

NEXT F2F
Noah, Paul C et al: transport issues in France due to national holiday in
  France. They will be taken to the list.