Minutes of XML Protocol Working Group Teleconference, February 6, 2002.
1. Roll call
- BEA Systems David Orchard
- Canon Herve Ruellan
- Compaq Yin-Leng Husband
- DaimlerChrysler R. & Tech Mario Jeckle
- DevelopMentor Martin Gudgin
- Fujitsu Limited Kazunori Iwasa
- Hewlett Packard Stuart Williams
- IBM John Ibbotson
- IBM David Fallside
- IBM Noah Mendelsohn
- Intel Highland Mary Mountain
- Macromedia Glen Daniels
- Martsoft Jin Yu
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Henrik Nielsen
- Microsoft Corporation Paul Cotton
- Netscape Ray Whitmer
- Oracle Anish Karmarkar
- Oracle Jeff MischKinsky
- Philips Research Amr Yassin
- Planetfred Mark Baker
- Rogue Wave Murali Janakiraman
- Software AG Dietmar Gaertner
- Sun Microsystems Marc Hadley
- Sun Microsystems Chris Ferris
- Systinet (IDOOX) Jacek Kopecky
- Tibco Don Mullen
- Unisys Lynne Thompson (scribe)
- Unisys Nick Smilonich
- W3C Yves Lafon
- WebMethods Camilo Arbelaez
- WebMethods Asir Vedamuthu
- Canon Jean-Jacques Moreau
- Compaq Kevin Perkins
- DaimlerChrysler R. & Tech Andreas Riegg
- Developmentor Aaron Skonnard
- Fujitsu Limited Masahiko Narita
- Intel Brad Lund
- Macromedia Simeon Simeonov
- Netscape Vidur Apparao
- Philips Research Yasser alSafadi
- Rogue Wave Patrick Thompson
- Software AG Michael Champion
- Systinet (IDOOX) Miroslav Simek
- Tibco Frank DeRose
- W3C Hugo Haas
- Active Data Exchange Richard Martin
- Active Data Exchange Shane Sesta
- Cisco Raj Nair
- Ericsson Research Canada Nilo Mitra
- IONA Technologies Oisin Hurley
- Mitre Marwan Sabbouh
- SAP AG Volker Wiechers
- Zolera Rich Salz
- AT&T Mark Jones
- AT&T Michah Lerner
- Cisco Krishna Sankar
- EDF (Electricite de France) Philippe Bedu
- EDF (Electricite de France) Olivier Boudeville
- Interwoven Mark Hale
- Interwoven Ron Daniel
- IONA Technologies Eric Newcomer
- Mitre Paul Denning
- SAP AG Gerd Hoelzing
2. Agenda Review
David Fallside added 2 items to the agenda:
(1) Reminder to register for the Technical Plenary and F2F meeting. Draft
agenda for the F2F meeting will be available on the website in the next day
or two. Agenda will be finalized beginning of next week. WG members will
be pinged for feedback on initial aganda
(2) What worked well in the past F2F meetings is to go into the meeting
with proposals for issue resolutions. Prior to F2F, we need to set people
to work on generating proposals to resolve issues on the list.
3. Review of minutes
January 30 minutes approved as posted.
4. Review of Action Items 
#1 2001/11/07: Editors [Henrik] - Done
Provide examples of encoding tool (by 2001/12/15 -> by EOW 2002/01/09).
#2 2001/11/27: Editors - Pending
Incorporate requirements from RDF, UML, XML Encryption, ... in requirements
HenrikN related an earlier conversation on the question of finding some
explicit requirements from RDF and UML. It turned out that we have had a
discussion going on with them for a long time, in fact, so long that it is
reflected in our requirements and even our charter and it also goes to
which spec we have to deal with respect to data models of various types.
Henrik said we have the requirements covered in our requirements document,
but we have an issue dealing with it, particularly issue #29. The proposal
is to insert a sentence in the requirements document that we expect RDF and
UML requirements are covered by the references to the requirements document
in the charter itself.
Stuart suggested we ping at least the RDF group (not necessarily the UML
group) to see whether needs are met. DavidF said we are in the process of
ping-ing the RDF group. We can ask them explicitly.
#3 2001/12/05: HenrikN &DavidF - Pending
Follow up on links to requirements from external WGs by Monday noon EST.
With regards to RDF, DavidF said that we have pinged them again and hope to
get a definitive answer to them on issue #29...serialization of RDF. With
regards to UML, DavidF has spoken with the chair of OMG/XMI WG (Barbara
Price) to ask whether they believe that they can transport XMI messages,
which are the XML representations of UML models, inside SOAP messages.
They have generated a list of ~14 critical points which they used to judge
the truth of the statement that they can send XMI documents in SOAP. Of
those 14 points, most confirmed that they could transport XMI documents in
SOAP. There were 3 of 14 cases where they cannot answer positively because
they did not understand our specifications. To resolve this, DavidF asked
for a volunteer who would be a contact for the XMI/UML people and whose job
is to explain what we meant in those 3 cases. By doing so, they can give
us our resolution of issue #29.
Mario, who is currently in the OMG/XMI WG, volunteered to be the contact
person. DavidF suggested sending him e-mail to get this effort going.
#4 2002/01/09: DavidO - Done
Complete encryption scenarios and send them to xml-dist-app and
Given the recent e-mails from Joseph Reagle, DavidF wanted to know if these
scenarios convince us and XMLE that they can apply encryption to SOAP?
[DavidO]: It depends on what is meant by applying encryption to SOAP.
There are other questions such as "How do multiple schema validations steps
occur? What should intermediaries that may be doing encrypting and
decrypting expose as the interface? How should namespace names be used?"
and so on.
DavidO would like to know the working group's comments on that. In reading
the e-mails from DavidO and JosephR, DavidF could not figure out whether or
not DavidO and JosephR felt that the issues surrounding namespaces and use
of schemas are addressed.
NoahM commented that this might be related to issue #137.
DavidF tabled the discussion for now. He suggested that we go through the
questions that DavidO raised. Are there viable solutions? DavidO and
StuartW suggested that a joint meeting between the XMLP and XMLE groups
Action: DavidO and David to figure out the interaction between XMLP and
#5 2002/01/30: OisinH - Pending
E-mail review of section of the primer by Friday. OisinH has sent his
regrets. He will complete action by end of the week.
5. Status Reports
No discussion as the Primer Editor is not present.
The specification is in good shape. In addition to the TBTF text work,
DavidF asked if the editors believe that they would commit to making a
stable spec available by end of next week (15 Feb) because we need stable
specs for the F2F meeting. According to one of the editors, the only one
big piece of work outstanding is in discussion - rewriting the encoding and
RPC sections in terms of infoset. The editors are unsure whether they can
do this piece of work and commit to a stable spec by the end of next week.
Editors added that this change was signalled in an ednote. DavidF
determined that no feedback was received and the ednote stated intent to do
this work. DavidF said this situation gives us the liberty to do the work.
GudginM said Section 5 is quite large, and offered to provide change text
separately at the F2F meeting for members to decide on. It would not be a
complete rewrite of both sections (infoset description of SOAP encoding and
RPC convention), but it would at least show the direction we are headed.
GudginM further added that it does not make sense to do one section only.
We should consider it as a block.
[PaulC]: Could we go to Last Call without it?
[DavidF]: We would like to have it in last call.
Action: Figure out whether infoset description of SOAP encoding and RPC
convention is needed for Last Call [Yves Lafon/DavidF].
Highland provided the status of email binding. A proposal is ready for
distribution and review by a wider audience. She noted that it is in HTML
format (should be in XML). DavidF commented that he is more concerned with
its content at this time.
TBTF is meeting on Friday. By and large, TBTF is happy with the proposal.
The proposal will be published on Friday.
Action: Send email binding document to Yves Lafon to remove inappropriate
items such as logos, before circulation to xml-dist-app [HighlandMM]
The task force has not met recently. There is nothing to report at this
time. There will be a meeting Thursday.
Conformance work -
[Jeff]: Good progress has been made. We divided the spec into a series of
assertions and notes. Publish the document in ASCII by Friday (or Monday).
Encourage the group to read the notes and identify areas that are unclear,
untestable, or need changes. We do not want to design and write tests
until we are sure the assertions are correct.
PaulC has several questions.
Q. Are all materials from the previous F2F being integrated?
A. [Jeff]: We are doing more than that. We are going through the spec and
pulling out all areas where things have to be implemented and turning them
into assertions. We are using the materials from the F2F; but some areas
did not have assertions.
Q. Why ASCII text? Why not directly integrate the material into Hugo's
A. [Jeff]: It will be.
Q. When will it be done?
A. [Jeff]: After the group has reviewed the ASCII assertions. Oisin is
handling giving the material in parallel to Hugo.
Q. On the homepage, there is a procedure for submitting tests. Do these
submitted tests have to be integrated as well?
A. [Jeff]: Yes. There is a master list which will encompass all of these
sources. [Ahnish]: We are trying to break the project into stages, leading
to an updated version of Hugo's document.
Q. Do you have dates for the stages?
A. [Jeff]: As mentioned earlier, by Monday for the complete list. We
don't know how long it will take to integrate it into Hugo's document.
[PaulC]: We can follow your plan but we need that document for Last Call.
DavidF has proposed a date of 2/14 for that document. It doesn't sound
like you can meet that date.
[Jeff]: We think we can make that date.
DavidF suggested that Jeff and his team work in parallel as much as
possible. This is a two-phase process (1) integration of the materials you
have generated and integrated with the materials from the website, and (2)
the process of integrating that into Hugo's main document. DavidF
suggested that Jeff and the others put the integrated materials into the
Hugo document sooner rather than later, i.e. assume that the work they have
done is probably right and not wait for feedback from the WG before moving
to the second phase. Jeff agreed to integrate as soon as possible rather
than wait for the group's comments.
No discussion (skipped)
6. The editors have offered 2 rewrites of Section 2.
The preamble (from ) regarding the rewrites is:
(i) The first "SoapProcessingModel.htm" and "SoapProcessingModel_RL.htm"
is the less radical of the two and maintains the current terminology around
SOAP actor and roles.
(ii) Second "SoapProcessingModelNoActor.htm" &
SoapProcessingModelNoActor_RL.htm" proposes more radical changes. The
specification's current use of the word actor is counter-intuitive, e.g.
we speak about SOAP nodes assuming roles named by SOAP actors. In real life
roles are not named by actors, actors play roles and this can lead to some
confusing wording. The second rewrite assumes that we rename the "actor"
attribute to "role".
Per Marc, options to clean up spec will improve overall readability and
understandability of the spec. It brings the spec in line with common
English usage - actors play role instead of nodes playing roles. It reads
properly. However, Henrik would like to see less focus on the English
usage. He would like to see one fundamental concept. People might get
confused to see three concepts - roles, actors, and nodes.
DavidF asked Marc to estimate the amount of work required for the different
options by going through the pros and cons. Henrik claims that all the work
is relatively small because all the edit are focussed very narrowly in a
few paragraphs in Section 2. Throughout the rest of the spec, we used SOAP
node as a generic term for a SOAP processor. GudginM and Henrik both
agreed that the Friday schedule will not be jeopardized if the decision is
to adopt what Marc described in his e-mail as the more radical change and
the most work ( (ii) above). Henrik claimed the most of the work is
Noah is uncomfortable with the proposal on the table for two reasons and
offers his proposal on how to resolve it:
(1) It is not as orthogonally as it was. Now the endpoint does not neatly
have a set of roles that it assumes. It has a set of roles plus this other
magical thing. Noah would prefer to see it more symmetrical.
(2) There is a change in the design. In the past, it was possible for an
intermediary to also decide to serve in the anonymous role. Previously,
the anonymous actor was viewed as symmetric. Something was lost in the
process. Noah suggested: (a) go back where we were on this issue, pick a
term other than anonymous actor but to basically say there is an assumed
actor which is what the endpoint must act as and which is treated
symmetrically with the others, or (b) eliminate the notion that a header
can sent without an actor on it. Just like Next and None, we could have an
actor named Endpoint. Noah would be happy to see an explicitly defined
Endpoint URI for roles. It would be treated like another value for roles
and is defaultable.
Henrik believes that there is an actual name for it already, which is
[Henrik]: I am not sure I understand why putting that into the message. It
is implicitly there now as a default value, so if you don't stick anything
in, this is what it means. Putting it in explicitly is just burning bytes.
DavidF surveys the working group as to how many are in favor of
"syntactically making the endpoint explicit, making the endpoint explicit
in a syntactic way as a piece of symmetry". At least 8 telcon
participants favor the creation of an endpoint URI.
DavidF proposed that before actually adopting option 2 (ii), we need to see
the actual text (plus wordsmithing of problematic areas as pointed out by
NoahM). Noah requested clarification of task (i.e., explicit URI,..) .
DavidF confirms that this is based on the notion that a URI can be invented
and will be expressable by leaving out the attribute out but you can also
expressed it with it back.
Action: Produce rewrite of 6.2.per DavidF's instructions [NoahM, HenrikN,
Henrik was given the action to open an additional issue on general
defaulting scheme for attributes in the envelope (not schema defaulting but
Noah pointed out that in Section 2.5, an entire paragraph was deleted that
represented the working group's resolution of "what a body element
means"...Noah agreed that the spec is coherent without this paragraph. In
previous discussions (2 months ago), lots of readers were concerned about
what a body could be. Noah was reluctant to let go of this paragraph.
Many telcon participants believe that this paragraph should be moved to the
Primer. DavidF instructed editors to ensure the paragraph does not
disappear, and that it must appear in the Primer.
7. Issue 176, canonicalization/rewrite of headers.
Don Mullen started the discussion. In discussing intermediary processing
last week, Noah raised issue regarding the kind of rules that might be
enforce and the kind of lexical changes that can be made to certain blocks
within the SOAP message. This was recorded as issue #176. Don stated 3
options: (1) Allow making lexical changes anywhere, (2) Disallow making
lexical changes anywhere, or (3) Specifically say that lexical changes
within the blocks are not allowed but outside the blocks they are. DavidF
added that there is also the "issue of how we deal with the various _types_
of things, i.e. PIs etc"
[Henrik]: We are walking a fine line by looking at the lexical
representation as in the case of XML 1.0 representation or looking at it
terms of the Infoset and we could solve it by going in a slighter different
direction with the exception of the types, e.g., true or one. We could
say we use these particular parts of the Infoset, and whatever we don't
use, this is what you have to do with those, i.e., you have to pass them
through unaltered or similar, and not think of it in terms of the exact
serialialization. I realize the signing of encryption posts has different
constraints, but I don't think they have to canonicalization for other
DavidF requested a clarification of Henrik approach.
[Noah]: What I had thought we were talking about with lexical
representations was if you look at the Infoset, it includes not only
elements and attributes, but things like character information items that
include white space. We can look at the Infoset and say that is it has all
the things that are lexical. It has white space characters, comments, line
wrappings and so on, so I think the question is very much starting with
that Infoset coming in for a message what are the constraints on the
Infoset we will send out in the next message. Even at that level we have to
talk about whether the number of white space characters are preserved, are
comments preserved, what are the rules if Queue headers were removed
because they were processed and there was a comment between them and so on.
[DavidF]: Can I characterize what you are saying as anything that is
carried in the Infoset description we need to think about. Henrik, were
you saying we should carve up our Infoset description to distinguish
between what is carried and what types of information items are carried
that we care about?
[Henrik]: We only use some of them, and we should say what we want to do
with the rest of them.
Noah states that everyone is in agreement.
[DavidF]: The question is which ones do we agree we care about at the
Infoset level. Are they all carried as information items of one sort or
another? So they are all CIIs, Comment information, etc....
Henrik responded positively.
DavidF has a strong sense that the members are in agreement with the
general idea that nodes are only obligated to pass information items that
appear inside blocks (header and body). Information items of any sort that
occur outsides blocks are not guaranteed. Ray added that the order of the
header block would be preserved, that is, the order of the header blocks is
actually information that exists outside of the header block. Noah added
that order is coherent from an infoset point of view. Henrik pointed out
that there is this notion of taking things in and out. What would be the
[DavidF]: We have identified various aspects of issue #176. In a sense,
we have got some fair agreement. We need a proposal to address the 3
critical aspects (1) where the info item can be changed if they can be, (2)
ordering of those info item, and (3) the issue of whether true is
equivalent to 1.
Action: Draft proposal for treatment of intermediary of infoset
information items [Henrik]
8. Issue 165, dereferencibility of URI's.
NoahM provided a brief summary of the proposed resolution from the TBTF.
The issue can be traced back to concerns raised about support for
attachment architectures (SOAP+attachments) as a means of carrying
information that will be guaranteed available during processing of a SOAP
message. Current charter does not specifically call for considerations of
attachments. The inclusion of attachment processing is slated to be in the
next revision to the workgroup's charter.
No objection from the WG to closing issue 165 with this resolution.