XMLP WG telcon, July 25, 2001
1. Roll call
- Akamai Technologies Mark Nottingham
- AT&T Mark Jones
- BEA Systems Jags Ramnaryan
- Canon Herve Ruellan
- Data Research Associates Mark Needleman
- DevelopMentor Martin Gudgin
- Engenia Software Eric Jenkins
- Ericsson Research Canada Nilo Mitra
- Fujitsu Limited Kazunori Iwasa
- IBM John Ibbotson
- IBM David Fallside
- IBM Doug Davis
- IDOOX Jacek Kopecky
- Informix Software Charles Campbell
- Intel Randy Hall
- Intel Highland Mary Mountain
- Library of Congress Ray Denenberg
- Lotus Development Noah Mendelsohn
- Macromedia Glen Daniels
- Matsushita Electric Ryuji Inoue
- Mitre Paul Denning
- Novell Scott Isaacson
- OMG Henry Lowe
- Philips Research Amr Yassin
- SAP AG Volker Wiechers
- Sun Microsystems Marc Hadley
- Sun Microsystems Chris Ferris
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- Vitria Technology Inc. Tony Lee (scribe)
- W3C Yves Lafon
- W3C Hugo Haas
- Xerox Ugo Corda
- AT&T Michah Lerner
- BEA Systems Dan Frantz
- Canon Jean-Jacques Moreau
- DevelopMentor Don Box
- Engenia Software Jeffrey Kay
- Fujitsu Limited Masahiko Narita
- IDOOX Miroslav Simek
- Informix Software Soumitro Tagore
- Library of Congress Rich Greenfield
- Macromedia Simeon Simeonov
- Mitre Marwan Sabbouh
- Philips Research Yasser alSafadi
- SAP AG Gerd Hoelzing
- Vitria Technology Inc. Richard Koo
- Active Data Exchange Richard Martin
- Active Data Exchange Shane Sesta
- Compaq Yin-Leng Husband
- Epicentric Alan Kropp
- Hewlett Packard Stuart Williams
- Interwoven Mark Hale
- Jamcracker David Orchard
- Microsoft Corporation Henrik Nielsen
- Microsoft Corporation Paul Cotton
- Oracle David Clay
- Rogue Wave Murali Janakiraman
- Software AG Michael Champion
- WebMethods Randy Waldrop
- Bowstreet James Tauber
- Bowstreet Alex Ceponkus
- Commerce One Jay Kasi
- Commerce One David Burdett
- Compaq Kevin Perkins
- DaimlerChrysler R. & Tech Mario
- DaimlerChrysler R. & Tech Andreas
- Epicentric Scott Golubock
- Interwoven Ron Daniel
- IONA Technologies Oisin Hurley
- IONA Technologies Eric Newcomer
- Netscape Vidur Apparao
- Netscape Ray Whitmer
- Propel Daniela Florescu
- Rogue Wave Patrick Thompson
- Software AG Dietmar Gaertner
- Tibco Frank DeRose
2. Agenda review
No other items.
4. Review action items
1. for David Clay. Marked as closed because it is covered by
2. for Hugo. Document sent this morning.
3. for Paul C. Outstanding issue.
4. for Nilo. On the agenda today so marked as closed.
5. for Glen D.
[Glen] This was to do what Chris ended up doing.
[David] So we can close this item.
[Glen] We also need a larger scale version of what an
infoset is to be expanded out to the group.
6. for Gudge.
[Gudge] Think this is done and the results were sent to Chair.
[David] Marked as closed and will appear in next week's agenda.
7. for Glen D.
[David] On agenda for today so this item is discharged.
6. Review proposed resolutions to issues
Issue 24. Proposed resolution sent to eric@microsoft. Chair will
continue to investigate.
Issue 99. Proposed resolution sent from Glen. Is this acceptable?
No responses so closed with that resolution text.
Issue 100. Glen looked through the specification text and sent
a summary via email.
[Glen] In summary, the specification is unclear on this issue.
We can decided the security of the error. Secondly, if we
if we don't throw an error then we can consider Noah's
suggestion of a 'mustHappen' attribute.
[MarkJ] At Dinard we discussed ordering and mustHappen. I thought
that the algorithm for processing headers was extensible
enough to handle this.
[Glen] We could mention in that space that we have extensions for
people to add that capability.
[David] Do we need to design this?
[Glen] Maybe we don't have to design this then.
[Noah] A semi-minimalist approach sounds good. But I prefer not to
have optional behavior. I would specifically suggest that if
the specification is unclear then it must be made clear that
it is not specified. Also we don't standardize the
mustHappen semantics because they are related to larger
issues. An example is multicast. What does mustHappen mean
for that case?
[Chris] From the RPC call today we talked about 'best-practices' or
'standard extensions' as another separate specification.
[David] I am hearing 1) we should make it more explicit that it
is not necessary to throw an error. and 2) Do not
investigate creating a mustHappen attribute.
[Noah] Need clarification of 'is not necessary'.
[David] We need clarification of that semantic.
[Glen] mustUnderstand targeted at an endpoint needs to check
that all the intermediate mustUnderstands were processed
that were addressed to intermediate nodes.
[Noah] We disagree but shouldn't spend time on this.
[David] We need a proposal. I would like to hear more exact
terminology for clarifying that part of the specification.
Noah - you would rather not say that the ultimate receiver
may throw a mustUnderstand error if it receives a
mustUnderstand header which is not targeted at it?
[Glen] It does not say you should do it, it doesn't say you
shouldn't do it.
[Noah] If we don't say do it, then don't test for interoperability
based on it.
[David] Specification covers normative behavior.
[Glen] The Soap Builders community is concerned about this
issue. It should be described in the description of the
[Chris] The issue is for people building generic SOAP engines
versus applications. Noah is saying that we don't want to
preclude mustUnderstand blocks never reaching the correct
actors. From the SOAP processing perspective, if it throws
an exception then that prevents applications that don't
[Noah] Compromise text. Note that as a consequence of these rules
that it is possible for a message to reach an endpoint with
headers that are mustUnderstand that have not been
processed. This situation can arise. It is not an error and
does not result in an error according to this
specification, but it is possible to have extensions to
define this as a fault.
[Doug] Glen is suggesting the client does not know if endpoint is
throwing an error. Noah's text is much clearer what the
endpoint will do.
[Glen] In the general case it is a client issue.
[David] Glen and Noah to come up with some wording for the
specification. No suggestion for designing a mustHappen
[Chris] If we add wording such as Noah's, then developers will be
scratching their heads. It is possible that an extension
could be widely accepted though.
[Doug] I would like us to define this especially if the
specification says we throw an exception without the
[Noah] Let's do it better or not at all.
[Chuck] How about making it non-normative?
[David] We have an extension mechanism. If we put a note in
explaining a specific case, then it ballooned out to
designing a mechanism. We do not have time to do this in
[?] I agree but this is a special case. It is perfectly appropriate
to defined a standard extension.
[Glenn] I will send out a proposal. But I won't say if it belongs
in the specification or not.
[?] Could be in the primer? Example from the schema primer as a
[Jake] Similar to correlation ID extension? We are making a
correlation ID extension?
[David] It is being worked up by the TF and will be put up in front
of the WG. It will not be put out normatively. Glen and
Noah to write up a note to go into the specification.
[Glen] Happy to build up the beginning of this work.
Issue 102. Jacek, you put forward a resolution proposal.
[Jacek] I went through the specification. The specification is
careful not to say where the fault goes except for the RPC
case. Responsibility of the message patterns to specify
this. The specification needs to say this: The
responsibility of specifying where faults come and go is up
to the message patterns.
[Chris] Not clear that a message pattern is not necessarily bound
to a transport protocol.
[Jacek] Does not have to be bound, but messages from node to node.
[Noah] If I can clarify. SOAP 1.1 has half-baked message
patterns. When you use SOAP over HTTP, responses go across
HTTP responses. SOAP 1.1 doesn't say much about other
bindings. What is a response? It only says this a bout
RPC. Better off with a lightweight but first class message
pattern. Start with one-way and request/response, followed
by the relationship with the binding.
When I invent a new binding, required to define which
message patterns it supports.
This is all background to support Jacek's response.
[Mark] We have been discussing this in the TBTF. It is attached to
[Noah] My thoughts are that it is detached but needs to be
architected to use the facilities of the transport
[David] Proposed resolution of 102 presupposes something that does
not exist in the specification so it is premature to
accept this resolution. But we can take this as a signal
to the TBTF that a formal message pattern definition is
needed. Is this reasonable?
[David] TBTF will take up message exchange patterns and we will
leave 102 until the TF gets back.
Issue 106. Ordering issues of mustUnderstand in context of
multiple headers. We have a proposal. No comments from
WG, so chair judges that we can close 106 with the text
in the proposal.
Issue 107. Eric made a proposal for wrapping up 107. 4
subproposals and 1 outstanding issue.
First proposal is a minor change to Section 4.2. The
commentator in email agreed. Any disagreement? No
comment was made, so chair judges the WG has decided
to make the change.
Suggestion 2 and 3 covered by resolution that deals
with overlap in the specification. Eric agrees to that
response. Question to the Editors, is there a proposal
for solving that overlap?
[Editor] Need editing time and go ahead from the WG on the new
[David] Can the editors give us a date?
[Editor] Before the next telcon.
[David] That's entirely acceptable. Number 4, there was a
disagreement. The commentator felt it was already covered.
[Eric] Judgement call. I also felt that it was already covered but
if the WG wanted more, that was my proposal.
[David] No, WG desires to drop the suggestion.
[Eric] Fine by me.
[David] Open issue of what is a SOAP Application. Is the one line
in the specification sufficient?
[Eric] Stuart had a response which included a definition of a SOAP
[David] Is your proposal to put in a definition above and beyond
how it is currently called out?
[Eric] Difference between application and a SOAP node is the
issue. Do we need two terms? Or are they different?
[David] We will need a proposal for what that definition would
[Eric] Couldn't see any differences except that a SOAP Application
could span multiple SOAP nodes.
[David] Is that covered in Stuart's note?
Eric and Stuart to work on a proposal.
7. Review Infoset version of spec
Five specific questions/issues were raised in the text of the Infoset
version. Any comments?
[Mark] General point. If we go down the infoset route, we need to
also go down the primer route.
[?] Could we add more examples to the specification to cover this?
[Gudge] Prefer the Infoset to be descriptive and the primer to have
(Discussion on defaulting values from schemas followed)
[Chris] It is compatible, we just need to specify the attribute
information item properly.
[Gudge] Might have been defaulted in by schema processing.
[Chris] Are we requiring it to be schema processed? It cannot be
[Gudge] Why can't it be defaulted by a DTD? Seems strange to say
that you must have it in the Instance and it cannot be
defaulted in. I can go either way. Specification can say
cannot be defaulted in or it can say that we don't care.
[Noah] SOAP core mechanisms depend on schema processing? SOAP 1.1
is not dependent on schema processing.
[Gudge] The sender must put them in there.
(Lots of agreement to maintain status quo)
[Chris] Need to make it explicit that attributes added by
application can never be defaulted by a DTD. And if an
application expects attributes to default from a schema, be
aware that processors are not required to do schema
[Noah] Schema defaulting adds new properties. Never change existing
[David] Chris will write a proposal for wording on application
When we have these modifications to the Infoset and the
Infoset editor's copy, is that sufficient changes to put out as
a new Working Draft?
8. Review proposal for Primer
Deferred to next week.
End of call.