- AT&T Mark Jones
- Canon Jean-Jacques Moreau (Scribe)
- DaimlerChrysler R. & Tech Mario Jeckle
- Ericsson Nilo Mitra
- IBM John Ibbotson
- IBM David Fallside
- IBM Noah Mendelsohn
- Macromedia Glen Daniels
- Microsoft Corporation Henrik Nielsen
- Netscape Ray Whitmer
- Oracle Anish Karmarkar
- Progress Software Colleen Evans
- SAP AG Volker Wiechers
- SAP AG Gerd Hoelzing
- SeeBeyond Pete Wenzel
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- W3C Yves Lafon
- W3C Carine Bournez
- AT&T Michah Lerner
- Canon Herve Ruellan
- DaimlerChrysler R. & Tech Andreas Riegg
- Microsoft Corporation Martin Gudgin
- Netscape Vidur Apparao
- Oracle Jeff Mischkinsky
- Software AG Dietmar Gaertner
- BEA Systems David Orchard
- Fujitsu Limited Kazunori Iwasa
- Fujitsu Limited Masahiko Narita
- IONA Technologies Oisin Hurley
- Systinet (IDOOX) Jacek Kopecky
- Tibco Don Mullen
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- IONA Technologies Eric Newcomer
- Martsoft Jin Yu
- Matsushita Electric Ryuji Inoue
- Mitre Marwan Sabbouh *
- Mitre Paul Denning
- Systinet (IDOOX) Miroslav Simek
- Tibco Amy Lewis
2. Agenda review, and AOB (11.05 + 5)
3. Approval of 20 Nov, 27 Nov XMLP WG telcons
Minutes 20 november approved as posted.
Minutes 27 november approved as posted.
4. Review action items, see
David proposes a plan for publishing AM doc as a "no longer under
i) describes status section
ii) solicits an editor, Mark Jones volunteers
No objections from WG to this proposal.
Proposal for publishing without WG review once edited
No objections to this course of action. David will review the document
David proposes plan for resolving issue 385 (conformance section for
Attachment Feature doc)
Hervé's proposed modifications are mentioned, Henrik approves of these.
No objection from WG to accepting David's proposal with Hervé's
David: Issue 385 is closed.
DaveO, close 87, 86, 89, 90, 96, pending. Reassigned to Colleen.
Chair, find volunteer to review WSD requirements doc by email, done, but no
volunteers. JohnI volunteers.
5. Status reports (11.20 + 20)
Nilo: new version of ed copy created last week, it incorporated all LC
comments. Awaiting further instructions.
Henrik: editors have a plan:
i) Generate 1st snapshot with diff markup.
ii) Remove diff markup and log and generate 2nd snapshot
iii) Do minor editing tweaks
Henrik, MarcH, JJM: snapshot ready next Tuesday, 10/12
David: feedback on 2nd draft by EOB Friday, 13/12
David: please add one more step -
iv) Make snapshot a CR draft
-- LC Issue List
Carine: there are 3 outstanding issues on part 1 and part 2; 6 Abstract
Model document issues have been closed
Yves: I am still trying to determine whether Microsoft's IPR statement is
complete (in CPP sense of the word). I am waiting for a response from
David: Ray, can we close 327?
Ray: I still have a problem with WebMethod's statement.
David: resolution of that is outside jurisdiction of this WG.
Ray: would expect that if had received similar statement from outside
member, would have looked at this issue.
David: I have been told that we don't need a PAG on account of their IPR
Ray: I don't believe that is correct. A PAG is for any apparent IPR.
David: Yves, ask DanielW to send email message what he told you, Ray and I
during AC meeting.
Noah: Ray has a point, we need clarification, need to understand what the
W3C would do when company comes out of the blue with problematic IPR.
David: Yves will ask DanielW.
Ray: special circumstances need to be considered.
-- Implementation tracking status
David: we are asking implementors which features they implement. Deadline
next Monday. Some reports available already, and we will hold a telcon when
all data is available. We will then need to demonstrate interop. Will
create a second table to record interop. All this activity can be done in
parallel to CR.
-- Test Collection
Anish: will reply to Don's email this afternoon. No other news to report.
David: we will need an updated test collection document very soon if it is
to be published jointly with CR draft.
Henrik: we need both the spec and a test collection, but I am eager to go
ahead with spec asap.
David: the content of the test collection document will probably change
with results of CR. Can we avoid CR for the test collection document?
David: so I propose we go to CR with part 0, 1 and 2 only. The other
documents (test collection, etc.) will not be published as CR working
drafts, but they may be changed as result of CR.
No objection from WG.
David: we are planning to publish a concrete attachment feature spec.
Should it be a separate document or merged with the existing abstract
attachment feature spec?
Henrik: there should be one single document.
David: and should that document be published with the main SOAP spec or
with the concrete spec?
MarcH: publish it with the concrete spec.
Noah: has the pressure died down on the attachment feature spec?
MarcH: in my organisation, people want the concrete attachment feature
JJM: I agree
David: So to summarise the complete proposal. The AF document will not go
into CR, and it will be put on hold until we start work on the concrete AF
implementation spec. They will be published into a package together.
Furthermore, we will go to CR with Parts 0, 1, and 2 only. Any objections?
No objections voiced.
6. Moving to CR (11.40 + 15)
David: remaining considerations before we can go to CR:
i) Comments needed to close issues 87, 86, 89, 90, 96. Colleen has an
action to complete these.
ii) Microsoft's IPR issue.
iii) A record of our decision to enter CR. We did this last week.
iv) Prepare spec. Part 1 and 2 editors have agreed to a schedule. Nilo,
will Part 0 be ready for next week?
v) Proposed status section text. WG agrees it can go into parts 0, 1 and 2.
vi) Request CR status. Chair is currently drafting text with the W3C team.
It is ~70% complete.
vii) Announcement of CR. According to the CR FAQ there needs to be a telcon
to decide what the announcement will look like.
We should be able to go to CR right before the W3C publication moratorium
starts, i.e. before December 20th.
7. LC Issues [http://www.w3.org/2000/xp/Group/xmlp-lc-issues] (11.55 + 5)
No pushback on Last Call issues reported.
8. Other topics (12.00 + 20)
-- SOAP's subsetting of XML
David: Paul Grosso went to TAG as individual: he has a problem with SOAP
not permitting any internal subset in its messages. The TAG replied that
this is an interesting question, it (subsetting XML) is not necessarily bad
idea, but they want more about rationale from XMLP. Paul and the TAG are
nervous about delaying XMLP's work. Noah has drafted a lengthy response to
TAG which we will discuss.
Noah: want to avoid reopening controversial questions and tradeoffs and
want to document our rationale.
Noah: SOAP is not a redefinition of XML, but SOAP is a user of XML. Every
user of XML resticts XML, e.g. element names. The reasons include
performance and simplicity of processing model (e.g. relaying at
intermediaries: should they relay DTDs? etc.). Maybe SOAP defines a subset.
Also there is the PI issue.
David: I note there have been positive responses to Noah's note, in
particular from DaveO who is also on the TAG.
MarcH: Noah's note essentially deals with the internal subset. What about
Noah: it should deal with that as well
David: Paul does not mention the external subset.
Noah: it is less controversial.
David: Paul says that an "important class" of documents are standalone XML
documents. Does it mean he is admitting the existence of a subset?
David: should we include mention of the external subset?
RayW: there are probably other things we should mention like entities,
Noah: I am willing to add a sentence about "don't allow external DTDs".
Henrik: we should also mention robustness
RayW: default attributes are another potential problem area.
Noah: I am not sure we want to go to that level of detail.
RayW: what about mentioning adding types to attributes? Maybe we add one
line to say this is consistent with our approach.
David: what about adding a line on simplicity?
RayW: more worried about processor having them as a rule.
David: any objection? (would be useful for TAG to investigate issue)
Noah: don't think our subset is particularly general. Driven by
intermediares, for example.
Noah: the points I have captured so far are external subset, security,
David: did you and Ray reach an agreement on email?
Noah: we need more discussion.
David: you and RayW have until Friday to come to agreement.
Noah: we will need to save time for editing. I can provide one draft only.
David: if people have comments on what Noah and Ray create, they will need
to send proposed rewording.
No one on WG objects to this course (i.e. friday deadline, require
rewording) of action.
-- Requirements coverage by spec, preliminary reports:
Sections 4.4, 4.5
MarcH: are we not supporting intermediaries and keeping quiet about it?
MarcH: MEPs are fundamental.
Henrik: have not thought enough about how MEPs work with intermediaries.
They may or may not work. Hence the proposed note.
Glen: originally, we wanted to be able to enable the request-response MEP
with a one-way MEP plus header block. We have all the pieces, but they did
not make it into the spec at this time.
Noah: yes, we failed to elucidate the state machine for intermediaries. I
wanted to go there, but the WG was relunctant.
Glen: is there still a problem with the new wording? In most cases, there
are only two messages.
Henrik: we need to be careful about what we support exactly.
Glen: maybe this is all work for SOAP > version 1.2?
MarcH: I'm not sure how this leaves us. We're not saying we do support
Glen: I agree.
MarcH: e.g. do we enable propagation, etc.
Glen: We do enable as part of processing model, and in binding from one
node to another node, although we don't enable over the complete path. So,
the pieces are there; The spec is probably OK for now. The other option is
to go back to LC.
Noah: It may com up as part of CR when we will need intermediary testing.
Henrik: we use a trick to test intermdiaries.
Noah: if intermediaries can use the current MEP, the trick is fine.
Glen: the request-response MEP is trickable.
MarcH, Noah: "trick" has a pejorative connotation.
Henrik: this discussion is on a slippery slope.
David: we need email traffic on R811 and R808.
MarcH: my note about intermediaries not being supported will NOT be
included in the spec.
David (to MarcH): please resend your report to initiate email discussion,
and include this clarification.