W3C XML Protocol teleconference, 23 May 2001

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

Present 37/32 Excused Regrets Absent

2. Agenda review, call for AOB (1.05 + 5m)



None

3. Approval of minutes from May 16 telcon [1] (1.10 + 5m)

4. Review action items, see [2] (1.15 + 15m)



Pending action items:


2001/03/28: David Clay
Start working on reconsiliation between what he has proposed with the most
up to date version of the AM and Henrik's glossary mapping.


DavidF: Still pending.
DaveC: Need to do another draft based upon the outcome of Noah's proposal.
Some info about ordering in it and that would require changes to  several
other things.


2001/05/16: Paul Cotton
Figure out what the XML Schema Type Lib taskforce is doing and report to
the WG by next week.


DavidF: No progress to date. Paul asked questions, but has yet to hear
back.
ACTION: Paul will ask again next weeek.


2001/05/16: Noah & Henrik
Propose a set of clarification issues based on Noah's mail and hand them to
DavidF for inclusion in the issues list.


Noah/Henrik: Not fully completed.
ACTION: complete within the next few days.


2001/05/16: Henrik
Provide proposal for ordered header entries by friday EOB. Also drag in
Glen and Noah.
ACTION ITEM COMPLETE


2001/05/16: DavidF
Make the WG start thinking about issues and how to solve these issues in
time for the f2f meeting.


DavidF: Sent out email yesterday that describes one avenue from which we
should start thinking about issues. All members of WG should peruse
current version of spec to look for further points of clarification
(non-editorial). Need to start pulling these into issue form for
resolution.


DavidF: All members of WG should read the spec. Some of the issues have
come from other sources (SOAPBuilders and SOAP Developers). Need 2
volunteers to ping each group to solicit other issues of clarification that
we could then consider for addition to the list of outstanding  issues.
Doug will ping SOAP Builders list. Henrik to ping SOAP Developers list.


PaulC: email should request that comments be sent to the XMLP comments
list. Goal is to have a message that we will be able to respond to. As
long as there is a W3C archive that we can respond to, that's fine.


Noah: Disagrees. Feels that design questions should be covered on dist-app.


DavidF: Make sure that Doug and Henrik send email with appropriate cc's to
ensure that W3C captures all


Noah: Feels that occassional cross-posting to dist-app may benefit all.


ACTION ITEM COMPLETE




DavidF: 5 issues here from our issues list. Take 30 minutes to go through
these.

5. (1.30 + 30m) The following are some issues of clarification that exist

already on our issues list (there are others). We discuss each issue in
order to: (a) determine what exactly is the issue being raised and whether
it is bona fide, (b) briefly discuss ways of resolving it, (c) assign an
owner responsible for generating a proposal.


------------------------------------------------------------------------------------



    i16 [3] -- RPC mapping is not clear on how a method with a void return
type and no out arguments should be mapped onto the SOAP protocol


DavidF: Do we consider this . The spec doesn't say how to handle this type
of situation. Is this the case? Is there an obvious response to  this
issue?


Henrik: This was discussed a long time ago. It boils down to HTTP and
getting back a response, but it could be seen in other contexts. Should  I
send back an empty SOAP envelope or send back an empty HTTP 200 or 204. but
I don't have anything to send back to you. That's basically the issue.


DavidF: How to handle it in non-HTTP situations?


Henrik: Need to deal with this from an RPC convention point of view.


DavidF: Can we send back an empty message?


Henrik: The question is do we want to send anything back at all. From a
convention point of view we send back 200 HTTP OK. If there's nothing to
send back, I can't see the benefit of sending back an empty envelope.


DavidF: Couple of different points of view. If the semantics of the app are
that you want to know that it is impt for the sending app to know  that
completion occurred, but there is no data from the RP itself, then you need
to send something back, but on the other hand you can use  HTTP 200/204 to
send back


???: Both mechanisms may be useful


MarcH: RPC convention is that you send a function, and you block until that
message comes back. If we're talking about RPC here, then you  need to have
some indication that the function has been completed.


DaveO: Would prefer to have an empty envelope come back for RPC-style
message exchanges


Hugo: Should remain an empty envelope


DavidF: Assign an owner to this and summarize an argument pro/con. Frank
Rose to take ownership of this issue. Pass on issue to dist-app.


PaulC: Frank - are you proposing changes to section 7.1?


FrankR: No, not exactly.


DavidF: The issue is ambiguous on this point. THe RPC portion does not say
what should happen when an RPC returns.


PaulC: Valuable to weave through the text in 7.1 and hypothesize how 7.1
can be interpreted in the context of the issue (void return)


Noah: One of the things that is tricky with RPC, is that SOAP doesn't
really say anything about methods or procedures that might be out  there.
SOAP does or does not allow a return convention (which does reflect a void
return).


FrankR: Not going to present a position, just going to outline the issue.



    i19 [5] -- spec currently does not require any namespace for the
children elements of the Fault element; namely, faultcode, faultstring,
detail, and faultactor. These elements are therefore in the default
namespace


DavidF: clarification of this issue? discussion of this? does he have a
point?


???: Yes he does.


DavidF: Should this be clarified in the spec.


???: Yes, definitely.


DavidF: Do we believe that this was simply an omission?


Henrik: One of the reasons is that is consistent with the section 5
encoding.


MarcH: If you use a default namespace, then you don't have to redefine the
very namespace that your trying to define.


DavidF: This issue is a bit mushy.


PaulC: The children should come from a namespace. There are several ways to
do this.


DavidF: You could fix this by requiring that the child elements must be in
the same namespace as the fault, body, and envelope. Whether you use a
default or other mechanism such as prefixing.


Noah: Recommendation that we all try to use a consistent methodology,
namely qualified namespaces.


PaulC: Is the schema open?


DavidF: FaultCode and faultstring are members of the default namespace.
They could be part of an envelope and not be required to be namespace
qualified to that namespace - that seems a bit odd. Need to look at the
actual text for this (4.4). Need to understand what the issue  is here in
the context of section 4.41


ACTION ITEM: Henrik to take ownership of this issue. Timeline - will send
out by EOB tomorrow (24/05/01)




    i20 (point 2) [10] -- Unclear of HOW Schemas are meant to be used


DavidF: specifically within SOAP. General plea to explain the use of
schemas in SOAP and provide further clarification. What is the recommended
way of using schemas in SOAP. What is the intended use of schemas in SOAP.
It's not a very well laid out issue. He doesn't point to a particular
portion of the spec. Does anyone have any more detail on his issue? We can
have someone own this issue and ask Steve McDowell to provide further
clarificaiton.


Noah: Some of the things are at best subtle. On the one hand SOAP does not
mandate the use of Schemas. But, there are other things that "you don't
have to validate this" but here is something that you might have to know if
you were using a schema language. It might be easy for someone to miss
these types of subtleties.


DavidF: So do we need to provide further clarification on this?


Noah: Need to tease out "this is what we're trying to bring out" and this
is leading to some confusion?


???: How is Schema location to be used - is that clear?


Noah: This goes beyond the use of SOAP 1.1 - it doesn't mandate the use of
schema types. e.g. XSI type, W3C Schema location.


DaveO: People want guidance on how to use Schemas with SOAP and want some
"best practices"


Noah: not sure this belongs in the SOAP spec. Recommend that someone in a
separate document (e.g. WSDL) outlines how to use schemas with SOAP.
Recommend that this not go into the core SOAP spec.


DavidF: Noah's suggestion that a detailed explanation of how to use W3C
schema with SOAP is not appropriate in the core spec. It's probably
necessary to clarify in the spec that SOAP does not require the use of
schemas. I would like to give someone responsibility on this issue. Dig
into both sides of the issue - are there large numbers of people that want
to know how to use W3C schema with SOAP, and provide details on what would
be required to provide such clarification.


PaulC: Answering this question would add no new conformance material to the
SOAP spec.


DavidF: Do we close this issue and leave the spec as it is?


DaveC: There was something in the WG charter about the serialization
functionality using Schema.


DavidF: We might decide that is requirement is met with the current
specification.


PaulC: Will volunteer, but would prefer to go back to original commentator
to get further clarification. Will first send a private note, and then ask
him for permission to make it more widely available.


ACTION ITEM: PaulC to send an email tomorrow to this person.




    i25 [11] -- spec is somewhat ambiguous on the matter as it allows
"other stuff" after the body but doesn't say what to use it for or what the

processing model is


DavidF: Initially this is brought out by the question on whether or not we
can have footers or trailers after the body element in an envelope. It's
been noted that the spec is simply ambiguous as to what the function of
these footers are. Henriks proposal makes reference to these trailer
elements. Need to clarify what the function of these trailer/footer
elements are.


Henrik: You can stick things after the body, but there are no processing
rules (mustUnderstand, etc) required by the spec for these trailer/footer
elements.


DavidF: Need to have a proposal for explaining what is the role of these
trailers vis a vis a processing model. Henrik's proposal doesn't make
mention of any kind of ordering, and processing requirements.


Henrik: Willing to clarify on this.


DaveC: Will take on this issue, but won't be able to do it by Friday.


ACTION ITEM: Dave Clay to take on this issue.


DavidF: Overall - need to look at the spec and tease out all ambiguities.




    i78 [4] -- is there any defined order of the struct that is the
response, and the other independent serializations within the body?


DavidF: May also interact with the RPC issue. Basically asking about the
ordering of entries in the body of a response in the RPC context. Does it
make sense to collapse this and make it part of 16?


FrankR: I see the connection here, and I'd be willing to collapse this into
issue 16.


DavidF: Does this make sense to do?


FrankR: It very well could be related.


DavidR: We'll keep it as a separate issue but will be considering it in
conjunction with issue 16.


ACTION ITEM: FrankR to look at this issue in the context of issue 16.

6. (2.00 + 25m)



Issue #100 [7]


As part of our discussion on the implications of mU and its ability to
support a directed sequence of intermediaries, Henrik agreed to make a
proposal for ordering of header entries. This is now available [13]. In
addition to considering the proposal itself, we need to summarise the
various aspects of the mU discussion to date (I think this includes at
least Noah's dependency proposal and Henrik's order proposal) in terms of
what we are trying to accomplish, and to prepare proposals for decision at
the f2f.


David F: Useful discussion to date on clarification. Need to take stock of
where we are and figure out if we have proposals on the table.  Need to
push the WG to get closure on these issues.


DavidF: We started a discussion on the mustUnderstand attribute. Lots of
good discussion on this issue. Sprouted a proposal from Noah on dependency
and then as of the last call sprouted another shoot on the ordering of
header entries, and the responsibilities of processors in handling them. We
have a few proposals before us and we need to start thinking about making
some decisions on these proposals.


Noah: Would suggest that there are 3 things related here on the table
        1 - my proposal raised issues on what mU is really all about. This
raises some issues about message routing, but there are other issues that
still need to be explored. Need to come out with one set of coordinated set
of issues that map to the context


        2 - Henrik made some proposals on the order for processing header
entries and ordering. He's implying that it's somewhat atomic


        3 - Question of can mU be used as an extension mechanism? e.g.
putting mU on a header. Glen noticed that if a SOAP processor doesn't
recognize the mU in the header which may contain additional dependancy
rules, there might be some problems here.


Issues with multiple headers reaching the same actor.


Henrik: The starting point for the proposal I sent out is about how to deal
with the processing. The assumption was that we might want to have multiple
different ways of expressing dependencies. How can we mU as an
extensibility mechanism but have the least hooks into the SOAP spec to make
this possible. How do I know where I should stop?


Noah: Glen's issue stikes me as the most fundamental. mU is offered as a
fundamental extension mechanism. This is a high priority issue. Can it be
used as a stable extension mechanism. Recommend that we get to the bottom
of this and take a hard look at Henrik's proposal.


DaveC: In looking at the module template, if I'm defining a new module, I
need to state the dependencies on other modules, but there may be future
dependencies on modules that don't yet exist (e.g. an encryption module).
Also the issue that we've qualitatively identified these modules and
installed them in a processor, the processor probably knows about these
dependencies, but a proccessor would probably know whether or not these
dependencies are corrent or not.


DavidF: We should go through Henrik's proposal and go through the
fundamental points in the proposal to make sure that Glen's issues are
adequately met.


Henrik: Processing of SOAP messages currently only utilizes pass/fail -
like HTTP. Always fail in a binary sense. Either it succeeds or it fails.
At the SOAP layer it succeeds or fails. Once we have this model, it is
difficult to introduce the notion of complete ordering within the message.
(e.g. I get through 3 headers and the 4th fails - SOAP does not really
handle this). Can I do some type of partial ordering or do I need to do
complete ordering? SOAP processors need a way to add headers that won't
interfere with ordering and dependencies. What are the minimum things that
we need to do within the core SOAP spec to allow ordering. Offered four
different conventions:


1 - from a fundamental SOAP point of view, it's only success or failure
2 - intermediaries must not change the order when they see a message coming
in. They can add and remove, but they cannot change the order of header
fields.


3 - 2 ways to deal with ordering under the assumption that they are using
mU. One way is to use the XML Encapsulation mechanism - wrapping them
lexically within the message. This means that SOAP is not able to see the
inner headers. All links you have should point forward in the message


DavidF: Is this a fully baked proposal yet?


Henrik: Not yet. There should probably be more discussion on this issue.


Noah: Point of clarification. Is the building block you're requiring in the
SOAP 1.1. spec today?


Henrik: The text can be interpreted in different ways.


Noah: What about for more complex transaction-based scenarios? What happens
when you process the first 8 headers and the 9th blows up? Say a credit
card fails. Do you roll back the entire transaction???


Henrik: SOAP doesn't actually say anything about what you have to do in the
headers.


Noah: It is consisent with the SOAP spec to not tell an actor to roll back
in the header.


DavidF: Need to see a summary of these issues.


ACTION ITEM: Noah/Henrik to send an email to discuss this issue. Noah to
send a public response to Henriks email on the public list.


DavidF: This should lead into a discussion on Glen's issue. Need to make
some clarification to the spec. Need to come up with some suggestions on
how to resolve this. Also need to look into Glen's issue.


Noah: This is also related to Glen's issue, and should be taken into
account when looking at the overall context of this discussion.


--------------------------------------------------------------------------------------



[END OF CALL - ISSUE 99 NOT DISCUSSED DURING CONF CALL]





Issue #99 [9]


When a "mustUnderstand" fault occurs there is no way for the receiver to
know exactly what caused it. There are 2 alternatives in Glen's proposal
[8]:
(1) new elements in the fault element to specify the QName where the
failure occurred
(2) a new header with copies of the misunderstood headers





Alternative 2 can indicate what caused the fault without breaking the
existing extensibility model, however we ran out of time in the last telcon

when we were discussing how to return multiple faults. This is where we'll
pick up the discussion.

7. Any Other Business (2.25 + 5m)



None


References.
[1] http://www.w3.org/2000/xp/Group/Admin/#schedule
[2] http://www.w3.org/2000/xp/Group/Admin/#pending


[3] http://www.w3.org/2000/xp/Group/xmlp-issues#x16


[4] http://www.w3.org/2000/xp/Group/xmlp-issues#x78


[5] http://www.w3.org/2000/xp/Group/xmlp-issues#x19


[7] http://www.w3.org/2000/xp/Group/xmlp-issues#x100


[8] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0218.html


[9] http://www.w3.org/2000/xp/Group/xmlp-issues#x99


[10] http://www.w3.org/2000/xp/Group/xmlp-issues#x20


[11] http://www.w3.org/2000/xp/Group/xmlp-issues#x25


[13] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0284.html