See also: IRC log
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html
"This format serializes the instance data in the HTTP message body, making it only suitable for HTTP requests using methods allowing message bodies."
"This format serializes the instance data in the HTTP message body, making it only suitable for HTTP requests using methods allowing message bodies."
"In this serialization, for HTTP requests, the rules for constructing the HTTP request IRI defined in 6.7.1 Serialization of the instance data in parts of the HTTP request IRI apply if the {style} property of the Interface Operation bound has a value of "http://www.w3.org/@@@@/@@/wsdl/style/iri" as defined in 4.2 IRI Style."
<Jonathan> http://lists.w3.org/Archives/Public/www-ws-desc/2007Jan/0058.html
<monica> will only be able to join today via irc - conflicts
<scribe> Scribe: plh
Minutes approved
Review of Action items [.1].
[Interop]
? 2006-11-30: [interop] John Kaputin to create a test case
with "required=false".
? 2006-12-14: [interop] Jonathan to fix transferCodings -
add control group
[WG]
? 2006-09-21: Jonathan to check periodically that SPARQL has
added schemaLocation.
? 2006-12-14: plh to come up with a more detailed proposal for
CR112 if possible
? 2007-01-04: Jonathan to make sure parameters are added to the
URI in the HTTP binding even when no whttp:location
appears.
? 2007-01-04: Paul to report back on which test cases in the
WSDL test suite fail the basic patterns, with
suggestions on how to address the issues.
DONE [.3] 2007-01-04: Charlton to come up with a list of editorial
comments and WSDL substantive issues.
? 2007-01-04: Jonathan to analyze CR117 further.
Current Editorial Action Items
Note: Editorial AIs associated with LC issues recorded at [.2].
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/5/cr-issues/actions_owner.html
<scribe> [DONE] 2007-01-04: Charlton to come up with a list of editorial comments and WSDL substantive issues.
<Jonathan> http://lists.w3.org/Archives/Public/www-ws-desc/2007Jan/0071.html
Jonathan: let's skip the
editorial issues
... let's look at number 11, policy intersection
Charlton: this is relevant to the
client, not strictly relevant to WSDL. Don't see anything to
select the intersection mode selection.
... if one entity understands one mode and an other is being
required by the other entity, the intersection won't occur.
Jonathan: so, if I would attach a policy to WSDL, should we have a mode as well?
Charlton: if you want someone to
always apply lax, there is no mechanism for that for the
moment.
... there should be a mechanism for expressing this.
Philippe: this is up to the client to use one or the other intersection mode
Asir: it's at the discretion of the requester. I don't see this as a WSDL issue
Charlton: not trying to express that anyone other than the client can pick the mode, but the service might want to indicate which one to pick.
Jonathan: be isn't ignorable the mode?
Philippe: if you don't want the client to ignore your assertions, then don't use ignorable.
Jonathan: we would need a more developed use case to see the interop problem, but this seems a policy issue
Monica: some parts of the discussion will be handled in other documents in WS-Policy. Maybe that will help Charlton on this issue.
Charlton: I'm happy not including
this in the WSDL comments.
... Number 12 is already filed as an issue in WS-Policy but
we're expressing interest in it.
... the issue is about how to map parameters in policy
attachments to WSDL 2.0.
Asir: is this a Last Call issue or an issue about the WSDL 1.1 Element identifiers?
Charlton: this is a last call issue?
s/\?//
scribe: it's a fragid issue.
Jonathan: I suggest we include it
in the mail, as a side remark.
... I'll file the issues on behalf of the WSDL WG.
... all editorials. not 11.
... I'll leave the observations in this WG.
<scribe> ACTION: Jonathan to send WS-Policy comments to the WS-Policy WG [recorded in http://www.w3.org/2007/01/11-ws-desc-minutes.html#action01]
<scribe> Postponed
<Jonathan> http://www.w3.org/Submission/2006/SUBM-WS-MTOMPolicy-20061101/
Jonathan: W3C ack'd a submission on the MTOM policy assertion
Philippe: will be sent to XMLP. I
*think* they want to work on this on the REC track.
... the XMLP WG will need a new charter if they do so.
Jonathan: following-up on this, I thought Canon was going to investigate the use of the MTOM policy assertion. Any news?
Jean-Jacques: no news yet.
Jonathan: the interesting point is if it is difficult to implement a WS-Policy that can only support one policy assertion.
Jean-Jacques: if we parse it, and check if the infoset only contains a subset, would that work?
Jonathan: you also want to
support the PolicyReference element, which is the
practice
... you also want to reject policy you don't understand.
Jean-Jacques: a bit more complex than XPath...
Jonathan: I also don't understand
the resources constraint you're facing
... could one use XSLT to transform the policy into a direct
WSDL extension?
... if that's true, the information content is equivalent
... Paul's proposal was to annotate the policies. Asir's
proposal was that we don't need to annotate them at
all.
<scribe> ACTION: Jean-Jacques to provide more analysis on how difficult it would be deal with a Policy that only contains an MTOM policy assertion [recorded in http://www.w3.org/2007/01/11-ws-desc-minutes.html#action02]
http://www.w3.org/2002/ws/desc/5/cr-issues/#CR122
John: 6.7.2.2.2 talks about ignoreUncited. If the HTTP PUT or POST then the remainder gets serialized in the message body anyway, not repeated in the URI. So the use of the property isn't relevant here.
Jonathan: should we clarify that
data could be thrown away?
... you're not only preventing the data from appearing in the
URI, but you can also prevent it from appearing in the HTTP
Body
... Youenn got the correct behavior
... I do believe it would be possible to write some WSDL that
wouldn't interop because of implementation limitations.
... yes, it is the expected behavior. The user might trip on
this. Closed with no action.
Resolution: close with no action
http://www.w3.org/2002/ws/desc/5/cr-issues/#CR130
<monica> nick /monica
John: I had to make some decision
on how to associate the tokens I find with the string
... should the spec be more specific?
<jkaputin> whttp:location="{{{town}}}"
<jkaputin> {{,{town},}}
<jkaputin> {{,{,town,}},}
John: two ways to interpret the example.
<Roberto> I'd say it's '{' + value of town + '}'
+1
John: with a strategy that looks for matching par curly braces first, the example will be ok.
Jonathan: the proposal is to match the pair of curly braces first.
Tony: I can't see a grammar where the second result would be correct
Jonathan: is there a common algorithm we can point to?
John: don't know any
Philippe: don't try using regular expression to handle http:location, you need a parser and a state table
{{town}}
<scribe> ACTION: Philippe to propose a grammar for http:location [recorded in http://www.w3.org/2007/01/11-ws-desc-minutes.html#action03]
http://www.w3.org/2002/ws/desc/5/cr-issues/#CR131
John: should we deal with infault elements as well?
Jonathan: the binding only works
for the 3 MEPs
... you can say that it applies to the infault in your
extension as well.
Resolution: the HTTP 1.1 Binding aplies only to the 3 MEPs we have in the spec. Closed with no action
http://www.w3.org/2002/ws/desc/5/cr-issues/#CR133
Jonathan: For the SOAP response
MEP the immediate destination is "the value of the WSDL
{address} property, modified by the {http location} property
following the rules described in section 6.7.2 Serialization as
application/x-www-form-urlencoded."
... is it intentional that we are ignoring http:location?
"the SOAP request-response MEP the immediate destination is "the value of the WSDL {address} property of the Endpoint component."" . is it intentional that we are ignoring http:location?
John: so instance data would be serialized in the IRI
Jonathan: yes, but the full XML would still be part of the SOAP Body
John: might be useful in
gateway/middleware scenarios
... so you don't have to parse the message body but still want
to do dispatch
Jonathan: didn't see any reason to have it the way it is.
Proposal: the SOAP request-response MEP immediate destination is the value of the
WSDL {address} property, modified by the {http location} property following the
rules described in section 6.7.2 Serialization as application/x-www-form-urlencoded. The entire instance data is serialized in the SOAP Body.
Resolution: proposal adopted.
John: What happens if the MEP
allows multiple input messages or infaults as well as input
messages?
... there is an issue on how to associate the element name with
the input data.
Jonathan: we only define the property for the 3 MEPs.
Resolution: closed.
http://www.w3.org/2002/ws/desc/5/cr-issues/#CR141
Jonathan: this is a duplicate of 130 since Philippe will come up with a grammar.
Resolution: will be resolved with the resolution of 130. Closed (duplicate).
wsdl: binding/wsdl:operation/@whttp:queryParameterSeparator is missing in
the HTTP binding syntax summary while present in section 6.4.4.
Resolution: agreed. needs to be fixed.
Jonathan: It does make sense to
add #none
... the SOAP Response MEP can only be used with the IRI style
or with an input message of #none.
... sounds reasonable.
Resolution: agreed. Needs to be fixed.
Support for deprecation.
Resolution: could be done through extensibility or in V.Next. Closed.