W3C XML Protocol Working Group teleconference, 29 August 2001

1. Roll call, scribes for minutes/action items (12.00 + 5)

Present 29/27 Excused Regrets Absent

2. Agenda review, and AOB (12.05 + 5)


No other items

3. Approval of minutes from Aug 22 [1] telcon (12.10 + 5)


Approved

4. Review action items, see [2] (12.15 + 10)


OLD
CLOSED: 2001/08/01: Frank DeRose: Send summary of the discussions on the
proposals and clarification (including the "kludge" proposal) re. issue
78 to xml-dist-app.

DONE: 2001/08/15: Editors: Propose wording for updated paragraph
regarding discussion in agenda item 6 [Handling application defined
attributes in Infoset description]

PENDING: 2001/08/22: Editors: Introduce term "SOAP Messaging framework"
for part 1 of the specification and think hard about alternatives for
"Adjuntcs" for part 2.

PENDING: 2001/08/22: ChrisF & EricJ: Craft a definition of SOAP
application for the glossary, using Tech def. #1 as a starting point.
ETA: EOB Friday

PENDING: 2001/08/22: Editors: Change rule 1 to refer to server fault in
section 4 in new section 7.3.

NEW
ACTION: Editors: Propose some introductory text for the new specs by the
end of the week.

ACTION: Hugo: Link the new specs from XMLP WG web pages

ACTION: DavidF: put Primer ToC review on next week's agenda

ACTION: Gudge: Reply to the XML Schema WG re. base64 encoding by saying:
"No opinion" copying xml-dist-app, also provide rationale

ACTION: Editors: Remove last sentence of rule #5 in


ACTION: Editors: Clarify the specification indicating that URIs in the
SOAP encoding can refer to resources inside _and_ outside the SOAP
envelope.

ACTION: PaulC: Come up with resolution text for issue 30.

ACTION: NoahM: Come up with a proposal regarding the
support/non-support of XMLBase in SOAP 1.2

ACTION: Hugo: Close resolved issues (as per agenda): 24, 100, 109, 111,
115, 118, 123.

5. Status reports (12.25 + 10)


-- Editors: status of spec and Primer

Jean-Jacques: Has been working on splitting the spec. Document 1 is
section 1-4 and document 2 is the rest. Document 2 has a temporary title
(see action item). No work has been done on the introductory text. We
need to get it done by end of this week. Gudge and Henrik will work on
introductory text.

Vidur: Document 2 doesn't link to SOAP envelope and encoding schemas.

Henrik: Editors need a phone conference tomorrow

-- Primer

Nilo: put out a revised ToC
(http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Aug/0076.html)
which showed how the contents would
move to various sections. Got comments back regarding use of infoset and
compatibility with SOAP 1.1.

-- Transport binding task force

Stuart: Focused on providing a framework for bindings. There have been
several proposals floating around for discussion. The number of things
that the group can agree on has varied as there are several thorny
issues. Some of the issues involve information exchange with the sending
node and the receiving soap node respectively. Looking at instances of
properties in order to figure out what a framework looks like

Some of the things that the group has come to consensus on:

* A binding will be described in terms of a sending and receiving
infoset of an envelope

* A binding will describe how the information is transferred

* Properties may be added to describe certain features of the binding -
looking for feedback in what properties are needed.

We will have a snapshot for the f2f

-- RPC task force

DavidF: Report from the RPC taskforce is already on the agenda for the
f2f. There will be proposed solutions for issues 78/16 and 113. Has also
talked about how the data model and data encoding relates in section 5

6. Proposal for response to XML Schema WG on base64 encoding (if Martin

Gudgin attends telcon) (12.35 + 10)

Gudge: Schema group asked us whether we thought schema should enforce
the multiple 4 character rule or not.

Proposal: Gudge recommends no.

We were also asked whether we have an opinion on base64 encoding

Proposal: Gudge recommends that we don't have any opinion.

Stuart: Is there any worst solution that we have to avoid? Gudge:
Doesn't seem to be.

DavidF: Is the group ok with this? Yes (no dissent recorded). Gudge
directed to respond directly to the XML Schema WG, giving the opinion and a
rationale.

7. Proposal [3] for further modification to section 7.3 (RPC Faultcodes)

[7]. This should provide final resolution to issue 45 [8] (12.45 + 10)

Jean-Jacques: Issue with rule number 5 which currently says that RPC
fault and success both return SOAP success.

Henrik: Is it possible to separate "faults arising in an extension or
from the application" from "Procedure level errors"?

Jean-Jacques: Might make things more complicated

ChrisF: Might be such a thing as runtime errors that can be separated
from application faults.

Proposal: remove the last sentence from rule 5.

DavidF: Is the group ok with this?  Yes (no dissent recorded). Editors are
directed accordingly.

8. Issue 30 proposal [4] (12.55 + 15)


(i) The proposal is to add a clarification to the spec indicating that
URIs in the SOAP encoding can refer to resources inside _and_ outside
the SOAP envelope. Do we accept this proposal, and to close issue 30?

DavidF: Any discussion on proposed clarification:

"In my opinion, the only point that we want to clarify (and it is only a
clarification) is that a consequence of using URIs is that they can
point to anything and not only within the same document (of the style
#foo). Some implementers may be surprised that the value of the href
attribute could be something like "http://www.foo.com/some.doc" if we do
not point this out in a clarification. In addition we might want to
indicate that they can point to an attachment to the SOAP message [3].
In both of the latter cases we want to be sure to indicate that these
URI's point outside of the current SOAP message."

No discussion.

DavidF: Is the group ok with this?  Yes (no dissent recorded). Editors are
directed accordingly.

(ii) Further discussion stemming from the proposal (see thread
originating at [4]) concerned whether or not SOAP 1.2 should explicitly
define the role of XML Base. That discussion reached the following
choice-point:
    (A) Defer consideration of XML Base until after SOAP 1.2
                or
    (B) Explicitly define the role of XML Base in SOAP 1.2 (Choosing
either option will add an issue on the subject of XML Base to our issue
list. Resolution of the issue will obviously vary depending on our
choice of A or B.)

ChrisF: Think we have to address the issue because of interop issues

Noah: I tend to agree with that. Not clear what W3C calls upon what we
have to do. Two ways we can do:

1) When you use relative URIs in a SOAP document, the base will be
presumed to be X.

2) It is explicitly undefined

Regardless of which direction we take we should talk about

Hugo: If a spec doesn't explicitly refers to XMLBase then the definition
is undefined by default.

PaulC: Why doesn't SOAP refer to it today?

Noah: I think XML Base only works with relative URIs

PaulC: Are we sure that implementations can support XMLBase in order to
get interoperability or does this require that we stretch the timeline
for SOAP 1.2?

ChrisF: Think we have to say something about XMLBase regardless of what
its impact may be. We should say something about it. I am not saying
that we should adopt it.

Noah: Rough wording proposal: This spec defines no value for the XMLBase
property value

PaulC: We need to know from implementations whether they are willing to
go farther but we haven't had that discussion.

Hugo: Concerned about this approach: What if I don't have
interoperability because of XMLBase

Noah: There are two things that we may want to say *if* we don't have
anything to say about XMLBase:

A) SOAP makes no statement about the use of XMLBase but applications may
treat relative URIs (XMLBase) as
they choose
B) SOAP makes no statement about the use of XMLBase and applications may
not use relative URI's (XMLBase)

PaulC: I think we need to make a proposal and go offline

DavidF: straw poll of WG sentiment indicates no-one is unhappy with asking
for a concrete proposal in the spirit of Noah's (A) suggestion, and so Noah
is asked to generate such a proposal.

9. Issue list (1.10 + 20)


Issue 24[z1]:

Seems to be a misunderstanding from unknown originator

DavidF: Is the group ok with closing this with the given resolution?  Yes
(no dissent recorded). Issue list will be updated with the resolution.

Issue 71[z2]:

Hugo: Thought that this issue has been resolved but MarkN wasn't sure.

Noah: Section 2 now does define that there is no order but that it is
possible to introduce order using the mustUnderstand attribute.

DavidF: Seems that the combination of the various parts of section
addresses the ordering part of the issue.

Hugo: MarkN has signed up for sending a proposal to the list

DavidF: Let's wait for that. However, we do have a resolution on the third
part of the issue as listed in the agenda, i.e.
"Also, SOAP's processing model does not dictate the order in which
multiple headers should be processed, if targetted at the same
processor".

Stuart: Regarding the issues listed in the "resolved" category of the
"issue summary" (i.e. 100, 109,
111, 115, 118, 123) list that appears in the agenda, I propose we decide on
them en masse rather than individually.

David: Is this ok with the group? Yes (no dissent recorded). Issue list
will be updated with resolutions proposed in the agenda.

END