Minutes of 2001-04-11 XMLP WG teleconference held on 11 April 2001
1. Roll Call:
- Active Data Exchange Shane Sesta (Scribe)
- AT&T Mark Jones
- Bowstreet Alex Ceponkus
- Cisco Krishna Sankar
- Compaq Yin-Leng Husband
- Data Research Associates Mark Needleman
- Engenia Software Jeffrey Kay
- Hewlett Packard David Ezell
- IBM David Fallside
- IBM Doug Davis
- IDOOX Jacek Kopecky
- Library of Congress Ray Denenberg
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Paul Cotton
- Microsoft Corporation Henrik Nielsen
- Mitre Paul Denning
- Netscape Vidur Apparao
- Philips Research Amr Yassin
- Rogue Wave Murali Janakiraman
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- Vitria Technology Inc. Waqar Sadiq
- W3C Yves Lafon
- Xerox Ugo Corda
- AT&T Michah Lerner
- Bowstreet James Tauber
- Compaq Kevin Perkins
- Hewlett Packard Stuart Williams
- IDOOX Miroslav Simek
- Library of Congress Rich Greenfield
- Philips Research Yasser alSafadi
- Rogue Wave Patrick Thompson
- Software AG Dietmar Gaertner
- Sun Microsystems Chris Ferris
- Vitria Technology Inc. Richard Koo
- W3C Hugo Haas
- Lotus Development Noah Mendelsohn
- Active Data Exchange Richard Martin
- Akamai Technologies Mark Nottingham
- Canon Jean-Jacques Moreau
- Canon Herve Ruellan
- DaimlerChrysler R. & Tech Andreas Riegg
- DataChannel Brian Eisenberg
- DevelopMentor Martin Gudgin
- Engenia Software Eric Jenkins
- Epicentric Julian Kumar
- Ericsson Research Canada Nilo Mitra
- Fujitsu Software Corporation Masahiko Narita
- Fujitsu Software Corporation Kazunori Iwasa
- Group 8760 Dick Brooks
- IBM John Ibbotson
- Intel Randy Hall
- Interwoven Mark Hale
- Jamcracker David Orchard
- Macromedia Simeon Simeonov
- Macromedia Glen Daniels
- Mitre Marwan Sabbouh
- Netscape Ray Whitmer
- Novell Scott Isaacson
- OMG Henry Lowe
- Oracle David Clay
- SAP AG Gerd Hoelzing
- Tradia George Scott
- Tradia Erin Hoffman
- WebMethods Randy Waldrop
- Commerce One David Burdett
- Commerce One Murray Maloney
- DaimlerChrysler R. & Tech Mario Jeckle
- DevelopMentor Don Box
- Epicentric Miles Chaston
- Informix Software Soumitro Tagore
- Informix Software Charles Campbell
- Interwoven Ron Daniel
- IONA Technologies Eric Newcomer
- IONA Technologies Oisin Hurley
- Oracle Jim Trezzo
- SAP AG Volker Wiechers
- Tibco Frank DeRose
2. AGENDA REVIEW.
David F. stated that we would skip agenda item 3, approval of 4/4 minutes and
table that item for next week.
David F. described agenda item 5, indicating that the AM items appended to the
agenda which were unassigned or would be underrepresented in this
telecon must be reviewed and possibly reassigned.
NO "other business" items were raised for addition to the agenda.
3. Item tabled for next week.
4. ACTION ITEM REVIEW
Action items below were discussed in order based on the action item list.
Action item 1 - Henrik had not received the updates on this item from Noah
yet, could not confirm whether or not Noah had sent him the updates,
so the action item was marked PENDING.
Action item 2 - Marked as PENDING per item 1.
Action item 3 - David Clay sent regrets. It was asked if anyone could speak
on this. Paul Denning noted that he had worked within the group but
did not think that he or anyone but DavidC could fully speak for this
item. Item left PENDING.
Action item 4 - Henrik to send comments - Item COMPLETED.
Action item 5 - David Clay to define "module," - Item left PENDING.
(see item 3.)
Action item 6 - David F. indicated that it had been decided that someone was
needed to populate the issues list generated by requirements which ARE
met by the SOAP 1.1 spec. Item was assigned to Jacek Kopecky and
Jeff Kay to populate the issues list appropriately.
5. ISSUES AGAINST THE ABSTRACT MODEL (AM) DOCUMENT
Mark Jones was asked to give descriptions of the issues, so that each could
be discussed and assigned as appropriate.
Within the context of the discussion below, it was clarified that the
intent was to assign and act upon only issues which impacted the
publication of the AM document.
[Issue numbers used in these minutes refer to the order of the issues
appearance in the telcon agenda.]
Mark J. - The first two issues are called out in the AM doc issues section,
the group felt these issues needed to be brought back to the WG,
they are unassigned. Issue 1 refers to the debate about the role of
targeting blocks/processing WITHIN the envelope, and whether routing
is a function handled within the envelope or not. How does routing
happen? Waqar - commented, volunteered. OWNER ASSIGNED: Waqar
Per similarity to 1, Waqar was suggested.
Mark J - Discussion from last week may have resolved issue 2. He will clarify
enough for AM spec to reach publication. Thus, OWNER ASSIGNED:
Mark J. - to clarify question, this is a design issue, questioning whether we
should distinguish header blocks from footer blocks, or just have
"blocks," which are "mixed up." SOAP does explicitly distinguish.
Mixed anon discussion ensued. Comments that serializing return messages when
independent handlers perform on header/body blocks is an issue.
Mark J. - we say that an intermediary should be able to identify and perform
on a subset of blocks which were targeted for them, must a handler
parse which blocks are meant for it? This may be a general design
issue, but may not stand in the way of publication.
Henrik - not sure that this is an issue. The spec says that we have to be
able to syntactically separate or intermingle header and body blocks.
SOAP says that you have a mechanism for sending body and headers,
SOAP does allow intermingling, handleable as a special case of
headers. Abstractly, does not see an issue. There of course might be
a buffering issue in some cases but it is based on the semantics of
the features you are trying to serve.
Mark J - Are you saying that you could dispense with the idea of a separate
body to allow "intermingling?"
Henrik - some things at the [handwriting issue here, my apologies - Shane] may
be needed, could
Mark J. - Can intermediaries insert header blocks?
Henrik - we do not say that
Mark J. - If there is a distinction, buffering will be required
Henrik - what I would like to see is an example which shows that these is an
David F. - What is the origin of this issue?
Mark J. - It looked to the subgroup like the distinction [between header and
footer blocks] was just "syntactic sugar," not needed in the
ABSTRACT model design.
David F. - perhaps it is not clear that this is an issue.
Mark J. - see section 3.2, it seems there is a distinction in the document of
header and body in some of the language
Mark - do we need use cases, perhaps this is a farther-reaching issue than the
AM? For example where the recipient of many blocks might need to write
a header AND footer blocks which would naturally require some
David F. - do we change the design at this point? We have a requirements spec,
SOAP, and use cases already. There has already been a "high bar"
set by the requirements and SOAP.
Mark J. - do we take SOAP to be a "high bar" basis for our design moving
David F. - YES, the AM is meant to be an abstract description of what
Mark - this issue was a suggestion for the simplification of SOAP's design.
What do we do with improvement suggestions?
David F. - We need a good use case to show compelling need for an improvement.
Mark J. - is not simplification and clarity good [an improvement] on its own
David - Re-cast this as a usage scenario, or see if it is encompassed by one.
We will consider applying this if it is needed to help SOAP meet a USE
CASE requirement. TO DO FOR MARK JONES - SEE IF THIS FITS AN EXISTING
Mark J. - are usage scenarios a closed set?
David F. - the list is not set in stone, but we need to be mindful of
Anon - S21 may fit this. [Some agreement that it pertains well to the
resultant buffering issue.]
David F. - is resolution of this issue required for the publication of the
Mark J. - It sounds like the AM will inherit the header/body structure from
David - We will give it to Mark to check this against F21, and will remove it
as an AM issue.
ISSUE 4 -
Mark J. - This concerns message construction. It may impact serialization
issues, passing of blocks... The AM does not say much about whether
XMLP can construct..
Vidur - This is an implementation detail, not an AM issue, no?
Mark - yes, we have just a send primitive, is that the model
Henrik - yes, the handler is abstract, this is just an API/impl. issue
Mark J. - Well, the question was about multiple handlers constructing a
David F. - Asks Paul Cotton for his advice in his role as Chair of Query WG:
Should we include this and resolution in the DOC publication?
Paul Cotton Advisor - Yes, it is always helpful to include such, inclusion
will help pre-empt such questions after publication.
David F. asks for a volunteer to write the rationale for the resolution, and
will include the originator of the issue in the list with the
Vidur - volunteers to craft the message to be logged as the response.
RESP FOR ACTION : VIDUR
Ray - The second part of the issue is resolved, but not the first part.
Paul - Are there ways of specifying where blocks go?
Anon comments, editorialized: Yes, this is implied : Messages CAN BE FORMED.
WHERE they are formed is an implementation issue, as is HOW they are
Paul - These are abstract operations, the answer is that no abstraction for
CONSTRUCTION is needed.
ISSUE 5 -
Mark volunteers to take this issue, STUART may have already have a resolution.
Mark will track.
ISSUE 6 -
Mark J. - Chris' question is, if an intermediary has inserted a block, which
faults later in the chain, where does the fault flow back to?
Henrik - I can think of several NON request/response scenarios where this
issue is or is not decided based on the binding. [to the delivery
ANON - What does SOAP do?
Henrik - SOAP reports that there was a fault, not what to do with it.
It includes a "suggestion" in the spec for the HTTP binding.
ANON - The destination for reporting of faults is decided in implementation
based on needs and the binding.
Mark J. - Is this underspecified in SOAP, should it be more specified?
We have no general fault reporting guideline.
Henrik - In SOAP, you have a URI as part of the fault action, so you KNOW
where it occurred, and can handle it.
Mark J. - Can an application just target who should get the fault message?
Henrik - SOAP says, "this is how to report a fault," it does not require what
you do with it.
Anon - The receiver doesn't know who is the originator of a given block,
unless it is explicit in the block. [There was acknowledgement and
general agreement on this point - Shane]
ACTION ASSIGNED - Paul/Henrik to write up an explanation of the "out of scope"
resolution to this issue.
ISSUE 7 -
Mark J. - This concerns the Corrolation.Messageref parameter. Stuart needs to
craft an EDITORIAL correction to clarify the AM description.
Believe that Stuart has already clarified via discussion, is just an
editorial action to get it into the AM.
David F. - could someone else look into that discussion and perform editorial
clarification to the correlation.messageref parameter description
based on the discussion text?
Mark - when will comments/editorial issues be closed? Can this wait for
David F. - it has not yet been decided when, I think that we CAN leave it for
ACTION ASSIGNED - Stuart to perform editorial clarification for .messageref
ISSUE 8 -
David/Mark call for clarification on this issue, it is from Ray.
Ray - I felt that it might be a weakness in the model to abandon guidelines
for request/response actions to model RPC and other messaging patterns,
there is no explicit RPC support through the description of the
unitdata primitives only, aside from correlation and causality (one
message arises as a result of another.) This does not encompass the
deterministic nature of RPC, where if you send a request, you MUST have
a CORRESPONDING RESPONSE, or you have no RPC. The XMLP layer does not
have any way of requiring a resultant message.
Henrik - you could have semantics requiring a non 1-to-1 message exchange
requirement, or any open ended requirement structure. It would be a
high level function to REQUIRE resultant messages.
Ray - the XMLP layer is not "aware" of such requirements, it does not know.
Henrik - the semantic of the application knows.
Ray - then XMLP does not know whether to keep the connection open, for example.
David F. - Doesn't RPC sit "above" XMLP?
Henrik - we decided that RPC is a module, no?
David F. - who will own this?
Ray - I can own this.
OWNER ASSIGNED - Ray
GENERAL DISCUSSION ON ISSUES AGAINST ABSTRACT MODEL SPEC
David - I propose that we set dates. If we want to submit for publication
before the 20th, we must be finished by next week, so we need to stop
accepting comments by the end of this week.
Anon conversation ensues, it was mentioned that we should have the issues
resolved/removed and editorial comments against the AM closed, then
allow the editors time to complete before the 4/18 telecon so that the
AM doc can be reviewed/approved by the WG.
Deadlines were agreed for comments : Friday, April 13th at end of workday PST.
Deadline for issue resolutions/inclusions : In the hands of editors by
Monday Apr 16, Noon PST
Deadline for editing to be completed by Tues. Apr 17, Noon PST
It will be decided on the 4/18 telecon whether we can publish the doc.