See also: IRC log
Agenda item 6 may have to wait until the F2F when all interested parties are present
<cferris> here was my reply to daveo's blog post: http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
<cferris> oops, wrong URI: http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=440&entry=107924
zakim access will be provided for Sat F2F
Sat agenda will include details
15 Feb approved
2006/02/01: Herve - done
2006/02/01: Noah - done
noah: email sent but includes mention of pasting document at URI
noah need to discuss at F2F if/who will write the doc and post it
noah: thinks the right thing to
do is draft a short document with an anchor for the class of MEPs
and some descriptive text
... if later this turns out not to be the right thing to do we can
pul the docuemnt or post an alternate representation
<scribe> ACTION: Noah to draft suitable document [recorded in http://www.w3.org/2006/02/22-xmlprotocol-minutes.html#action01]
noah: inferred doc is for class of all possible MEPs
daveH: point out that there are currently two instances of this class
ACTION 1=Noah to draft suitabl document for class of URI description
ACTION 1=Noah to draft suitabl document for class of MEP description
edcopy chnages and email sent
<Yves> http://lists.w3.org/Archives/Public/xmlp-comments/2006Feb/0001.html
above URI points to email from Noah describing some problems with current fault generation description
below are alternative proposals from that email
<noah> SOAP Rec says today: ""Failure is indicated by the generation of a fault (see 5.4 SOAP Fault).
<noah> SOAP message processing MAY result in the generation of at most one fault
<noah> Alternative #1: Failure is indicated by the generation of a fault (see 5.4 SOAP Fault);
<noah> SOAP message processing MUST result in the generation of at most one fault
<noah> for each message processed."
<noah> Alternative #2:"Failure is indicated by the generation of a fault (see 5.4 SOAP Fault).
<noah> SOAP message processing MAY result in the generation a SOAP fault; more
<noah> than one SOAP fault MUST NOT be generated when processing a SOAP message."
<dhull> so, what's the usual way to say "[0 .. 1]". Can we just say that somehow?
marc: likes option 2
yves thinks it is a good clarrification
dave prefers option 1
daveH is ok with either
chris: prefers the second since it is easier to see that there's been a change
chris is also ok with either
mike: any pushback to option 2 ?
option 2 accepted
<scribe> ACTION: chris to send closing email re fault generation fix [recorded in http://www.w3.org/2006/02/22-xmlprotocol-minutes.html#action02]
<Yves> http://lists.w3.org/Archives/Public/xmlp-comments/2006Feb/0001.html
<anish> has this been recorded as an issue in the errata?
ACTION 2=chris to send closing email re fault generation fix and cc Henrik
<scribe> ACTION: Yves to create rec issue for fault generation text [recorded in http://www.w3.org/2006/02/22-xmlprotocol-minutes.html#action03]
<mikem> http://lists.w3.org/Archives/Public/xml-dist-app/2006Feb/0022.html
daveH presents his strongly vs weakly typed MEPs analysis as captured in email archived at the URI above
<noah> I think Dave Hulls 2006/Feb0022.html message captures the state of play very nicely.
<noah> In particular, I think the crucial observation is that in the case of "strongly typed" MEPs, the application decides whether to wait "keying off of
<noah> "supports f-a-f MEP" or "supports r-o-r MEP","
<anish> daveh, in your email you talk about f-a-f MEP and one-way MEP: could u talk about the different between the two?
<anish> at the MEP level, that is
noah 1) I think that with either strongly or weakly typed MEPs, implementors can and probably will create APIs that model the WSDL level APIs. So, one API for In/Out, another for In-only.
noah: 2) In the strongly typed case, I speculate that implementors will also build APIs that model the SOAP MEPs. So, and API that lets you transparently run any request/response binding, and another that lets you transparently run any faf.
noah: 3) The question is how the implementations of those APIs find out what to do at a low level: the strongly typed approach insulates the implementations of the WSDL APIs from detailed knowledge of each SOAP binding. The WSDL level API will be built in terms of the SOAP level MEPs.
noah: 4) In the case of weakly typed MEPs, then we are in some sense declining to standardize the means by which the WSDL-level APIs would get binding independence. Maybe or maybe not particular implementations would find ways to factor their code.
chris: head hurting, one of the
original principles for SOAP spec was not to get into
implementation or API design
... argues that many different implementations are possible and
that it would be a mistake for us to over-analyze this.
dave: if implementing WS would use both request-response and fire-and-forget happily
dave thinks if this isn't defined by us then implementors would have to invent it
<anish> +1 to that -- we don't need to analyze this to death, especially the APIs -- there are several ways to do the APIs
[Chair note: there seems to be a hole in the minutes here]
<dhull> +1 to noah
<dhull> (re: consistent semantics)
anish: what the difference is between f-a-f MEP and one-way MEP (from the POV of how the MEP is defined)
marc comments: WG should steer clear of API abstraction design, that stuff happens elsewehre, this WG needs to concentrate on protocols
<cferris> +1 to Marc's comments [Chair note: I moved this here though Chris may have been +1ing something else Marc said not captured]
daveH: f-a-f and one-way are used interchangeably
<dhull> (by me))
noah: thinks that abstractions we define are of most use to protocol binding designers and they allow bindings to exhibit similar capabilities that can promote generic APIs
dave: commonality between
protocol bindings is straightforward and worth modelling/defining
to promote a generic abstraction
... really wants to abstract away from HTTP
meeting adjourned
[NEW]
ACTION: chris to send closing email re fault
generation fix [recorded in http://www.w3.org/2006/02/22-xmlprotocol-minutes.html#action02]
[NEW] ACTION: Noah to draft
suitable document [recorded in http://www.w3.org/2006/02/22-xmlprotocol-minutes.html#action01]
[NEW] ACTION: Yves to create rec
issue for fault generation text [recorded in http://www.w3.org/2006/02/22-xmlprotocol-minutes.html#action03]
[End of minutes]