W3C

Web Services Description
29 Jun 2006

Agenda

See also: IRC log

Attendees

Present
Charlton Baretto, Adobe Systems
Allen Brookes, Rogue Wave Software
Roberto Chinnici, Sun Microsystems
Paul Downey, British Telecommunications
Jacek Kopecky, DERI Innsbruck at the Leopold-Franzens-Universit├Ąt Innsbruck, Austria
Amelia Lewis, TIBCO
Philippe Le Hegaret, W3C
Jean-Jacques Moreau, Canon
Gilbert Pilz, BEA Systems
Tony Rogers, Co-chair/Computer Associates
Regrets
Glen Daniels, Sonic Software
Youenn Fablet, Canon
Tom Jordahl, Macromedia
Bozhong Lin, IONA Technologies
Jonathan Marsh, Co-chair/Microsoft
Vivek Pandey, Sun Microsystems
Arthur Ryman, IBM
Chair
Tony
Scribe
Charlton

Contents


Approval of minutes

June 15th minutes approved

Review of action items

AIs for interop skipped

Paul's AI: In progress

Jonathan's AI: Per Jacek, in progress

Glen's AI: Not present at telecon

Charlton's AI: Marked completed based on this morning's update

Gil's AI: In progress

Jonathan's AI: Not present at telcon

Arthur's AIs: Not present at telcon

Administrivia

Looks like we'll have a telcon next week.

SPARQL wsdl bug - In progress

CR022

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR022

http://lists.w3.org/Archives/Public/www-ws-desc/2006May/0101.html

http://lists.w3.org/Archives/Public/www-ws-desc/2006May/0128.html

http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0034.html

Postpone issue since we don't have Arthur or Jonathan today

CR037

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR037

Postpone issue since we don't have Arthur

CR044

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR044

http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0057.html

http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0073.html

Charlton: I suggested some language on the last call to make Section 6.3.1 read more smoothly.

Tony: Since we declined CR044, we will include this resolution as a suggestion for language to clarify the rationale for default properties in support of interface-less bindings

Jacek: We need to correct the language suggested for section 6.8 as per http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0026.html

ACTION: Charlton to update his proposal for CR044 based on the language correction suggested by Jacek per http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0026.html [recorded in http://www.w3.org/2006/06/29-ws-desc-minutes.html#action04]

CR045

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR045

Unfortunately Paul just dropped off the telcon, so we'll postpone discussion of this issue

CR052

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR052

Serializing only part of the body with HTTP binding

(non-sequitur to CR044 - no objections to accepting the proposal; will forward it to the editors as described)

CR052 wants to speak toward updating the state through an append

Roberto: Not a trivial change

Jacek: Not serializing the location as part of the payload

Philippe: This is a new use case. A bit late in the cycle to include it

Tony: Input for the next revision

Jacek: Or toward producing a new extension

Tony: e.g. HTTP 2.0 binding. Difficult to handle a new use case at this time, agreed. We'll need to respond likewise.

Jacek volunteers to address this.

ACTION: Jacek to draft a response to Eric re: CR052 explaining that this represents a new use case, and that we will not be able to address this as such in the spec, but that it can be addressed as an additional extension... [recorded in http://www.w3.org/2006/06/29-ws-desc-minutes.html#action01]

CR053

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR053

Allow absolute URI in {location}

Jacek: I don't think it is possible to craft the URI inclusive of extended variables
... I think what he wants is that the location be considered for combination with the base IRI

Philippe: Don't see anything that makes that impossible

<JacekK> location="http://foo"; address="http://example.com/"; whttp:location="{location}"

<JacekK> http://example.com/{location}

<JacekK> http://example.com/http://foo

<Roberto> 6.4.2. says:

<Roberto> Input serializations may define additional processing rules to be applied to the value of {http location} before combining it with the {address} property of the endpoint element to form the HTTP request IRI.

<Roberto> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#http-operation-decl-relate

<gil> it seems like there are two issues here

Jacek: Need to clarify and provide an example - to illustrate where the address will be ignored and not included in the path - it isn't obvious

<Roberto> 6.4.2: This IRI is combined with the base IRI specified in the {address} property of the Endpoint component to form the full IRI for the HTTP request to invoke the operation.

Roberto: Also need to clarify what is meant as the combination of IRIs

<gil> (a) seems to be another new use case around "following a hyperlink"

<Roberto> where are the combination rules?

<gil> (b) seems to be clarifying the spec

Jacek: I think the spec supports this as Roberto described. Only need to clarify that it is in fact true, and that it may have an unexpected effect in certain corner cases

Philippe: Are we doing some URI escaping or not?

Tony: Only response is that there is no escape. What Roberto appears to have pointed out is that it substitutes the location before deciding what to do with what amounts to the two URIs

Jacek: No escaping mentioned in 6.7

Tony: If provide substitution by itself, implying "use URI as URI, don't escape it", but if in a string, then it is a parameter

Jacek: If anything before the parameter, escape it, otherwise not

Roberto: Way to address this would be to add more syntax

Philippe: Add explanatory text to spec - no encoding at this stage, and encoding only once full URI is formed. We would need to add a warning re: security w.r.t. this. Someone can make your service to go somewhere else if you don't check what you use as input.

Tony: So we should clearly indicate that no escaping is going on?

Jacek: Someone can interpret our spec to indicate that escaping is going on

Philippe: We need to clarify the spec language around this

ACTION: Philippe to write up recommended text to clarify the issue in CR53 [recorded in http://www.w3.org/2006/06/29-ws-desc-minutes.html#action02]

CR054

Tony: Sounds like Eric is asking for a change to XForms

Jacek: I think we should correct Eric on this. Specifies element name, not attribute, in section 6.1.1

Philippe: Don't believe there is an issue here. Eric is providing feedback as requested.

ACTION: Jacek to write a response to Eric correcting his interpretation of the text as described in CR054 [recorded in http://www.w3.org/2006/06/29-ws-desc-minutes.html#action03]

CR055

Jacek: This is done

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR055

http://lists.w3.org/Archives/Public/www-ws-desc/2006May/0087.html

<JacekK> Jacek's action completed at http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0026.html

Clarification needed on HTTP Transfer Coding

<JacekK> http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0032.html

I believe the desired description is clearly made with the language at hand with the proposal for CR044

Tony: If we accept Charlton's language for CR044 than we can consider this issue closed as well

http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0073.html

Tony: CR055 to be left open pending Charlton's AI for CR044

CR056

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR056

Questions on {http method} and {safety} extension properties

Tony: Mark CR056 as pending based on administrivia 4c

[Philippe fixed the reported typo]

CR057

http://www.w3.org/2002/ws/desc/5/cr-issues/#CR057

HTTPHeader name should be xs:string, not xs:QName

Jacek: Does anyone disdisagree with John Kaputin on this?

Gil: Note that John has implemented HTTPHeader as xs:string in Woden

Jacek: Have an example...

Jacek reads proposal

Resolution: Accept John's proposal as editorial item

ACTION: Editors to ensure that HTTPHeader name is of type xs:string, and not XS:Qname (see issue CR057)

Tony: At the end of time for the telcon - see you on the call next week

Summary of Action Items

[NEW] ACTION: Charlton to update his proposal based on the language correction suggested by Jacek per http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0026.html [recorded in http://www.w3.org/2006/06/29-ws-desc-minutes.html#action04]
[NEW] ACTION: Jacek to draft a response to Eric re: CR052 explaining that this represents a new use case, and that we will not be able to address this as such in the spec, but that it can be addressed as an additional extension.... [recorded in http://www.w3.org/2006/06/29-ws-desc-minutes.html#action01]
[NEW] ACTION: Jacek to write a response to Eric correcting his interpretation of the text as described in CR054 [recorded in http://www.w3.org/2006/06/29-ws-desc-minutes.html#action03]
[NEW] ACTION: Philippe to write up recommended text to clarify the issue in CR53 [recorded in http://www.w3.org/2006/06/29-ws-desc-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/06/29 18:33:57 $