| Tuesday, June 5th |
|
| Morning Session I, 8.30a - 10.15a |
|
| Break, 10.15a - 10.45a | |
| Morning Session II, 10.45a - 12.30p |
|
| Lunch, 12.30p - 1.30p | |
| Afternoon Session I, 1.30p - 3.00p |
|
| Break, 3.00p - 3.30p | |
| Afternoon Session II, 3.30p - 5.00p |
|
| Wednesday, June
6th |
|
| Morning Session I, 8.30a - 10.15a |
|
| Break, 10.15a - 10.45a | |
| Morning Session II, 10.45a - 12.30p |
|
| Lunch, 12.30p - 1.30p | |
| Afternoon Session I, 1.30p - 3.00p |
|
| Break, 3.00p - 3.30p | |
| Afternoon Session II, 3.30p - 5.00p |
|
| Evening: Visit and dinner at Mont Saint-Michel | |
| Thursday, June
7th |
|
| Morning Session I, 8.30a - 10.15a |
|
| Break, 10.15a - 10.45a | |
| Morning Session II, 10.45a - 12.30p |
|
| Lunch, 12.30p - 1.30p | |
| Afternoon Session I, 1.30p - 3.00p |
|
| Break, 3.00p - 3.30p | |
| Afternoon Session II, 3.30p - 5.00p |
|
We are behind schedule within the WG in general, we need to make progress.
Due to travel and connectivity problems, last week's telcon minutes were not posted. We will postponse their approval until thursday.
Scott Isaacson volunteered to scribe.
DF: Are we doing SOAP or something else? When posed in this way, the question is divisive and polarising, and it is not productive to frame the question as such. SOAP addresses envelope, encoding, some RPC. We have noticed over the last few weeks that many smart people can read the same spec but still disagree. By discussing and moving forward, the result is XMLP which has a new collective understanding. Also note that we are not going to move reliable messaging (for example) into XMLP 1.0, we are deciding something now that can be used as the basis for moving forward in the future.
HN: One clarifying question. You said "Where does SOAP end and where does XMLP start" I need to understand. Are we doing XMLP 1.0 or SOAP 2.0? If we say we have fixed ambiguities, variables, and other disconnects in the SOAP 1.1 spec, and call it something else, then what have we done?
DF: We are XMLP WG in W3C. We are charged with looking at SOAP. It is incumbent on us to make sure we stay anchored to the existing communities. Therefore, we are allowed to call this XMLP.
GD: Even if we just changed bugs in the spec, we would have to have a namespace change due to the new semantics.
Other discussion started, but DF postpones it until the publishing discussion which is scheduled for later in the meeting. DF wants to proceed with issues and action items.
3/28 David Clay: Pending, DavidC is not here.
5/23 Paul C Clarification on i20 f2f. Original correspondent agrees to close this no action.
*** Action Item Paul C to send close issue message to originator and to the mailing lists.
5/23 David C: Proposal for i25. Saw it on Friday. This is done.
5/23: i78 Frank D. has a proposal circulating. This is done.
5/30: i23 and 4 This is done
5/30: Clarification from PC about i30. Pending
5/30: 14 and 66 Done.
5/30: Mark N done
5/30: Stuart Done
5 Questions from NM
NM: mU is the most basic building block for extensibility. Some doubt about the validity of that statement. Assume SOAP had no intermediaries. All headers are addressed to the destination. Open SOAP spec in section 2, processing model. The wording needs to be clarified. Is it "check mU all" and then "process all" ? or is it "check mU then process" then "check next mU then process" etc. If B is both final and next does it check all "next" and then B or both together, etc.
Why is this a problem? The Glen Paradox (GP). Introduce the extension and mU. Only a problem if you noticed it after you didn't do it right (i.e., ordering). Some people balk since they have been building a streaming process for SOAP.
Let's consider the questions in a different order.
HN: Why is it the way it is? Why can it be read 2 ways? SOAP is a wire protocol. Two declarative statements: sticky notes on each header - mU and actor. "Look at all vs start right away" is not a new question for protocols. It is left open in the spec due to not wanting to specify implementation, just protocol. There was no order implied, so don't assume it. After reading this what about "streaming" vs "read all". Still the answer is "it depends". Could we introduce "normally you can do what you want to do, but in this case do it this way" (which comes first encryption vs compression - order matters). It doesn't make sense to say things like "you can't do streaming"
DF: Noah said there are implications to reading the spec. HN said we are reading far too much into this. The spec is not ambiguous, the spec is open to all these kinds of things. If so, where do we stand with the Glen paradox.
GD: What are the requirements of atomicity and roll back. We are building a streaming SOAP processor right now. You can do whatever you want if (1) it doesn't have side effects or (2) it can be rolled back.
HN: What if the first header you get is a mU that you fail on. What if you fail on the header processing rather than the mU error. mU must be understood for all headers first.
Jacek: Regarding streaming, I have some experience with building SOAP processors. Streaming part only helps with body - headers don't matter that much. The body is the big part. We could stream headers, but say order is important. So you can fault with client fault even before latter mU. Would not inhibit us, would help streaming.
Gudge: Push mU in the application, i.e., have child headers that have order defined by application semantics. We want to address the issue at a core level. 1) Do you have to process mU fault? 2) How do you approach application faults. Clarification,
Doug Davis: Spec is not as vague as Henrik thinks it is. Suggest that all mU first is too hard.
HN: Is ordering important or not? What do I deal with as a SOAP processor? "How" is up to the processor, "what" is up to the protocol. Hints could be very nice. How about "all dependencies must be forward" Does that imply order in all things?
DE: Is this a two pass or one pass process?
GD: Order is built in or parse all.
PC: To say that "the spec should specify order of errors" is disastrous. At best, the spec should define the order of severity not the faults. Order of errors is too restrictive. It is possible in the processing of headers to talk about severity (i.e, all mU first is OK).
NM: Spirit is right, whether severity is the key is a question. Jacek jumped to a conclusion that I like. The headers are different than the body. First come headers and they are hints. The body is the real work. What about a header that comes in saying "log the transaction or do nothing". We could explore a small modification to SOAP that deals with the processing model at the end point, and put in a statement that the BODY is different than HEADERS.
MJ: Leaning toward the proposal by Henrik, i.e. check conditions on a block by block basis. If (1) I am the actor, and (2) I understand the header, then process the header. You could get an application level fault first before the mU. What about some dummy mU first if they are really important.
HN: The role of the body is not different, but what you stick in there might be different. Ordering is bad for intermediaries. If we have dependencies then partial ordering is important. It might not be serialized.
SI: Forward references imply ordering.
NM: Total ordering is impossible.
SI: I agree.
DD: Headers are not as light weight was implied.
NM: Two points,
Jacek: Suggest that headers at the top level be ordered, children of headers are un-ordered.
Glen: Ask NM and PC about their thoughts on this.
NM: Intuition says unordered, however it does depend on certain things. What
if we made headers hierarchical. mU could be x levels deep in the tree.
This is a deep issue.
YL: Not just a simple 1 level vs 2 levels, but what about splitting application and SOAP processor. What if the word processing app has some SOAP examples.
HN: Echo service should work just fine.
Jacek: But only at two levels - not arbitrary hierarchical.
DF: We are getting to the end of the session, and there have been a number of discussion threads ranging from severity, to multiple levels, to 2 levels, to mU errors first vs application errors (only if unordered). We still have 3 or 4 dimensions we are iterating over. We need to figure out how to move the issue towards closure. We are spinning out rather than in.
MH: We don't really have that many dimensions. The choice seems to be: 1) Look at headers first, or 2) Partial ordering.
DD: Scan all or order. Yes.
NM: In general there is not an order, but if there is, lexical order is important. What about actor issues. What if I am A, next, and Q. Piece of software must include next, A.
GD: We don't have to worry about actors when thinking about order.
UC: In principle, are you forced to do some processing in order to understand Y or N? Clearly state that no processing that results in externally visible action is required.
break
DF: At the end of the last session, we came up with 2 choices: A) check all mU first or B) lexical (partial) ordering
GD: "FireNuke" and "GetPresidentialAuthorization mU=1" works for check all mU first, "GetPresidentialAUthorization mU=1" and "FireNuke" works for order
DD: But lexical order is not guaranteed, it might do it right, but it might do it wrong.
J-JM:
MJ: What about actors doing one but not the other? Wait, let's solve the point-to-point first and then worry about intermediaries.
NM: If order is important, both sender and receiver need to worry about order. On the sender side, buffering might be an issue.
Chuck: What about process control? Is this another example? Yes. Move on.
HN: What about saying not "what has to happen" but "what I did" (encryption and compression example - do it any way you want, but I am just letting you know that I did this and then that). Keep trying might be worse than non-optimal, it might have side effects.
Jacek: Can't rely on application ordering at protocol level.
MH: Back to the decrypt example. What if I decrypt and it fails - does the protocol fail or does the application move on and try other things?
HN: Can write a streaming processor, if it can take hints from the modules.
MH: Can't write a generalized streaming processor.
Jacek: HN are you advocating A?
HN: It is more tricky than that. Sometimes
you can throw a fault before you are done processing. Sometimes you throw the
fault only at the end of processing.
DD: The processor has to look at the whole message. Consider a security example: If the first header fails, then for security reasons, don't scan the rest.
GD: If your processor is designed for optimization, then it must cover faults that happen because of the wrong optimization. These are not protocol or application but optimization therefore do not flow back to the processor or sender.
HN: Agree with Glen.
GD: You must understand order or not. You can't introduce order into an unordered world.
Marwan: What about just an extension header.
NM: How do you introduce ordering into a processing model that is unordered? Do we have an extensibility model to SOAP? If so, how does it apply to ordering. Software in general, even optimized multi-threaded stuff, it still wants to do the right thing.
NM: Perhaps we really have 3 proposals.
HN: There is magic in both A and B.
DF: If you want to introduce an ordered header in an unordered world, how do you do it?
DD: mU does imply change of semantics, therefore, it must be understood. What about body, it is the same as headers with regard mU?
HN: Still trying to answer your question. Can you ask again?
Other issues discussed: What about contradictory statements. What about two elements which have different orders. What about the contracts between processors, module handlers, and applications, etc. What if the processor understand, but not the application.
DF: Are these crisp enough to decide yet?
Jacek: Propose that C is orthogonal to A and B. Ask why is B bad. Noah proposed that it is hard on the sender. What about a mU at the end.
Eric Jenkins: Same question as Jacek. What is the burden - processing or checking? Is processing part of the checking?
MH: Disadvantage of B is interaction with actors.
DF: I am hearing that options ABC are subverted by the processing/handler interactions.
HN: One of the goals was to spread the burden across senders and receivers. Intermediaries could preserve the order and not cause any damage: if order was there it is still OK, if order was not there, it doesn't matter.
SW: We could have multiple ordering extensions at the same time?
SI: Can we introduce another more complex envelope?
DF: Not in scope.
HN: Always have this problem even if you push it up to the envolope.
NM: In what style do we provide tools to application/module develop their own semantics and interactions. Don't think I am disagreeing with HN.
JI: Competing mU how do you handle?
NM: Suggest that in defining the semantics of the single mU, it must be specified so clearly as to understand what to do in all conditions.
DF: Are we ready to decide?
Jacek: Do we want to go down the road of
IfXThenYBeforeAAfterCWhenIFeelLikeIt type headers?
NM: Agree, but we don't need to preclude it.
GD: Advocating A, I think.
HN: These 3 short sentences don't cover it all.
DF: What are you proposing: D or clarifications on A? Come back!
DD: I don't want A. But if I am handed id2, id3 mU 3->2, fault it. Want order, but hint.
SW: Is order nice for processing or for message semantics?
MH: What if we made A "SHOULD" not "MUST"
NM: If order matters, then it really matters (nuke examples are a bit tasteless, but consider cash out of an ATM).
HN: What about removing all mU until the last which shows mU on the first
few. Is that A?
Most all: "Yes"
HN: "No"
MJ: Problem with B is client. What about a default of "ordered" with a new extension that says "the rest is unordered" Is this backwards compatible??
JJM: What about mU on some of the ordered list but not others?
YL: Propose D. Every header is hierarchical. Parents first. Then children.
Informal discussions over lunch revealed that A, B and C are all orthogonal, they are solutions to different issues.
Attempt to state the options ABC more clearly:
A) all mUs first
1. Walk through every header (intended for you)
2. if mU =1, then check that you can handle it
N = then will send a mU fault but might continue to walk through
Y = end of all headers and no N yet, start processing. Note that the
processing might be affected by the headers themselves
B) Lexical ordering
NM: A is process all but do nothing if any one is N
B is process up to this one and do nothing more if this one is N, but don't go
back and undo other processing prior to this one
Others: If that is true for B, then strike B.
DE: This is not Distributed Transaction Processing. If you think it is, you are using the wrong thing.
Others: None of these are Distributed Transaction Processing!
DD: There is a difference in A between look at all and process none if any are N otherwise do some/as much as you can but make sure you mU fault on any.
DF: We are not doing full wording here, just ideas.
DD: Agree.
What is A? NM: With or without order. Assume a definition of "What it means to Understand" and "what are actors" If there is any header addressed to a processor, that has mU=1, but that processor does not understand it, then that processor with generate a mU fault and act as if NO headers are processed.
If there is any header for me in the message that is marked as mU=1 which I can not "understand", I must respond by generating a mU fault and not perform any other processing.
JJM: This new bullet in the processing model happens first
NM: This first after "for me" filtering.
PC: What if there are two mU that I don't understand? do I generate 1
fault or 3 or 1 with 3 separate content messages.
GD: Doesn't matter. Leave
"what don't you understand" as an orthogonal issue.
HN: Always a single fault, but can contain a bunch of information.
GD: Is there a difference between "processing", "mU processing", and "SOAP Processing"?
DF: Should we fork the notion of processing? It bumps into issue 99.
DD: We have gone from looking at the whole to thinking that mU processing is special. Some disagreement about the concepts of "is this OK" or "not". Some claim it is an implementation detail. Others think it is critical to the model.
NM: The way we have laid out A, we have allowed ourselves to change every other element of SOAP, including the processing model itself, except for this mU feature itself. In SOAP 3.0 we could say that A and B from 1.1 are now completely different.
DF: Lets try to create wording for B now.
B1: You will process all headers in order until you fail on a mU.
B2: You will not process any headers after you fail on a mU. It says nothing
about processing before the fail.
Are B1 and B2 really orthogonal from A?
DD: We don't want to get into a situation where the client dictates the order.
DF: Do we have an option C?
No C is being withdrawn. Once we decide on "order" but
turn off vs "unordered" but turn on ordering we don't need C.????
GD: B1 and B2 both state no processing after mU fault. B1 says mandatory processing up to that point. B2 says optional processing up to that point.
MG: Is the body mU?
JI: The body in the message is the substantive item.
B makes it harder for client. A makes it harder for the server. Broken or malicious can make a mess with B, which leads to A.
Example from PC:
H1 H2 H3 mU=1 YES I UNDERSTAND H4 H5 H6 mU=1 NO I DON'T UNDERSTAND H7 A check H3, H6 process [H1;H7] <any order> B1 process [H1] process [H2] check and process[H3] process [H4] process [H5] check and process[H6] DO NOT process [H7] B2 check and process [H1 - H6] in any order DO NOT process [H7]
Gudge: "Order and add unordered" or "unordered and add ordered"
NM: All of this means that either mU is a module or we can change the processing model on the fly.
GD: There are malicious clients. mU is a client thing.
HN: The reason for having mU is that you give both parties a hook. It is a way for the receiver to say "I can't do that" and a way for the sender to say "Don't do that"
UC: ????
NM: THe body is the the syntactical point at which the processor knows there are no more headers and therefor no more mU headers. Stream after body.
DF: We have a unanimous consensus on A. Should we replace the new A with the one bullet in the spec, or wait until Thursday to see where we are on actors? .... We will wait until Thursday. We need a volunteer to see where this fits into the spec.
break
GD: Proposal for what to return in a mU fault.
DF: Is this something we desperately need, or is this just a nice idea.
GD: Just a nice idea - not complex.
DF: I am very wary of "simple" nice ideas. We just spent 6 hours on one issue!
NM: We are deciding on how much to understand in a free-form area. Receivers can send anything they want, what do we dictate?
DD: Can we lift the restriction that the fault header content may not be
used to convey information about header-related faults?
GD: Most everyone
agrees we don't care how they do it, we should just agree on a simple mechanism.
HN: Actor was put in so that errors could be tagged to a certain actor.
NM: What about "next" - does the actor claim to be "next" or some true identity. Are we talking about just mU headers or all headers? The spec doesn't say.
HH: Id's on every header? What about just an XPointer?
PC: To where?
DE: XPath?
GD: I have a concrete proposal. I don't care about how to fix it, I just want to send back info about what was not understood. The info should be a list of the QNames of the elements that were not understood. The proposed mechanism SHOULD (in the formal sense) be the mechanism.
DF: Any problems with this? Should we ask SOAP authors about why they have a
special handling of mU headers? Or perhaps not just mU headers, but all
headers?
HN: We wanted symmetry. If a header comes in and causes a fault, then the fault
goes back out on a header. HTTP bundles too much into error codes. It is a
simple packaging question. If there are 5 faults, then there could be 5
headers come back without stepping on each other.
GD: QNames make unambiguously to extensions, so if there are 3 of them in there, it is sufficient to say I don't understand 1 of them.????
HN: Why did we leave it out? There might be many ways. Why do we pick one now? What about sending WSDL? I am not advocating that.
DF: Take a straw poll. Unanimous consent to do this. Glen to provide the text. Glen to present this tomorrow.
*** Action Item Glen to prepare a proposal for tomorrow.
DF: Time to discuss actors.
M: Gives an introduction to actors. There are some subtleties. What do the following mean: Have a name as an actor? Play the role of an actor? The spin in the spec is that messages move through the world and the places they visit are geographically dispersed. These places are sort of known as actors. A piece of software is an actor. A message path is touched. The notion of an end point is quite well discussed. There is one magical actor called "next". If you do anything, you must do at least "next" If you do anything, you must take it out and then put it back. What if the path is A, B, C and you can play the role of A and B and C. Can you do all at once? One proposed rule is if I take on A, I MUST take on all headers for A.
DF: Do you have a particular proposal in mind?
NM: Some basic principles. Users can do what we spec writers do: We do "next" then they can too. Pick a term "processing point" etc. No processing point must take on a publicly known name. End point will add "anonymous". A second proposal could be: take on "next" and one other. If you are both A and B then you must do all A first and then all B's - do not interleave them. Why? Some feel that intuitively they are different "nodes"
GD: FYI: use "node" to mean "processing point". Comment: First proposal is in line with my understanding.
HN: What about a sender sending to cnn.com and news.com. Can CNN claim to be news.com?? What about "Transaction Manager" vs a specific transaction manager.
Jacek: No matter what the source routing, and no matter what the URI, the assumption is the first hop will return a good result. The first hop can decide to do whatever it wants. If we want to have some client control then add authentication. It is not that big of an issue.
NM: There will be many cases where I want to address actors at the logical layer. It is useful to have actors like next that are functional. For example, a header might be to call a cache manager saying "this is idempotent, OK to cache". Who decides who is a cache manager and who is not. Trust can only be done by with digital signatures. I can assert that I am any actor that I want.
*** Action Item: Noah and team to write a proposal for the group. Try to do it tonight.
Scott Isaacson volunteered to scribe for the first half of the day.
1. Glen Daniels report on mU faults. Should there be one SOAP-ENV:MisunderstoodHeader element? Should there be one SOAP-ENV:Header element with one SOAP-ENV:MisunderstoodHeader child with multiple qname attributes? Should there be one SOAP-ENV:Header element with one SOAP-ENV:MisunderstoodHeader child with a single qname attribute with multiple values? Should there be one SOAP-ENV:Header element with one SOAP-ENV:MisunderstoodHeader child with multiple qname attributes?
"When a processor generates a MustUnderstand fault, it SHOULD provide, in the generated fault message, headers in the following format which detail the qualified names (QNames, per the XML Schema Datatypes specification) of the particular header(s) which were not understood:
<SOAP:ENV:Header>
<SOAP:ENV:MisunderstodHeader qname="ns1:header1"
xmlns:n1="urn:SomeNS"/>
<SOAP:ENV:MisunderstodHeader qname="ns2:header2"
xmlns:n2="http://some.other.com/"/>
</SOAP:ENV:Header>
<SOAP:ENV:Body>
<SOAP:ENV:Fault>
<faultcode>MustUnderstand</faultcode>
</SOAP:ENV:Fault>
</SOAP:ENV:Body>
In other words, a header with the localname "MisunderstoodHeader" in the SOAP-ENV namespace (as defined in sec *.*) ..."
Done wordsmithing, done with the major issues around this proposal, time for Glen to finish the write up and submit to the spec editors.
2. Noah M. Noah distributed a hardcopy of the "Section 2.0 Rewording" proposal. This proposal includes a clarified description of actors and newly (as of yesterday) defined rules for processing mustUnderstand.
The minimal goal of this effort was to define the set of rules for a piece of software (XMLP Processor) to take on roles as actors including (as a liberty) the new rules on mustUnderstand processing rules.
Node is the term for the lump of software that can be next and zero or more other actors. Actor is not a thing or a piece of software, but a role or a responsibility. For example, if " I" am a node and "I" think that I am a CacheManager then I can act in the role of Actor for all messages addressed to CacheManager.
There is a potentially controversial issues with targeting. Actors MAY, but need not, be named with a URI useable to route SOAP messages to an appropriate processing node.
Conform is a new term. mustUnderstand and conform are defined by the module specification, not but the SOAP spec. Modules might say H1 AND H2. If a node gets H1 but not H2, it could be a client fault (application fault) not necessarily a mustUnderstand fault. Issues noted about "fully conform" and "fully implement" - could do more or not?
HN: mustUnderstand and Actor attributes are both sender preferences. In most other protocols, the receiver is the sole authority for deciding who processes what.
Processing of next is interesting since if a Node is more than one actor, we have written the spec in such a way that Node does "next" only once.
NM: Need to look at the term Actor. The Actor attribute is being used to "target" rather than name a header.
MJ: Actor does not feel like it is being used as a routing instruction.
HN: What if a node acts in multiple roles. There is no message path concept in SOAP. It does not say anything about ordering.
DD: It is possible for two actors in the path to take on the the same role and the only way the "second" one gets the headers is if the "first" one reinserted them.
HN: Noah's proposal includes body as header with mustUnderstand=1. Most implementations return serverFault not mUfault if they don't grok the body. Do we want to define a formal, common, way to handle body faults now?
NM: Add "no further processing (break statement)" to first paragraph. For second paragraph, it describes what must be processed, what must not be processed, what may be processed, and how do do that. Any order is across roles, across headers, etc, but with in one message.
PC: From a Quality Assurance point of view, can we describe what SOAP mandates vs what is new?
DE: Is there a difference between mustUnderstand and mustProcess? - no. SOAP uses mustUnderstand and mustProcess.
SI: What about "keep original order"? We can envision an intermediary whose role is to add order or re-order. Yes. Changing might break more things though.
DD: Why don't we just clarifying sentences here and there in the spec? Could be done, take a stab at it. Noah took 2.0, had old and new and finally just rewrote.
NM: Remaining issues
DF: Fasttrack this or discuss more? Unanimous consensus to fasttrack.
break
Issue 19
HN: There is a difference between between "having a prefix" and "being qualified" There are two positions.
For any interesting SOAP message, there is more than one name space.
Gudge: No on understands what an unqualified local names really means. Whether something is locally scoped has nothing to do with whether it is qualified. There is a large number of people that think that the namespace spec does not allow the SOAP style but it does (it just doesn't give examples).
Jacek: SOAP section 5 encoding is broken, but if we do go with it, then unqualified and unprefixed local names are OK.
Gudge: I used to be supportive of SOAP encoding but now I don't care.
PC: Suggest we get Andrew Layman envolved (because he was an author of SOAP and Namespace). Suggest an outreach effort to help determine this issue.
Gudge: The originator has a misunderstanding of namespaces and the schema, but the point still might be valid.
NM: XML Schema's most ugly issue was locally scoped elements. We start with a notion that Namespaces exist because different groups are defining vocabularies. Unprefixed is unrelated to namespace. Consider a book example in which there is the Title of the book and the Title of the author. Should these be namespace qualified? One camp says no they shouldn't. They say attributes are locally scoped and title attributes are locally scoped. The other camp says yes, plus it is visually jarring if not. Get with the program. W3C is going to find their limits by freezing one spec and not opening it to work on the next one.
How do you know something is locally scoped? If you have the schema, then it is easy to figure out. But SOAP goes to great length to say that not having a schema is OK. Chapter 5 provides one standard way of defining data structures that programs typically want to pass around.
**** Action Item Gudge (and Henrik) to clarify intent of issue with the orginal author.
Gudge: In xml-dev someone posted a document saying schemas should be written with everything namespace qualified. Gudge could not find any other example of unqualified local other than in SOAP section 5 encoding rules.
PC: Query will support what Schema does which is both.
Jacek: Schema archive, issue 208. Look in Schema IG archive.
Jacek: Let us make a proposal to use the same encoding in faults, whatever it turns out to be.
PC: We should follow the process, by closing one issue (a namespace issue not a SOAP issue) and opening a SOAP issue and tell him what the proposal is and ask for approval. We are not opening a new issue at the present time.
Gudge: How many have read XML 1.0 Spec (most), how many have read XML Infoset (less). Infoset is a collection of information items and their properties, it avoid angle brackets. It is the model vs the stream. Infoset draws out a root which is not the top of the serialized tree. It moves away from single or double quotes, and away from prefixed vs qualified. The things which we have been discussing would never have come up if we had done infoset rather than schema. Input into schema is an infoset, not an XML 1.0 byte stream. What happens first in terms of "DTD" vs "schema" is not apparent in the infoset.
NM: Furthermore, many docs never appear in the form of angle brackets. DOM form of datase????. It is possible to create an empty DOM and then populate it.
PC: I have a real concern about references to an infoset as if it were real. Infoset is in CR. To get out of CR, implementations will be specs, not software. The infoset is not a tree of properties. It is an abstract tree. Query uses it by defining an algebra that maps from terms to data structures.
HN: Not a good or bad comment. XML 1.0 started with angle brackets, then came Infoset. Interesting is that the abstraction was on an instance, not another abstraction.
Gudge: we have <> into the Node. In the node there is Actor A1 and Actor A2 and Actor A3. If they need to communicate, do they need to serialize into <> or can they communicate using a representation of the Infoset not necessarily <>. What about two nodes on two different hosts with different memory addresses, and what about compressed infoset representations between those nodes?
MJ: Existing practice does this. So surely we don't want to standardize on this? Is this binary XML?
NM: <> is an implementation of the infoset. DOM is an implementation of the infoset. SAX is an implementation of the infoset. Interop is at the infoset level, not the <> level.
HN: SOAP messages will always work.
NM: But it is a binding issue as well. SMTP could say <>. HTTP could say something else.
GD: We should not go crazy coming up with degenerate cases.
DD: Are we saying that we do or do not decide <> for HTTP?
NM: A binding could choose the representation: SMTP + serialized SAX calls for example.
DE: Modulo all the concerns. The spec will be easier to write with Infoset. SOAP would be better. For example, infoset headers are ordered.
MJ: We need to make sure that we carry over everything we have said about <> carries over into the infoset.
NM: Any binding definition that hurts some specific implementation should do so knowingly. You can always get <> out of an Infoset, although there might be an infinite number of documents with varying white space differences.
HN: I did not say this is not a good idea. Just a statement of what we are trying to do. We are just trying to get a broad as set as possible of interop across as many implementations as possible.
Gudge: We will most likely define a binding for HTTP using <>
HN: What about attachments? What is the scope of Infoset?
PC: We should move the Infoset decision to our discussion on scheduling.
DD: Infoset sounds like a cool idea, but what about schedule and interop? It feels like we are greatly increasing the number of options to discuss.
SW: Unless I misunderstand, Infoset it just a descriptive tool. Will it have an external effect?
DF: To summarise: In response to the question "Is this generally a good idea?", the answer seems to be mostly yes, but with some worry about interoperability and schedule impacts.
*** Action Item: Gudge to deliver a small proposal showing what an Infoset representation would look like. It was suggested he re-write one section of the spec in Infoset. By tomorrow.
NM: Dependency in bindings and pluggable bindings. We need to state how binding specifiers specify bindings.????
DF: Is this a must-do item for the spec? Need to get scoped.
DE: We must do it eventually.
HN: We must do bindings. Does Infoset make it easier??
NM: We have been drilling in on binding (ease of definition). Many programs will be generating SOAP messages. Can a SOAP processor have an interface that is a DOM? They want APIs that we don't define but we don't restrict. I will search for raising this to a level 1 requirement from what is already there.
Glen D: Issue of links referencing things that are external to the SOAP envelope.
NM: I can clearly use application style'd links to anything in any way that I want, BUT... this is about what we can rely on SOAP to provide.
Mark Jones: Scenarios where the bulk of the data is generated on route.... With the 1a discussion from yesterday we have moved the 'streaming point (?)' down to the boundary between the header and the body. It seems that trailers are then important for streaming applications.
HFN: In HTTP we have been struggling with trailers for quite some time. The problem is that you want to limit the type of thing that can be put in trailers. We can also look at what implementations do today. We may be able to push this down to the binding - ie. how the binding wraps the message and possibly in-lines the stuff that the message references. What do most applications do?
Glen D: Axis ignores the trailer - i.e. anything after the body.
Noah: We should tighten up the text: Trailers are not like header entries and are not subject to the same processing rules eg. mU does not apply to trailers.
Noah: Good housekeeping implies that you should define what things mean in every place that they can occur.
HFN: There is already text that deals with soap attributes attached to elements that are not the immediate children of headers.
Proposal for handling #25
Trailers are not header entries and are not subject to the processing rules described in Section 2.0.
The presence of a trailer does not trigger any additional application processing, however the information carried in a trailer may be referenced when processing a block in a header/body.
Trailers do not the impact the processing of the SOAP message. Intermediaries MUST NOT remove trailers.
Recommend clarification to section 2 text regarding actors having access to any part of the message including parts of the message after the body.
End of proposal
Noah: I am nervous about creeping complexity. A simpler choice might be just... trailers... we just don't do that. Or we could remove all semantic difference between headers, bodies and trailers... ie they're just block and subject to normal processing.
HFN...
Dug: What happens to references to headers that are removed from a message due to processing.
HFN: We don't guarantee that links point anywhere useful. Broken links can happen.
Glen D: Re multiref data... can I stick those up in the headers.... is it possible for an application to 2 headers plus a multiref....
Noah: If you've understood something and if the understanding is that this element stays around until the last multi-ref processes that's what it means to have understood it.
Glen: So if I move it down into the body it is subject to different mechanisms.
Noah:...
Glen: I think that I would like it if the same thing were true about trailers.
David Ezell: Can we insert trailers at an intermediary?
David F: Can anybody remove a trailer? Are trailers only ever inserted by original sender?. Group responds "No".
Noah: Maybe you want put a trailer in at the third hop to insert a signature.
David F: So are trailers either very simple or they are a complex 'rathole' that will take considerably more effort?
David F: Propose we take a break to do some wordsmithing of prop #25.
David F: We could move onto another issue eg. 22/95 (some assent...) or to go back to discuss the mU dependency issue.
David F: We will return to issue 22/95 after a break.
break
SKW: presents 3 options????
HFN: Let's not even talk about modifying trailers.
Mark Nottingham: Presentation on SOAPAction (SA).
Discussion of Mark's presentation.
HFN: ... a web service is defined by a set of messages it is willing to accept. In HTTP we have content-type and request URI and these two things are orthogonal.
Mark: It nice to say that you're expressing intent
Jacek: Not sure that you captured the issue of maintaining SA across transport boundaries.
Noah: Neither advocate or critic. This is a nice analysis, but has missed a reason that was explained to Noah early on. It is desirable to built high performance servers and to reject unwanted traffic. It is desirable to have lightweight processing of traffic which does not force you to 'crack' open the XML. There is an expectation that there is a trust relationship between the processor acting on the SA hint and the SOAP processor. SOAP action will never force you to process a message s
Noah:.... they are
Dug: I agree with Mark... the SOAPAction as it is today does not allow us to do a consistency check between the message and the SA header.
Jacek: SA should help you filter out messages that you don't want to process. SA does not do this. Messages can be well-meant and correctly addressed, malicious and correctly addressed, well-meant and incorrectly addressed. SA only catches the last case which is not really what you want.
Noah: Re Trust, you should establish a trust relationship between the thing that checks the SOAPAction and the thing that acts on a SOAP message. We are giving you a message, good or bad, that may let you do that...
Randy H: Question of clarification to Dug. If you are going to move this inside of the envelope why
Dug: This something that is verifiable at the SOAP processor.
Randy H: I would rather see this at the very top.
Dug: ... It
Gerd: If SA is a mandatory in the HTTP request binding if you remove it you do break interop with existing SOAP 1.1
John Ibbotson: The choice of use of SA in ebXml was taken as very much a pragmatic short term decision. The expectation is that there is more ebXML specific headers that will be more deeply involved in dispatching the message.
Mark Jones: One can accept the need for processors to able to do early rejection of a message. If this is indeed useful then it is probably a concern for most/all transports in which case it might possibly be good to move this inside the message so it is always available.
Mark Nott: ...for the most part I don't really see the point of SA.
Dieter: Re-iterate that SA removal will cause an interop problem, however, SA is a problem for interoperability today.
Eric J: If SA and Request URI are in conflict, who wins?
HFN: The RequestURI wins every time, no question.
DF: There are a couple of proposals around. There's probably a proposal zero which is no change. Strawpoll on P0; no change, P1 make optional ;P3 just remove it;
Gerd: How about SA= some options...
Mark: How about a strawpoll.
Noah: Have seen this with other groups where you have issues that break interop. On schema, we started a list that stacked up the issues that 'break' interop, with a tentative disposition with a commitment to revisit if interop does indeed get broken.
Paul C: With P1 are you really headed down a path of deprecation.
Marwan: How about just discourage use.
Ugo Corda: Like Proposal 2 (Marks presentation) re bullet 3 requiring use of URI to distinguish services.... require is too strong. (Mark agrees)
HFN: We route messages soley on the basis of URI, that is what we do on the Web. Just because particular implementation allow different dispatch mechanisms
HFN: There was an earlier attempt to clarify SA. SOAP does not say what should happen if SA is empty or absent. This was the intent of earlier postings. Given all this preceding text... no-one has asked why in HTTP and not in anywhere else. We have learned for the evolution of HTTP/HTML that the content-type mechanism does not work. It would be nice to distinguish things without central registries. We looked at this to see how we could fit these things into content-type, but we haven't managed it. I am unhappy with the '+' syntax - it doesn't work for us because we still need central registries.... we can actually get around these things without breaking backward compatibility.
DF: First step P0, do nothing, P1: do something.... to truncate discussion if possible.
RandyH: ... do nothing, but create best practices... (that's P1 do something).
DF: To re-iterate. Proposal 0 (P0) is to do nothing, Proposal 1 (P1) is to do something.
The informal strawpoll result is: Unanimous consent for P1, without objection.
DF: We have the proposals that were stated. We could explore those.
HFN: I like Mark's option 1.
Dug: I think that Mark's prop 1 & 2 have a number of flavours that could be elaborated further.
Marc H: We could take further polls to refine the immediate choices that we have.
DF: In other words, you would like to decide which proposal we use as a base for moving forward.
Anon: There are certain decisions we could make about Port # that might obviate the need for this discussion.
Jacek: Since SA is HTTP only, we might disscuss whether we want to make SA the same for everything.
DF: Interested to explore Mark's suggestion to focus. We might take Noah's tentative disposition, stacked issues
A second informal strawpoll:
P1 = "Mandatory SA", 0 votes
P2 = "Optional SA", 11 votes
P3 = "No SA, and deprecate it, 14 votes
DF: This result is too close to call.
Glen D: This looks like this might be the first point at which we diverge from SOAP.
DF: Need to consider how to move forward... we could assign some folks to work on this and bring forward a proposal tomorrow. Or we could split the group in the morning to develop several proposals.
DF: Tomorrow we will talk about schedule. See slides. There are two schedules to discuss. In the short-term, we need to consider 3 documents. The Requirements document can be left as-is. The Abstarct Model document may need some editing based on changes resulting from this F2F. The Specification document has changed, e.g. revised examples, and may further change as result of this f2f. We can also consider omitting the issues list snapshot, and we need to consider the namespace issue, protocol name issue.
Stuart Williams scribes
WG split into three smaller groups to generate SA proposals. WG re-convened and merged these various proposals into four seperate ones, ABCD.
Informal strawpoll results on numbers of people in favour of each proposal:
Proposal A, 4 votes
Proposal B, 0 votes
Proposal C, 0 votes
Proposal D, 22 votes
PC: Want to have an explicit vote on what this group doing wrt SOAP 1.1
HFN: yesterday we did not have the discussion yesterday over the effect of the resolutions
Mark H:
Dug:
HFN: If you read the statements in the spec. you would reach the same conclusion
HFN: You are now saying that valid SOAP implementations are broken
Mark Nott: ..quotes from charter viz relationship of SOAP to activity.
Ugo: Regarding breaking implementation... current implementations apply different semantics wrt SA.
HFN: Saying that something is not specified....
Glen
Noah: Wanted to respond to the point on being compatible with SOAP 1.1. I wanted to suggest again something that I suggested yesterday... Some of these changes are kind of binary and once you break one of these things then the bar to other minor changes falls. We could keep a list of the modest changes that we might want to make pending some more major change. I would like to line up the things that break compatibility based on their merits.
PC: I wanted to respond to Mark's reading of the charter. I would argue that this is not an improvement.
Noah: Paul what you are saying is coherent, but it is mixing in a personal value judgement.
Randy: I think that taking SA away is not an improvement. I am not comfortable with taking this away without providing something that gives back the functionality.
Glen: Unless we can get to some discussion of what information has to be passed into a binding...
RandyH:
Dug: I believe that proposal D leaves open the possibility to have the discussion.
Glen D: ...but the problem is that it implies
Noah: re-quotes the charter... reference to evaluation of solutions proposed with respect to SOAP.
HFN: Leaving the charter aside I would like to agree with Glen in that we should have a better notion of what bindings are and what we are going to use them for. If you come out to the community and say one month that x is bad and then next month say that x is good... that would be bad.
Hugo: I think that we are publishing WDs and we are asking the public for feedback. What we are putting out is not a REC.
DF: Rightly or wrongly, the public puts significant weight behind a WD.
PC: Would generally agree except wrt to the way that the charter for this group is very different.
Mark N: So we think that we need to look some more at trasnport bindings as an iterim we could put wording in our draft making SA optional.
DF: We could do a number of things including Noah's suggestion.
Mark Jones: Could we signal areas of work to be done in our specification.
DF: I think that this comes down to the judgement of whether this is in fact an improvement. Folks have read the same piece of text in the SOAP 1.1 spec and come to different conclusions. I think that we do need to figure out some way of determining whether a change such as this is for the better or worse involving a larger community.
Noah: I think that you're right. I would like to get some sense of the degree of improvement. I think this is better, but not hugely better.
Dug: If we are going to do this for this issue shouldn't we do this wrt to a bunch of other issues.
DF: What I'm trying to formulate is how we could seed discussion of these matters in the WD that we would expect to put out the next month or so.
Noah: So discussion of this on dist-app
DF: Yes
PC: Instuctions to editors say that the doc status should not be boiler-plate text and should include detailed statements of changes and issues and requests for priority feedback.
DF: Suggest changing the spec as Proposal D and mark it out in the document status exactly as Paul suggests.
Noah: If we go down the path that Paul suggests then the list should signal changes of clarification (ie. not intended change to meaning) and those that are changes intended to resolve particular issues.
Eric:
DF: Recall on Schema that we signalled in the text request for priority feedback.
DF: So do we agree on unanimous consent to D... Actually, I want to expand question to ask is there consent to publishing a WD including proposal D and a request for priority feedback.
PC: Microsoft would likely file a minority opinion if the WG published such a WD.
Randy H: So would we (Intel).
DF: Another option is to leave spec as is, but to include an option in the document and seek feedback.
Glen: I was wondering if there is a way of having a more widely scoped discussion
DF:
Noah: WD should indeed be pretty close to what we expect the spec to be. I have no objection to a wider discussion but probably not in the document.
PC: Suggest we include the extremes of A and D in the document and seek feedback on both. Personally, I wouldn't even wait for publication of the WD. Would take it to dist-app.
Yves: There is something common to A and D, which is that SA is deprecated. We could note the commonality and ask for feedback on the difference.
Dug: I don't disagree with any of the process proposal, but I am concerned that we might just be delaying a decision.
DF: I think that this group is bigger than just the folks in this room. We have been asked to act publically as part of a larger community and we should engage that larger community.
Dug: But this has been the subject of much discussion in the larger community.
Frank: Seconded
DF: But has this specific proposal been discussed in the larger community?
Gudge: Nobody out there believes that they have the power to make a proposal.
DF: I was responding to Dug's question of whether we expect anything from the wider community that will change our mind.
Mark N: Concern about references/linkages to service description languages.
Glen:....
Frank: There are WG members who are not here whose vote's might change the numbers
PC: So... do you think we have concensus?
DF: ... as you remind us... we don't need concensus on content to publish. We can make the choice here that we would make this change and publish the document. We have had indications that at least two of our members would formally object. I have been exploring options that attempt to yield more concensus. Feedback from dist-app would be useful and may yield more concensus.
DF: Propose a break (35 min over due) and return with a number of proposals.
After the morning break:
DF: Proposal on how to proceed on the next step. Suggest the following:
Start conversation by going to the larger community (dist-app, soap-builder,
soap-dev, ebXML, etc). We present our
two proposals and invite priority feedback. There is a 10 day cut-off and we
have the option to roll any feedback into the next publication.
Could include Noah 1a text for consultation.
Dug: Might need to work on the wording of the A/D proposals before we send them out. Folks out there are missing the context of the discussions that led to the proposals.
DF: So, how ambiguous is the wording for proposals A and D.
Frank: Not all...
Dug: I find D ambigous because it says it doesn't indicate that SA could come-back in another guise within the SOAP envelope.
DF: For the most part I think that we need go with the wording we have.
Frank: I think we need to add Noah's clarification to A.
Wordsmithing discussion, partly hinging on the definition of deprication.
PC: quotes definition of deprecation from SGML.
HFN: IETF defines deprecation in terms of longevity
Mark Not:????
Noah: Suggest we bring both proposals together around "discouraged" rather
than "deprecated".
Dug: I think Paul is right, changing "deprecated" to "discouraged" loses the
commonality between A/B
Frank: I'd come down toward "discourage" rather than "deprecate".
Jacek: I have felt that the difference between A/D is in deprecation and
discourage.
RandyW: Indicates that all receivers MUST not accept/reject on basis of
SA
Yves:
DF: Do the re-worded proposals A and D work for people?
Dug: I have changes for D too about not precluding future change.
DF: Proposal is that missive will contain re-worded A and D along with preamble.
General consent to construct email.
DF: Looking for volunteers to wrap proposals into an email and be responsible for sending out and handling responses. Suggest Deadline for Monday 18th June.
Chair conducted an informal straw pol to determine whether the reworded
versions of A and D had significantly chnaged the vote count.
One addition to A and one move from D to A. [A(6), D(21)]
DF: Clarification, send the email to IETF, ebXML, SOAP-Builders, SOAP-Dev, xml-dist-app.
Action: Mark Nottingham and Martin Gudgin to create and send message.
DF: We are now seriously behind time! Want to dive directly into a discussion of the schedule (long term and short term), see slides. The larger schedule is the one leading to PR and REC. We need to be sensitive to what we can realistically achieve in our schedule. The short term schedule is motivated by the immediate need to meet our 'heartbeat'. There are issues in the short term around what exactly do we publish, and I have some proposals around that. Ww will postpone the Usage Scenario discussion and discussion of the other issues on the agenda.
DF: We have three documents: Reguirements, Abstarct Model, and Draft Spec. We need
another heartbeat document for 19th June. The requirements document can stand
as is. There have been some small changes, but that is a secondary issue. Our
other two documents are currently listed as editors drafts.
Let's talk about the AM first. We did prepare a version of the document for
publication a number of weeks ago and stalled on the publication process. Want
to revisit whether the current version of the AM document is something we want to
publish 'as-is', or whether it should be modified .
Stuart/Mark: there are a number of possible minor changes to the AM document.
Noah: Questions the implication associated with publication of a WD on the intention to move the WD toward a REC.
PC: Any WD publication MUST indicate whether the WD is on a RECOMMENDATION track or not.
Hugo: Note that the requirements document makes no such statement.
PC: It is implicit that a requirements document is never on a RECOMMENDATION track.
Noah: Words to effect that "The WG has developed the AM in the hope that it will help us do a better job of designing the protocol and perhaps eventually to serve as a framework for describing the protocol. The WG has not yet decided whether this document will be part of the XMLP Recommendation.
DF: Chair judges unanimous concensus to include wording expressing the sentiment of Noah's words in the Abstract Model Document Status.
DF: Note that the publication of both documents is assumed to be 'ganged' (as agreed previously). We now move discussion to the Spec document.
Dug: Propose to remove elements that transferred from AM document into the XMLP/SOAP spec.
HFN: Clarification... do you propose to remove the whole section or just the diagram.
Dug: Whole section...
MarcH: The task given to editors was to apply the Glossary wording to the whole spec. We have had WG concensus to do that and to bring the two documents into sync.
HFN: A proposal: it might be more appropriate to move the diagram to an appendix.
DF: Part of the motivation for putting diagram and terminology into the spec were that folks felt that the diagram in particular provided enormous clarification, and that we wanted the AM document and the spec to be cut from the same cloth.
Dug: Remain concerned that the AM implies a particular implementation.
Noah: I share some of Dug's concerns. If we want to keep the diagram we need to keep the things that have counterparts with the SOAP spec.????
Mark Jones: Many of these terms have have come from outside the AM group and pre-existed..
Noah: It may be that if we consider all the terms, some may not make the cut.... (for the spec).
Marc Hadley: We need to be sensitive to the inter-relationship between terms.
DF: Would like to take this up a level and ask those with particular concerns to make specific proposals for changes.
Noah: My suggestion was that the editors draft of the SOAP/XMLP specification adopt the new terminology in those cases where there are direct counterparts or equivalent terms. I would suggest moving some of the more 'questionable' things such as the diagram to an appendix.
Jean-Jacques: Would like to remind people that the Abstract Model document has been available for several weeks and we have yet to receive any comments.
DF: I would like to see particular proposals for changes. Does the group have a sense of what is likely to be proposed, and does it want to invite someone to make a more particular proposal?
Glen D: Whilst I have some concerns that the AM may seem prescriptive of implementation there are many useful concepts introduced in the AM that we do need.
DF: I think this needs better formulation as a concern. Suggest you (Dug) prepare a succinct statement of concern with some examples.
Action: Dug to develop a succinct statement of concern on AM material in XMLP/SOAP spec with some examples.
DF: Note that there are a number of changes to the editors copy: mU processing text; Revised examples; Schema; Issue list (to be omitted?); Namespace xmlsoap.org/w3.org; Name currently XMLP/SOAP. On issues list snapshot, it is radically out of date now, suggest that we remove it. Retain a reference to issue list.
PC: Strongly suggest retention of an updated issues list snapshot.
Hugo: Publication of a WD is like a snapshot of our work.
HFN: With HTTP-WG we did have a separate issue-list, it worked fine.
PC: If it gets the WD out faster then drop it.
DF: Some folks found the list an impediment to getting to the document.
PC: The issues list should have forward references to issues.
HFN: Our issues list is not in that state. It is not overly specific.
DF: Inclusion of the issues list, and in what form will be at the discretion of the Chair and the editors. [No objection raised.]
Lunch
Document publication, continued...
XMLP/SOAP specification, issue 4 (namespace, xmlsoap.org/w3.org)
Paul Cotton makes a proposal. Notes the following:
Noah -- clarification. suggest a note to current soap users that if they want to change something they use the new namespace. This is not soap1.1 compatible.
David Fallside -- Asks for clarification of SOAP version being proposed.
Paul Cotton -- SOAP1.2 (namespace is changing, so it's ok, 2.0 is too much).
Noah -- Need a note that we reserve the right to change to 2.0 if changes prove more radical.
Glen -- are there issues with the name?
Paul Cotton -- not that we know of.
Yves -- there may be an issue with some other company using the name.
David Fallside -- (aside) AC members in the WG need to know about PAG.
Mark H -- will soap fault return this error?
Henrik -- yes, in cases of a version mismatch.
Paul Cotton -- strength is the feature in MS work product will make moving forward more graceful.
Hugo -- how is this related to issue 14 or 66?
Gudge -- not sure about client versioning problems... issue was only about dealing with issues.
Paul Cotton -- may settle 66, probably not 14 (too vague).
Brian -- changes to abstract model???
Paul Cotton -- clarify that use of "XMLP/SOAP" wil be discontinued.
Noah -- "Service Oriented Access Protocol" might be a better name.
David Fallside -- on Paul's assertion that the "SOAP" name is a good thing for W3C. The name is is also associated with MSFT.
Stuart -- Refering to an earlier discussion between Paul and Mark Nottingham about the charter relationship between SOAP1.1 and XMLP and the risk of descisions that should be being made explicitly being made implicitly through a number of small changes (eg. proposal to remove SA), Stuart asked Paul whether he would interpret the WG choosing SOAP as the name of its protocol in a way that implicitly restricted the WGs ability to innovate solutions.
Paul Cotton -- because we go with SOAP1.2, we minimize pain to the community.
Glen -- we must reserve the right to make changes. Has concern that we bar certain types of changes in adopting the name change.
Paul Cotton -- MSFT would never have submitted soap to W3C if such changes were not to be allowed.
Noah -- focus on what we know about right now. The WG is just now turning the corner of expertise. We don't want to close off the option of changing away from SOAP name later. We must reserve the right to change. Essential that these reservations be minuted.
David Fallside -- (aside) the WG has been very restrained in its decisions that may affect to SOAP. There have been no gratuitous decisions.
Glen -- some issues need to be moved more to the fore. Early discussion will likely improve the design.
DF: informal strawpoll of WG on whether or not to accept Paul's proposal
Unanimous result from strawpoll in favour of adopting Paul's proposal, but acknowledging Noah's caveat.
David Fallside -- defer discussion of meaning of the name. Need to first decide how the fault is returned. Discussion follows.
Henrik -- presentation of envelope versioning model and of the SOAP versioning transition proposal. Model in 4.1.2 says we don't care about versioning. But version.mismatch is returned if the wrong namespace (for the envelope) is used. Suggest sending back the namespace that the receiver *does* understand. Recommend sending back multiple namespaces.
Glen -- how do you send a fault in a namespace you "don't understand"?
Noah -- thinks we need an appendix. Soap1.1 processors won't understand
the new versioning mechanism.
However, people wishing to make minimal changes to 1.1 processors MAY respond
with a response per the new spec (with the convention for expressing the
namespace).
Henrik -- says that SOAP1.1 implementations can't be changed, but will return a simple version.mismatch.
Noah -- what is the soap1.2 namespace?
Henrik -- .../soap1_2/envelope (or some such)
Gudge -- clarification. we have already soap1.1. Pubish spec in new namespace with new stuff.
Glen -- I'm a soap1.1 processor. If I don't recognize the namespace, I'll return this error. Conversely, newer processors, SHOULD understand all versions of soap, and return an error in the sender's namespace.
Dug -- namespace should ALWAYS be the 1.1 namespace. (Lots of others agree).
Frank -- clarification.
Noah -- make a suggestion in an appendix (takes pressure off). Defer rest of decision to an issue on the issues list.
Paul Cotton -- such an appendix should point to issues 14 and 66.
David Fallside -- should we change the definition of the SOAP name?
Informal strawpoll of those in favour of various suggested names:
No member said "can't live with" PC's proposal to provide no definition of the name. The WG adopted "no definition SOAP" without dissent.
David Fallside -- we need to confirm that the proposal has no effect on the Abstract Model before we name it SOAP.
Henrik -- we're not sure the abstract model really models soap; need to keep the name separate.
Paul Cotton -- take the SOAP modeling section of the AM and say that it will be done, and that section point to SOAP 1.2.
Working group decides unanimously to adopt PaulC's proposal as ammended (see above).
Noah -- booleans are now "true" and "false". Needs to be discussed, will bring it up in email.
David Fallside -- proposed schedule. See charts.
Editors response
Editors agree to have a document containing all agreed upon changes (to date) by close of business 15 June, 2001.
WG agrees to review the document in time for the 20 June 2001 telcon, and be prepared to comment on the document at the telcon on that date.
Noah -- should his 2 page note on revising section 2 be posted?
BreakDiscussion of longer term schedule.
Chair's list, see slides.
David Fallside -- are there other issues?
Paul Cotton -- what about testing? Can we meet criteria for PR? Maybe not us, but we need to keep an eye on it.
David Fallside -- perhaps this has been covered by the WG members who were working on conformance?
Hugo -- no next steps defined yet.
Action: to Hugo, start thinking about how to record conformance.
David Fallside -- (see proposed schedule for details)... goal is to make Rec by end of 2001.
David Fallside -- this is an aggressive schedule and there are various ways we can think about speeding up our work. For example, we could have two telcons per week, and/or additional face-to- face meetings.
David Fallside -- should we have a Primer?
David Fallside -- Also consider task forces for encoding, rpc, etc.
Paul Cotton -- f2f requires 8 weeks notice (and approval) from entire WG.
Suggestion -- task force f2f instead of full f2f.
Yves -- even small meetings need 8 weeks notice.
Chuck -- need to have enough time to process comments
Paul Cotton -- biggest problem is getting back confirmation from the commenter.
Paul Cotton -- if we skip CR, need to make sure the public knows that ahead of time.
Paul Cotton -- last call seems too close to PR in the schedule.
Paul Cotton -- do we need to fix the charter to accomadate the schedule?
David Fallside -- our charter is until April 2002, so we are OK.
Henrik -- this working group is different, in that our work is continually visible to all implementers. Is CR relevant?
Chuck -- we should put out the Primer before last call.
Chuck -- would be interested in doing the Primer.
Chair notes that the WG generally thinks that a Primer is desirable.
David Fallside -- Two points in summary of discussion: 1) there are lots of things we need to make known up front and 2) lots of new territory in process. DF commits to coming back with recommendations on how to make it work.
David Fallside -- responding to a question about the September f2f. No information yet on the f2f except that it is being held in San Jose, California in September, and the local organiser is Scott Isaacson (Novell).
Meeting closes at 5:10PM, with thanks to Canon for a wonderful meeting.