See also the IRC
- AT&T Mark Jones
- BEA Systems David Orchard
- Canon Jean-Jacques Moreau
- Fujitsu Limited Kazunori Iwasa
- IBM John Ibbotson
- IBM David Fallside
- IBM Noah Mendelsohn
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Henrik Nielsen
- Mitre Paul Denning
- Netscape Ray Whitmer
- Oracle Anish Karmarkar
- Rogue Wave Murali Janakiraman
- SAP AG Volker Wiechers
- SAP AG Gerd Hoelzing
- SeeBeyond Pete Wenzel
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- Systinet (IDOOX) Jacek Kopecky
- W3C Yves Lafon
- W3C Carine Bournez
- WebMethods Camilo Arbelaez
- WebMethods Asir Vedamuthu
- AT&T Michah Lerner
- Canon Herve Ruellan
- Fujitsu Limited Masahiko Narita
- Microsoft Corporation Martin Gudgin
- Mitre Marwan Sabbouh
- Netscape Vidur Apparao
- Oracle Jeff Mischkinsky
- Rogue Wave Patrick Thompson
- Software AG Dietmar Gaertner
- Systinet (IDOOX) Miroslav Simek
- Ericsson Nilo Mitra
- IONA Technologies Oisin Hurley
- Tibco Don Mullen
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- DaimlerChrysler R. & Tech Mario Jeckle
- DaimlerChrysler R. & Tech Andreas Riegg
- IONA Technologies Eric Newcomer
- Macromedia Glen Daniels
- Martsoft Jin Yu
- Progress Software Colleen Evans
- Tibco Amy Lewis
2. Agenda review
Majority of time spent on last-call issues.
Agenda item 6 will be remaining issues.
Agenda item 7, issues lacking proposals.
Issue regarding IP does not appear on either agenda item, but will be
discussed as new charter is published.
Status of rechartering: We are a day away from seeing the new charter.
Responses from the new charter were requested from AC Reps, and
received from all.
The new charter is ready, pending announcement of director, perhaps
by the end of the week.
3. Approval of telecon minutes from last week.
No objection to their approval, and no requests for modifications.
4. Review of action items.
[misc notes on actions]
Responses trickling back from implementers. Will be published in next
day or two. Others have committed but provided no updates.
We may have lost HP as an implementer of the specification.
Question: Prioritizing dividing the implementations between must,
should, etc. Is it the case that we must show two interoperable
implementations for every feature, and that we must do it for the musts,
Opinion: not required for "should's".
DavidF: We have committed to implement not only mandatory but also
Noah: We should proceed that way and reevaluate if necessary later.
[end of actions]
5. Status reports.
* Primer -- no report
* Spec -- no change from editors
* Test collection document
Anish: mail sent describing this. Almost done synching with latest version
part 1. Have not started on part 2. Intends to be done by the end of the
Mike Champion -- WSA -- Hugo wrote something up that will be submitted
by the deadline on the 18th.
* Attachment feature document -- no comments back on this document yet
Reminder send to chairs list by DavidF.
* Last Call issues list -- it is up to date.
* Implementation tracking -- status given earlier
* Media type draft, nothing to report
* Planning for October F2F, please send agenda items.
Question: how is list of participants updated?
Only 6 registrants had come through in box. It will be updated in next
6. Last-call issues.
Any pushback to recently-closed issues?
Henrik -- a comment regarding closing and whether resolution text was
sufficient. This was sent to the chairs list. We have to be careful to
say carefully why we closed things. Some of the past closings have
contained no rationale at all.
Comment received during last call regarding subcode. Gudge proposed
not answering the questions. One question was about enumerated fault type,
the other was how WSD figures out the type of subcode. Gudge suggests
are not issues for us, but we should bequeath them to the WSD working
Resolution: No objection. Agreed to send comment to WSD working group.
Gudge agreed to send appropriate email to WSD WG in email.
Issue 234, are gateways intermediaries?
DavidF: Listed as editorial issue, but it is an important concept that
to be run past the WG.
Noah: Agenda statement about issue is an oversimplification, it states
is agreement that a gateway is not intermediary. It may not be, but not
necessarily. The wording should not rule out a gateway being an
Dave Orchard: Should we define gateways quickly, and pass future revisions
WSA working group?
Noah: gateways do not appear in SOAP specification. Req??? is fine, it
defines intermediary, and talks per-message. We do not talk about
gateways, we should not.
Proposal: close 354, taking no action except minor editorial. Rational
our position is that a gateway is not necessary a SOAP intermediary, but we
are not in the business of defining what is a gateway.
Henrik: Agrees. We have nothing to say about these things. We care
about what comes in and goes out SOAP.
Jean Jacques: Agree with Noah. Mark Baker and I came up with a joint
definition for Gateway, to be included in the WSA document."
Dave Orchard: So, the direction is to define gateways in WSA? Can we defer
this decision for a week, because the WSA WG thread is long and I have not
DavidF: We'll record the general feeling of the consensus and postpone
until next week.
DavidF: we have already agreed to a new attribute. The text Noah proposed
is the only we have. We can close this issue by incorporating Noah's text.
Jacek: Noah's text covers parts of 231. The rest of the resolution
regarding 231 is posted in dist-app, recorded in irc, dist app message
193. We have changed the attribute name changed to nodeType, but otherwise
we can use Noah's proposed text.
DavidF: Is there any objection to closing 231 as just described (and see
with the new name of attribute and Noah's text as referenced in agenda?
DavidF: 231 is so closed.
John Ibbotson to write closing text to xml-dist-app.
DavidF: Editors started preliminary discussion of options resolving 305,
sent in response to agenda in member archive #12. Marc to outline
Marc: We have three options:
1. Push back on issue -- when we say message, that includes all
information, not just the envelope. That ducks the issue a bit.
2. Accept that it is a problem and we need to split http binding into
copies of nearly the same thing with different state machines.
3. More radical overhaul. Remove the duplication between http binding
text and text of MEPs, pushing MEP descriptions back to section 6,
removing tables, extracting descriptive text. Then refer back to the
state machines in section 6.
Henrik: #3 was proposed in the issue. It is a lot of work, but perhaps
we should do it anyway.
Other editors state agreement -- setting themselves up for a lot of work.
David: Does #3 mean we will have a shorter spec?
Marc: Yes, several pages shorter, eliminating redundancies from section 6,
which may even be contradictory in places. Shortens http and does not
lengthen MEPs much.
???: What about the mail binding, what would be the effect? Does it use
DavidF: Are there any major objections to adopting option #3?
JohnI: If the editors are willing, I support simplification.
Yves: (in response to a question about such changes pushing us back to
If the changes are clarifications only, and even though they change the
appearance, they will not require us to go back to WD.
No objections to adopting option #3.
DavidF: There is at leats a tacit mandate at least for adopting option #3.
We will leave the issue open until the changes are doneand we can see them,
because they are large, and will give an opportunity to catch unintended
changes that are beyond editorial. We need the changes by the end of next
DavidF: We need a stable copy of spec. Any other changes between now and
must be there, too. Editors need to do everything for a draft by the F2F
resolves all issues.
Editor's question: How should paragraph movements be handled? Text deleted
old section and added to new section.
Looks bad. Is there a style sheet to hide this? No.
For tables, just leave deleted caption and not entire table.
Noah: Marc, is there a fifth change code that could be introduced for
notes, like "3 paragraphs removed here".
Henrik: Let editors take it off line.
Editors instructed to make changes, issue will remain open.
Awaiting text from Glen. Postponed.
DavidF: Request to rename soap encodings ref attribute to idref, to reduce
confusion related to other uses of ref, and to better reflect our use. We
have a proposal to maintain the status quo noting that if we namespace
qualify our attributes, it will appear in a different namespace
(the WG agreed to global namespace qualification in a previous issue).
DavidF: Proposal, keep the status quo, rationale: now that ref is namespace
qualified, it's semantics are uniquely qualified.
DavidF: This part of issue 326 is so closed.
With regard to how strictly idref is enforced. Spec says we should
enforce them. The request is that we MUST enforce them.
Proposed resolution: Because we do not mandate XML Schema, such
constraint checking is impossible.
Noah: Likes proposal, but not the reason. The id could be enforced
without schema. But there are other good reasons not to require it.
Nothing deeply breaks if we only encourage this and do not mandate
enforcement on data that applications are not interested in.
DavidF: Any obection to adopting status quo with modified rationale
and closing the issue?
DavidF: issue 362 is so closed.
Noah will send closing to xmlp-comment and originator.
Comment information items in SOAP infoset.
DavidF: Gudge was asked to create proposal on what infoset could contain,
he did. There has been a lively discussion. Can someone speak to where
the issue is with respect to the discussion (Gudge not present)?
Henrik: There was a question involved in signing the envelope, whether
an empty header can be removed from the envelope:
Noah: Two things, the decision, and the rationale.
1st model: Keep it simple, don't mess with it.
2nd model: It is a bother to keep track of whether data might be missing
due to an empty header.
Henrik: What if it was an argument.
Noah: that was not covered by case. It was not a question of what to
do if you remove the last one.
Noah prefers 1st option
More discussion of specific use cases with intermediaries ...
Marc: This (????) would be a significant change to last-call draft, because
what was allowed by intermediaries would now be disallowed.
Marc: Concerned we need to go back to another draft, which we want to
DavidF: Is there a part of the proposal that we could adopt?
Noah: Gudge claimed he took an action item to deal with various
aspects, not just CII's.
DavidF: There was a specific and a more general discussion. He
considered them to be clarifications, but not everyone agrees with that.
a. The proposal is large with possible WD size impacts.
b. Probably goes beyond CII scope.
c. People like where it went.
Possible ways forward:
1. Ask Gudge to explain how semantics are not changed. (Henrik points
out that intermediaries change, you could say what it applies to)
2. We need another turn of the crank. Either we choose status quo, or ask
Gudge or someone to pare down the proposal to just focus on CIIs.
3. We could take Henrik's comment that it really changes things, so
decide whether we want to take it on board.
Would this change send us back to the beginning of last-call.
Yves: Cannot say yes or no.
DavidF: Several have called this a major change. What about paring this
down. What about dealing with just CII's?
Marc: Will we get hit with being signature unfriendly, otherwise?
Noah: A middle ground beyond just do comments. Insofar as he is just
expressing in infoset terms what we were saying formally, should we
allow that. That part is just editorial, but can still go beyond comments.
DavidF: Middle ground, just do CIIs, or a slightly broader proposal to
use the infoset terminology and constructions throughout.
Noah: do comments and reiterate that editors need to be consistent on
infoset, and perhaps it is already clean in that respect.
David: Should we go forward?
Henrik would like to discover whether this takes us back before
LC, to see if more can be done.
Yves to try finding out by Monday whether this is lilkely to send us back
Henrik to talk to Gudge.
-- 366, use generic types for struct and array
Proposal to close issue with no action because it is no longer applicable
since generics were removed (issue 297).
DavidF: Any objections to closing the issue with this proposal?
No objections raised.
DavidF: issue 366 is so closed.
Jean Jacques to write xmlp-comment text.
-- 365, keep generics
Proposal to close issue with no action because we already decided to remove
generics (issue 297).
DavidF: Any objections to closing the issue with this proposal?
No objections raised.
DavidF: issue 365 is so closed.
7. Assign owners to generate proposals for the remaining non-editorial
issues for which we have no proposals.
359, will wait to see what Glen comes up with for 300 which is closely
John Ibbotson & David Fallside: 367 368 369
Proposals due for end of business on Monday. DavidF asks for committments.