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

1. roll call

PRESENT 35/28 EXCUSED REGRETS ABSENT

2. agenda review

AOB:
Whether or not to have a telecon next week (given Web Svcs WorkShop)
New phone arrangement

3. approval of 28 March minutes

no comments, approved as is

4. Review Action Items (AIs)


- 1.  Jeff Kay -  Jeff looked at list of issues.  Done
- 2.  Noah to update i41.  ?
- 3.  Henrik - update issue list with Noah's comment (open)
- 4.  DavidF - Talk with JeffK to determine if he is satisfied with scope
      of issues list. JeffK thinks that the issues list, at the outset, should
      contain requirements that are currently met by SOAP 1.1.

      Group feedback:
      Henrik:  Need to do it.  Separate document needed for issues.
      DavidF:  Note that resolved issues remain on list.  Need someone to do it.
      DavidF takes AI to get someone to do this.

- 5. David Clay - start to reconcile 3-way between Module Template, AM, and
     Glossary
     David Clay has been sick, but he's following discussion. AI left open.

http://www.w3.org/2000/xp/Group/1/03/soap-xmlp-terms-01.html

- 6.  In Henrik's inbox (still pending)
- 7.  David Clay
      Paul sent to subgroup
      David C - also digital signature
      He will report more under agenda item #7.
      (AI still pending)

5. Report from spec editors

They had a brief call earlier this week, course of action:
Henrik will put ('Noah's') caveat in status section
Henrik will put in the glossary, but has not yet merged its terminology
into the document text.
????appendix vs spec
????running text with now in section 2 as subsection
Put snapshot of issues list in an appendix and schemas for SOAP 1.1 as
appendix. Ed.s plan to have version ready by Friday.

They are splitting the work between three people, they will merge glossary
into text.

6. The spec ed.s need to merge the glossary into the spec, of particular

concern are the defns of:
- XMLP Handler
- XMLP Node

Goal of this agenda item is to reach concensus on these terms.

[Begin discussion of XMLP Handler.]

Jean-Jacques sent email today, in summary:
  He looked at Henrik's glossary, and summarized the points on Handler. The
  glossary has one definition, and there are three

issues with this defn:
1.  Handler is an implementation aspect
2.  apps not designed for XMLP, but back end app
3.  blocks not targetted to a handler

Henrik proposes to go back to old definition.

PaulD - drop Handler, use only Module
Henrik - SOAP mapping
Clay - calling it an abstraction helps
Henrik - no problem
Anon -- Uncomfortable removing Handler.  Keep it!

Module - def allows separation where module has multiple handlers
Henrik:

David F - things outside our purview

Where Object has data and behavior, Module has blocks and handlers

Need to amend module definition

H: main issue not clear in previous def whether blocks not associated with
   modules
things protocol-like
authentication, soap dsig
specific protocol semantics

other things payload - no "protocol"  e.g., vcard

important to say xmlp processor augmented with functionality - router,
reliability
do this through Modules

(David Ezell joined)

How does it map to handler

should be one behavior style

?? - targetted block - target at module/handler
untargetted blocks -

H:  target at SOAP processor, just a blob of data for next guy, metainfo
    nice to separate data intended for any party w/out notion of active vs
    passive blocks, active = part of module

D:  proposed wording "typically" Processing always associated w/module?

H:  does not define own blocks, just processing for something else valid 
    example of "typically" is difficult is something present in message or not

David C:  no blocks for module, e.g., just add tracking even if

Paul D: scan message for absense of blocks

Henrik: SOAP entries = XMLP Blocks

Targetting hard to map into SOAP

1:1 Handler: Block

Module 1 or more

handler registers a pattern
filter pattern e.g., TREX
pass to handler if pattern match
sender needs to know what to put in message for pattern to match

H:  go away from "dispatching" in processing/implementation environment notion
    of a processor is abstract add things to the abstract processor, i.e., 
    modules

def of module not key to XMLP
WG will not define

DavidF:  Less specific - more abstract is better

FrankD:  write once, run on multiple
. Need to know dispatch mechansim
. vendor independent modules
. plug in
. know that two modules are not stepping on each other

DavidC:  Template also includes "dependencies" to address Frank's concerns
Frank disagrees

Independent evolvability
stepping on each other
need framework

H:  not in WG charter
wire protocol

not APIs

Interop vs Portability

DavidF: (5:01) Need to move on,

Frank: ...transmission or exchange... needs to change
processing once they arrive

drop after ...module.

Processing of what?

An abstraction defined as part of an XMLP module for processing zero or more
Blocks

SOAP Processor dispatch to handler not discussed

Impact on AM document

Module vs Handler
1:1 or more than 1?

[WG ends discussion on XMLP Handler.]

The WG decided:

1. Handler = The abstraction for the processing and/or logic defined by an
XMLP module involving zero or more XMLP Blocks.

2. Module = An XMLP module is a basic unit for the definition of extensions
to XMLP. An XMLP module encapsulates the

definition of zero or more related XMLP blocks and their associated processing
rules. These processing rules are realised in an XMLP handlers.

[WG begins discussionon XMLP Node.]
Jean Jacques
XMLP Node
see Henrik's table
Use node instead of "application" (in SOAP 1.1)
node feels "physical"
need to allow more than one XMLP Node on a physical machine
proposal to drop "node"

transport intermediary - "host" ok

replace Node by Entity?

drop box around app+processor? no

Action to WG: continue discussion on dist-app list

7. AM document -


Mark Jones to catalog issues as they arrive

In the issues document, the spec column ref will say abstract model, and we
will need to highlight the particular section of the AM.

8. Module Template -- postponed until next telcon.

9. AOB

(i) The WSWS conflicts with next week's WG telecon. Chair solicits # who
cannot attend XMLP WG telecon next week? ~10 at WSWS. Chair takes this number 
under advisement.

Publication of the AM doc. Plan was for the WG to review and discuss the AM
doc before publishing on 13 April. If there is no call, then we almost
certainly won't publish on 4/13 and will slip to 20 April.

Hugo is concerned about blackout dates. If we submit for pub by 20 April then
can probably publish by 24 April. But since this is a 1st draft, probably want
to submit < 20 April. Hugo is on vacation that week, so Yves will have to work
on the publication. 
Another question, whether or not to tie spec and AM publications? 
There is no 1st draft of spec yet, so slip AM pub? 
If AM is not published in April will slip until May.
Chair takes under advisement

(ii) Re. Call-in. Intel bridge has changed and is no longer optimal.
Ideally want at least an 800 # in US, plus better for

outside US. Can another company host call? Action to WG: send email to
David F if your company can host call