Minutes of 2001-04-04 XMLP WG teleconference held on 04 April 2001
1. roll call
- Active Data Exchange Richard Martin
- Epicentric Julian Kumar
- Akamai Technologies Mark Nottingham
- AT&T Mark Jones
- AT&T Michah Lerner
- Canon Jean-Jacques Moreau
- Compaq Yin-Leng Husband
- DataChannel Brian Eisenberg
- Engenia Software Eric Jenkins
- Ericsson Research Canada Nilo Mitra
- Fujitsu Software Corporation Kazunori Iwasa
- Hewlett Packard David Ezell
- IBM John Ibbotson
- IBM David Fallside
- IDOOX Jacek Kopecky
- Jamcracker David Orchard
- Microsoft Corporation Henrik Nielsen
- Mitre Paul Denning (Scribe)
- Mitre Marwan Sabbouh
- Novell Scott Isaacson
- Oracle David Clay
- Philips Research Yasser alSafadi
- Philips Research Amr Yassin
- Rogue Wave Murali Janakiraman
- Rogue Wave Patrick Thompson
- Software AG Michael Champion
- Sun Microsystems Chris Ferris
- Sun Microsystems Marc Hadley
- Tibco Frank DeRose
- Tradia George Scott
- Vitria Technology Inc. Waqar Sadiq
- W3C Yves Lafon
- W3C Hugo Haas
- WebMethods Randy Waldrop
- Xerox Ugo Corda
- Allaire Glen Daniels
- SAP AG Volker Wiechers
- Epicentric Miles Chaston
- Active Data Exchange Eric Fedok
- Allaire Simeon Simeonov
- Canon Herve Ruellan
- Compaq Kevin Perkins
- Engenia Software Jeffrey Kay
- Fujitsu Software Corporation Masahiko Narita
- IBM Fransisco Cubera
- IDOOX Miroslav Simek
- Microsoft Corporation Paul Cotton
- Oracle Jim Trezzo
- SAP AG Gerd Hoelzing
- Software AG Dietmar Gaertner
- Tradia Erin Hoffman
- Vitria Technology Inc. Richard Koo
- DevelopMentor Martin Gudgin
- Lotus Development Noah Mendelsohn
- Hewlett Packard Stuart Williams
- Cisco Krishna Sankar
- Commerce One David Burdett
- DaimlerChrysler R. & Tech Andreas Riegg
- DaimlerChrysler R. & Tech Mario Jeckle
- Data Research Associates Mark Needleman
- DevelopMentor Don Box
- Group 8760 Dick Brooks
- Intel Randy Hall
- Library of Congress Ray Denenberg
- Matsushita Electric Ryuji Inoue
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- OMG Henry Lowe
- Bowstreet James Tauber
- Bowstreet Alex Ceponkus
- Commerce One Murray Maloney
- Informix Software Soumitro Tagore
- Informix Software Charles Campbell
- Interwoven Ron Daniel
- Interwoven Mark Hale
- IONA Technologies Eric Newcomer
- IONA Technologies Oisin Hurley
- Library of Congress Rich Greenfield
- Netscape Vidur Apparao
- Netscape Ray Whitmer
2. agenda review
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.
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
David Clay has been sick, but he's following discussion. AI left open.
- 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
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
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
authentication, soap dsig
specific protocol semantics
other things payload - no "protocol" e.g., vcard
important to say xmlp processor augmented with functionality - router,
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.,
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
stepping on each other
H: not in WG charter
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
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.]
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.
(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
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