1. Roll call.
Scribe for minutes selected from attached list. Actions to be
recorded on IRC.
Present 14/11
- AT&T Mark Jones
- Canon Jean-Jacques Moreau
- Ericsson Nilo Mitra
- IBM John Ibbotson
- IBM David Fallside (chair)
- Microsoft Corporation Martin Gudgin
- Microsoft Corporation Jeff Schlimmer
- Oracle Anish Karmarkar
- SAP AG Volker Wiechers (Scribe)
- SeeBeyond Pete Wenzel
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- Sun Microsystems Tony Graham
- W3C Carine Bournez
Excused
- AT&T Michah Lerner
- Canon Herve Ruellan
- IBM Noah Mendelsohn
- Oracle Jeff Mischkinsky
- SAP AG Gerd Hoelzing
- Software AG Dietmar Gaertner
- W3C Yves Lafon
Regrets
- BEA Systems David Orchard
- BEA Systems Mark Nottingham
- DaimlerChrysler R. & Tech Mario Jeckle
- Fujitsu Limited Masahiko Narita
- Fujitsu Limited Kazunori Iwasa
- IONA Technologies Oisin Hurley
- Macromedia Glen Daniels
- Matsushita Electric Ryuji Inoue
- Systinet (IDOOX) Jacek Kopecky
Absent
- DaimlerChrysler R. & Tech Andreas Riegg
- IONA Technologies Eric Newcomer
- Sonic Software (Progress) David Chappell
- Systinet (IDOOX) Miroslav Simek
- Tibco Don Mullen
- Unisys Lynne Thompson
- Unisys Nick Smilonich
2. Agenda review, and AOB
* Agenda approved
DF: If you are the AC:
o Send in reviews to the AC list
o Inform your press folks and wait not until end-of-review phases.
o Refer to Janet's mail too.
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003May/0022.html
3. Approval of May 14 telcon minutes
* telecon minutes approved without modification.
4. Review action items, see
[http://www.w3.org/2000/xp/Group/Admin/#pending]
5. Status reports
-- Report on polled time change for telcon - if you have an opinion, send
email to me and/or the member list before the telcon.
* DF: Due to lack of consensus, stick with status quo for the moment. There
was no dissent against keeping status quo.
-- Planning next f2f meeting. Primary topic for this meeting would likely
be Attachments. We have pencilled in the dates of July 24 and 25, and we
have received one offer for the meeting to be held in Sophia Antipolis at
W3C. The Chair is determining what the atttendance would be to such a
meeting - please be prepared to say yes/no on the call or have done so by
email prior to the call.
* DF: regarding poll, 3 said no (including one vacation), at least 7 said
yes.
Meeting will be held 7/24-7/25 in Sophia Antipolis
Remote access will be available.
-- Creation of "Q+A" regarding SOAP 1.2 in a WSDL 1.1 environment
Report from WSD WG on discussions with the community about the use of a
binding used by SOAPBuilders. We want to know about the outcome of WSD's
discussion before finalising our own Q+A work.
* DF: As expressed in GD mail [
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003May/0059.html],
the soap builder community would very
much like a "blessed" WSDL 1.1 binding for SOAP 1.2.
WSD group and 1-2 people from XMLP should be involved to make it
right.
JJM: WSD has not formally discussed this issue yet.
DF: Does XMLP believe that the general direction of GD proposal is a
good one?
JJM: will support such TF
Anish: volunteers to represent XMLP in this TF
DF: Judges that XMLP WG is in favour of the proposal, and will email WSD
WG Chair accordingly
-- Response to XML Schema and Core WGs, PeteW has drafted a response, see
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003May/0044.html.
* DF: No discussion. The WG has no objection to accept PeteW's proposal.
-- Registration of "application/soap+xml",
http://www.w3.org/2002/06/registering-mediatype.html
* DF: skip this item because MarkN is not present
6. PR issues, see http://www.w3.org/2000/xp/Group/xmlp-pr-issues.html
(11.35 + 15)
PR issues will be resolved and trickled into an Ed Copy in the same manner
as CR and LC issues except that (a) the bar for changes is higher, and (b)
the final Ed Copy will be 'submitted' to the Director who may choose to
accept/reject any of the changes for inclusion in any Recommendation
document(s).
-- 425, http://www.w3.org/2000/xp/Group/xmlp-pr-issues.html#x425, at last
week's telcon the WG clearly expressed sentiment for keeping status quo. We
felt the response wording was important and will evaluate Gudge's proposal
(http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003May/0042.html)
for exact text of the response.
* The working group has no objection to accept Gudge's proposal, and the
issue is closed.
-- 427, the originator of this issue thought that an example in the Primer
was missing an encoding statement, however he now appears to believe that
the example is in fact correct (
http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0087.html). At
last week's telcon it appeared there were problems in the presentation and
display of the example. We will evaluate Gudge and Volker's proposal
(pending) for resolution.
* After a short discussion, the WG accepted that there is nothing wrong
with the primer. For the convenience of readers with a default code page
other than "western", characters not within the iso-8859-1 charset
will be replaced by their unicode character references. A response
will be sent to the issue's originator, with text that his issue will be
closed
without any changes to the primer document.
-- 428, content free header,
http://www.w3.org/2000/xp/Group/xmlp-pr-issues.html#x428, Rich Salz asks
whether an empty <Header> can be removed and whether <Header> can be added
when one does not already exist, see thread starting at
http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0111.html. There
seems to be consensus on the list on a solution _iff_ adopting it will not
delay Recommendation. The proposed new text is:
>>>>>> 3. Element information items for additional header blocks MAY
>>>>>> be added to the [children] property of the SOAP Header
>>>>>> element information item as detailed in 2.7.2 SOAP Forwarding
>>>>>> Intermediaries. In this case, a SOAP Header element
>>>>>> information item MAY be added if not already present.
See for example
http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0131.html. W3C
staff are asked to prepare the "8-ball" (i.e. indicate whether such a
change will delay Recommendation) to help the WG make its decision.
* DF: Three questions.
Q1. Any technical discussion?
MarkH: We should update soap normalization note as well.
DF: Q2. Do you agree with the proposed text?
Gudge: The last sentence must be clearer.
"In this case, a SOAP Header element information item MAY be added, as the
first member of the [children] property of the SOAP Envelope element
information item, if it is not already present. "
The changed text was accepted by the WG.
DF: Q3. Should we change the spec? Will this delay Recommendation?
Carine: We should ask implementers if this breaks their implementations.
Action assigned to check with implementers and test collection.
Decision postponed until action done. (s. action log)
Anish: Test-collection already covers this.
7. Attachments (11.50 + 40)
The attachment document we are working with is located at
http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html
-- Update on outstanding Copyright and IP statements.
* No updates.
-- Attachment requirements, see
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Mar/0027.html.
Adoption of new requirement regarding use of SOAP 1.2 mechanisms, see
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003May/0052.html.
o status of requirements list
* DF: Noah sent an email wording the new requirement (link below)
[1]
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003May/0052.html
DF: Change all refs to PASWA in Noah's text to "the specification"
JEFF: Change refs in Noah's mail (two 5s -> 5,6).
JJM: We should write specs with terms we introduced in our specs
(Features, ...)
DF: Majority for accepting this requirement?
MarkJ: Delete second and last sentence.
After some discussion:
Change {PASWA} to {The specification} and insert a may in the second
sentence. The new wording will be :
Use of SOAP 1.2: The specification must be specified using the mechanisms
of SOAP 1.2. These may include features [1], binding specifications [2],
headers [3], relaying of information through intermediaries [4], and so on.
All processing must be specified in terms of the SOAP processing model [5],
as augmented by any new features introduced. Where practical, the optional
mechanisms of SOAP 1.2 (such as A Convention for Describing Features and
Bindings [6]) should be used in the specification.
[1] http://www.w3.org/TR/2003/PR-soap12-part1-20030507/#soapfeature
[2] http://www.w3.org/TR/2003/PR-soap12-part1-20030507/#transpbindframew
[3] http://www.w3.org/TR/2003/PR-soap12-part1-20030507/#soaphead
[4] http://www.w3.org/TR/2003/PR-soap12-part1-20030507/#relaysoapmsg
[5] http://www.w3.org/TR/2003/PR-soap12-part1-20030507/#msgexchngmdl
[6] http://www.w3.org/TR/2003/PR-soap12-part2-20030507/#soapfeatspec
The requirement in the wording above was accepted by the WG (no
objections).
-- 429, who sees xbinc:Include?,
http://www.w3.org/2000/xp/Group/xmlp-issues.html#x429 (also
http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0101.html). See
proposed resolution in same email.
* Gudge: A binding that supports this .. (didn't get the rest)
Marc: Can a binding alone do this stuff or are Soap header needed?
MarkJ: Application does not see the include header
Gudge: only true for xbinc:Include
Mark: DoInclude is not a soap header?
DF: Who deals with this headers? Where do we draw the line
between application and/or binding?
Marc: Are we defining a binding only or a binding + soap module
or soap module only?
Gudge: Thinks that we can go either way.
Actions assigned to JEFF&MarkN + JJM&Hervé (see action log)
-- Other issues?
* there where no other issues.