1. Roll call
2. Agenda review:
DF: I18n WG has requested review of CharMod document by 31 may. DF notes this is a last call review
request, and as XMLP is going to last call shortly, it would be prudent to provide such a review.
Are there any volunteers for this review?
No volunteers came forward.
DF: Need to find some other means for obtaining volunteers, offline.
AI - David.
DF: Regarding, May 1 - Europe holiday. We will have a telecon. This telcon is slated for making a
go/no-go last call decision. However, we will ensure that if such a decision is to be taken, everyone
will be given an equal opportunity to participate in any important decisions, document review, etc.
Options for providing such opportunity include e-mail ballot, postponing decision to the following
week telecon, etc.
3. Approval of 10 April 2002 minutes.
No objection to approving the posted minutes.
4. AI review
5. Status Report
DF (on behalf of Nilo): Is currently on track and up todate.
MH: Have made few changes recently. Very few items on the to-do list.
HFN: Recommends reading the April 11th spec.
DF: TBTF has a proposal for 197 which is on the agenda. Couple of other small items to deal with,
on Friday meeting.
MH: Does this include the overlapping request/response?
Anish: We have modified the conformance doc based on Noah's comments. Have
replied to HFN's comments. The snapshot of the conformance doc on the web
page is not available yet as promised last week. Will be done ASAP. It was a
lot of work to synch up with March 3rd version. Need to synch up with April 11th
spec and hoping that is not going to be a major task.
JI - nothing to report
BL not present.
Higland: New revision has been submitted. It has possible dependency on new text
TBTF is working on.
No questions were asked about the readbility plan that was referenced from the agenda.
6. Loose ends
DF: Are there any issues lurking on the mailing list that didn't make it onto the
MH: There are some issues Asir raised that are not on the list.
Yves: Thought he made them as comments and not raised as issues.
DF: What is the nature of comments? are they on dist-app?
JF: E-mails from Asir in April.
(regarding first of Asir's issues)
DF: we need to ask Asir to come out with a proposal
on serialization/deserialization rules.
HFN: Gudge had comments on Asir's other points.
Noah: We tried both ways - serialization and deserialization. Doing the
suggested way is coherent and hence we did it this way.
DF: Noah or Gudge would write down the fact that trying it this way was
better. AI to Noah.
JK: Asir 2nd issue (locally scoped Vs globally scoped). Commented that Gudge
said the label is to be taken as a Qname. Remove locally scoped/globally
scoped ids. AI to JK to write it down.
DF: 3rd issue: EII's- edge or node?
JK: Commented that Gudge feels EII can represent both.
Noah - Felt the text was very clear. Is this a proposal to change the text
or just an explanation
JK: No proposal, just explanation.
Noah: Node with a ref is an edge. Node with an id is both.
DF: AI to send a mail to Asir to check whether Gudge's reply is adequate.
Noah: We have covered the issue. No change to text but he has another issue
which we don't want to table now.
DF: 2 parts to this. First part is TBTF has proposed wording for 197. The
second is issue 61
MH: Outlined proposed changes. They involve edits to the existing text.
DF: In sum, 3 rules are proposed. some of which have ripple effects on the text.
DF. Is there any discussion of the proposal?
DF: Is there any objection to closing the issue with the proposal?
No objections raised to the proposal.
DF ruled that Issue 197 closed with the proposed text.
MH to send e-mail to xmlp-comments
DF described the 'extended' b option for issue 61. TBTF consensus is as
described in the telcon agenda. They will create a document during LC
describing an attachment feature. That document will not claim to be a
complete description, but will be billed as a partial one that could be
taken over in future work. Similar spirit as e-mail binding. Form of the
doc will be non-normative.
HFN: 2 comments. Regarding outcome of document and work. There is already
work going on in IETF that is very much addressing this area. The
opportunity should be kept open for other WGs. We should look at a plan with
a concrete proposal rather than an abstract one. IETF work is a specific
representation of how such a feature might look. We should have a plan that
talks about how we intend to come out with a complete solution.
MH: Thought there was a willingness in the group to provide a complete
description of a feature.
Noah: Do we need to settle with regard IETF and W3C work before we start
the work? Noah feels we can start the work without waiting.
DF: there is a precedent for IETF & W3C to jointly work on docs. Been done
many times. Whether the doc has IETF or W3C logo is something that need
advice from W3C. Can Yves answer that? DF Hopes we could go on now and defer
that particular question.
Noah: If all the work ends up in IETF, W3C must have a role in it as we have
the SOAP knowledge and expertise.
DF: Should we start working here and then say this is what we mean and then
ask the question where should this be completed?
Yves: Don't know exactly. Next IETF/W3C telecon is May or June. I will discuss
the question with the W3C team.
HFN: It is not so much a question where the doc ends. It is more that the
work is already going on in the IETF. Agrees with Noah on overlap, mutual
understanding. Feels not a good idea to go off and do something on our own.
We should take advantage of IETF-W3C co-ordination
CF: Confused. I don't understand the deal with IETF.
HFN: There is an existing SOAP-DIME IETF draft and it is being discussed.
Instead of going in a different direction of our own, we should work with
IETF to continue the work.
CF: I understand the work in IETF and the author is on the call. No problems
with co-ordination. But why we need to complicate the organization? We have
the expertise to do it. Who is participating from the IETF aside from HFN?
HFN - It is a working crowd of people. Not clear the relationship with that
work and the note we would produce. What is the easiest way to start work on
CF - Clarified but confused.
PaulC: Regarding the IETF liaison, the next call is not scheduled for 3 months.
Don't see why we can't own the internet-draft.
MH: Existing IETF-draft is towards DIME but we haven't yet decided on DIME.
Some people will be interested in SOAP with Attachments. We need to separate
the abstract and the concrete implementation. Not sure the IETF is looking at
HFN: My proposal is not to adopt the draft. We could separate that into 2
Noah: It is important to split the draft so that others could do with what
ever implementation they need.
HFN: Agrees with Noah.
JI: Reinforces Chris's viewpoint. S+A is an alternative. Don't want anything
to delay the final XMLP recommendation. Supportive of something that points
to concrete implementations such as DIME or MIME.
DF: Overall our views are not so very different. There are mainly 3 things.
(1) PaulC wants the possibility of an IETF Attachment Feature document.
(2) We need clarification on what constitutes completeness. Completeness
doesn't have to cover all corner cases, but should be complete enough.
(3) The doc we produce shouldn't prejudice any particular implementation.
DF: Question to the WG, if we amend the agenda proposal for 61 with these
three considerations, do we have a coherent proposal?
No objections raised.
DF: Are there any objections to closing issue 61 with the proposal in the
agenda, plus the above 3 points - DF will write-up the actual wording - ?
No objections reaised
DF rules that issue 61 closed.
8. Fault related issues.
3 parts: issue 192, question to editors, issue 201
Part I, issue 192:
HFN: Tried to figure out the exact points we are trying to address. Picked
out 5 issues. HFN read through the list in the proposal explaining the contents.
MH: WG hasn't yet agreed to the formulation of faults in the current
editors draft. Previously a fault was indicated by the body containing a
fault element. The draft now says that a fault is indicated by the body
containing a fault *and nothing else*. Feels strange that a message with
a fault in the body where the body also contains any other element is
*not* a fault.
HFN: It is the fault itself that says when is a fault.
MH: Fault says what is wrong? Not how to process it?
DF: How would your concern affect the proposal.
MH: We should loosen it by saying, one may take it as a fault if there is a
fault in the body, i.e. leave out the other constraint that fault should be
the only element to be considered a fault.
JK: some independent elements can end up in the body after the fault.
CF: If we do loosen it, we have to mention something about the other elements;
don't have to worry about other elements? Generally okay with HFN's proposal.
SW: the MB use case is about quoting a fault. ??? not the use case, we actually
wanted to support.
Noah: Felt that this fault processing proposal is an example of writing
our first spec for a soap body entry. Compared it to the purchaseOrder
example and mentioned that when these things are sitting on soap body this
is what it means. If it is somewhere (as a writer of the specification for
that entry) I have nothing to say. This spec only covers this case.
DF: MH - are you strongly attached?
MH: it is not a lie-down in the road issue but feels we are making a mistake.
Noted that if the body has another element in addition to the body it is not to
be considered as fault.
Noah: suggestion for a friendly amendment:
" Senders must not send messages that has a Fault element in the body and
also additional elements. If a receiver receives such a message, the
implications are undefined."
DF: Are there any objections to closing issue 192 with the proposal with the
No objections raised.
DF rules that issue 192 is closed.
Part II, editors' question:
DF: is the answer clear based on the resolution to 192?
Part III, issue 201:
MH : (missed MH comments)
HFN: Nothing to say. I agree with MH that it is covered and we should talk
about fault as special and close it.
DF: MH and HFN to take an action to write a proposal for this issue by the end
of the week.
9. New issues.
WG note that Glen (issue originator, and strong proponent) is not present.
HFN: think the proposed text (not mentioned in agenda) is a good direction but
needs some editorial work.
CF: Could be treated as a note.
DF: Are you suggesting we defer this to a non-normative part of specification?
SW: sounds like a best-practice kind of thing.
HFN: Glen took it as more than best-practice.
Noah: Not good to talk about this as Glen is not here and he should be given
DF: We should ping Glen to write a proposal/draft. I thought the current text is
a just a set of bullet points?
Noah: on April 10th he sent a proposal.
HFN: Needs wordsmithing.
Noah: Agree with that.
HFN: let us ask Glen to massage it and resend it.
PD: Agree. AI to Paul Denning to ask Glen to send it in time for next week's telecon.
DF: Is the WG going to advise anything?
HFN: At some point, we have to make a distinction between Http. Http has a
good set of properties; we shouldn't address all this in binding but
instead put it in primer.
DF: We are out of time, so we take this to e-mail and revisit next week.