W3C

W5 Description WG

27 Oct 2005

See also: IRC log

Attendees

Present:
Charlton Baretto, Adobe Systems
Rebecca Bergersen, IONA Technologies
Allen Brookes, Rogue Wave Software
Roberto Chinnici, Sun Microsystems
Glen Daniels, Sonic Software
Paul Downey, British Telecommunications
Youenn Fablet, Canon
Hugo Haas, W3C
Tom Jordahl, Macromedia
Anish Karmarkar, Oracle
Amelia Lewis, TIBCO
David Orchard, BEA Systems
Vivek Pandy, Sun Microsystems
Bijan Parsia, University of Maryland MIND Lab
Tony Rogers, Computer Associates
Arthur Ryman, IBM
Sanjiva Weerawarana, Invited Expert
Umit Yalcinalp, SAP
Regrets
Jacek Kopecky, DERI Innsbruck at the Leopold-Franzens-Universitšt Innsbruck, Austria
Kevin Canyang Liu, SAP
Jean-Jacques Moreau, Canon
Asir Vedamuthu, Microsoft
Chair
Marsh
Scribe
alewis

Contents


<scribe> Scribe: alewis

Approval of minutes

Minutes 2005-10-20 approved.

Action Items

3.  Review of Action items [.1]. 

?         2005-07-21: pauld to write a proposal for a working group 
                      report for requirements for schema evolution 
                      following closure of LC124 
CLOSED    2005-09-26: DaveO to draft a response and send to the WG. 
                      (LC335), due 2005-10-06. 
DONE [.7] 2005-09-26: Arthur to draft above as a proposal to be able to 
                      close this issue (LC344#5), due 2005-10-06. 
?         2005-09-26: Arthur to look for simplification options for 
                      comment 12 of 344. (LC344#12), due 2005-10-06. 
?         2005-09-26: Jonathan to point this out when it gets 
                      Implemented (LC344#13), due 2005-10-06. 
DONE [.8] 2005-09-26: Sanjiva and Roberto to investigate defaulting with
                      interfaceless bindings (LC333), due 2005-10,06 
DONE [.3] 2005-10-06: Marsh to investigate LC301 re .NET scenarios, 
                      due 2005-10-13. 
DONE [.4] 2005-10-06: Charlton to augment Hugo's proposal with 
                      parameters for all serializations, and syntax 
                      for suppressing parameters, due 2005-10-13. 
?         2005-10-20: Bijan to contact WG to ask for contribution to 
                      test suite, due 2005-10-27. 
DONE [.5] 2005-10-20: Marsh to forward nits to SPARQL, due 2005-10-27. 
DONE [.9] 2005-10-20: Tony to write up issues on I18N draft and email to
                      WSD mailing-list, due 2005-10-27. 
DONE [.10] 2005-10-20: Hugo to send email describing sanjiva's 2 properties
                      proposal (LC304), due 2005-10-27. 
DONE [.6] 2005-10-20: Marsh to go send email asking for clarification 
                      (LC357), due 2005-10-27.

Current Editorial Action Items 
?         2005-07-21: Arthur to add stable identifiers for each 
                      assertion, due 2005-09-26. 
?         2005-09-26: editors to fix the first paragraph of section 4 
                      ... does not make sense at all right now. 
                      (LC344#5), due 2005-10-06. 
?         2005-09-26: Editors to add a sentence saying {address} is 
                      optional because it could be defined by other 
                      means, such as an WS-A endpoint reference or maybe
                      the scenario does not require an address. 
                      (LC344#13), due 2005-10-06. 
?         2005-09-26: Editors fix "Case Elements NOT cited" in 6.8.1.2 
                      header to be "Case of elements NOT cited" (LC345),
                      due 2005-10-06. 

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/lc-issues/actions_owner.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0044.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0045.html	
[.5] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Oct/0051.html
[.6] http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Oct/0042.html
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0040.html
[.8] http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0051.html
[.9] http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0049.html
[.10] http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0046.html

Administrivia

information on face to face, post-meeting outing.

discussion of interop event rather than face to face in january, face to face at tech plenary in february.

<scribe> ACTION: Jonathan to schedule january/february meetings [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action01]

<Jonathan_Marsh> ACTION: Marsh to propose Jan meeting dates. [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action02]

Drop Action 1

ACTION- 1

status of rdf document: in process

<Jonathan_Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0049.html

<scribe> ACTION: Marsh to send tony's comments on behalf of working group [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action03]

<pauld> times for the WG: http://www.timeanddate.com/worldclock/custom.html?cities=103,224,231,43,136,195,389,152

<scribe> ACTION: Marsh to remind WG members of change in times [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action04]

<Jonathan_Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0027.html

Arthur has proposed text clarifying the use of built-in schema types.

arthur: just a matter of not having to explicitly import schema datatypes

tom: what does wsdl 1.1 do?

text approved.

<Tomj> WSDL 1.1 doesn't say, and implementations usually assumes schema type were available without importing

TOPIC: LC301 soapaction granularity. match WS-A?

marsh: soapaction set on request only, not on reply.
... therefore, can keep it on operation, applies only to initial message of exchange

<Tomj> +1 for status quo with clarification: SAOPAction applies to initial message only and is an operation level attribute (as it is in WSDL 1.1).

sanjiva: for in-out, if the reply goes to a non-anonymous address, then it needs a soapaction

marsh: that's ws-a specific; use ws-a extensions

anish: is that soap 1.1 or 1.2?

discussion of whether soapaction is always required (or always set) on the reply for soap 1.1

tom: in non-async case, no one cares about action on back channel

anish: wants to check whether soap 1.1 requires soapaction in all messages

<sanjiva> http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383528

<pauld> grepping through some logs, i've not seen SOAPAction on a response in the wild when using a wide variety of toolkits

<Roberto> SOAP 1.1 spec, section 6.1.1, talks about the "SOAPAction HTTP request header field" which "an HTTP client MUST use"

hugo: only concerned with soapaction sent to the service? that only works with a single input message.
... right now, soapaction value is set on all messages in an exchange.

roberto: soap 1.1 only specifies action on request message

marsh: existing practice seems to be for synchronous exchanges, action is only on initial message.

<umit> +1

marsh: do we want to handle extended meps (more than one input message) or asynchronous exchanges?

tom: if we say it shows up on initial message, we're not preventing people from putting it on subsequent messages.
... suggests status quo, with clarification that soapaction required on initial message.

umit: need to consider asynchronous case. need to permit future uses of soapaction; leaving it at operation level may not be the best choice.

<Roberto> based on the text in SOAP 1.1 I referenced, the statement in issue LC301 that "The SOAPAction HTTP header in SOAP 1.1 [...] are properties of a message" seems incorrect.

tom: soapaction is just an http header, shouldn't change status quo

<Zakim> hugo, you wanted to say that this solution doesn't describe all of SOAP 1.2

hugo: if soapaction is not at message level, then we are not describing soap 1.2, because that is where it is defined in soap 1.2

<Zakim> Jonathan_Marsh, you wanted to ask if we move it, whether we need restrictions on having it on certain replies...

marsh: if the soapaction is different between input and output, is that illegal?

hugo: prohibited in 1.1, allowed in 1.2

glen: why would this be prohibited?

marsh: oh, so if you put it on 1.1, then it will be ignored.

hugo: restrictions already exist in soap 1.1 binding

glen: then we should fix that, because it shouldn't be prohibited.

tom: we shouldn't change soapaction

umit: we need to change granularity

marsh: call for explication, need to compose well with ws-addressing.

<Jonathan_Marsh> ACTION: Umit to look at SOAP 1.1 binding whether soap action on response is prohibited or ignored (should be ignored) [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action05]

roberto: soap 1.2, there is only one value for the action property for a message exchange.

umit: argument is for asynchronous cases; binding for async http doesn't work.

roberto: that binding isn't written; we shouldn't start multiplying properties before the binding is written.

hugo: soap 1.2 http binding permits sending of soapaction on response.

roberto: can't see that in the text.
... there is only one action property; it can only have one value. so we don't need to describe more than one.

<Tomj> +1

<sanjiva> I'd like to suggest leaving it as is, per Tom's suggestion. I think that most reasonable people will simply copy the value of wsa:Action into the SOAPAction HTTP header to do the send of the response and be done with it.

glen: the fact that there's only one property doesn't mean that the property can't have different values in the course of the exchange.

hugo, glen: need clarification

marsh: call for new arguments/information

<Jonathan_Marsh> chad, new poll

<chad> new poll

doesn't address hugo's case, but hugo's case requires extended binding anyway.

<Jonathan_Marsh> option 1: status quo

<Jonathan_Marsh> chad, option 1: status quo with clarification (initial message only)

<Jonathan_Marsh> chad, option 2: move to message

<pauld> chad, question: options for LC301

<sanjiva> vote: 1

vote: 2

<Tomj> vote: 1

<hugo> vote: 2

<TonyR> vote: abstain

<Jonathan_Marsh> vote: daveo: 2

<Allen> vote: 1

<bijan> vote: abstain

<youenn> vote: 1

<Jonathan_Marsh> vote: 1

<Arthur> vote: 2

<RebeccaB> vote: abstain

<pauld> vote: 2

<Roberto> vote: 1

<umit> vote: 2, 1

<Jonathan_Marsh> vote: Anish: 1,2

<charlton> vote: 1, 2

<gdaniels> vote: 2

<Jonathan_Marsh> vote: vivek: 1

<Jonathan_Marsh> chad, count

<chad> Question: options for LC301

<chad> Option 1: status quo with clarification (initial message only) (9)

<chad> Option 2: move to message (7)

<chad> 19 voters: alewis (2) , Allen (1) , Anish (1, 2) , Arthur (2) , bijan () , charlton (1, 2) , daveo (2) , gdaniels (2) , hugo (2) , Jonathan_Marsh (1) , pauld (2) , RebeccaB () , Roberto (1) , sanjiva (1) , Tomj (1) , TonyR () , umit (2, 1) , vivek (1) , youenn (1)

<chad> Round 1: Count of first place rankings.

<chad> Candidate 1 is elected.

<chad> Winner is option 1 - status quo with clarification (initial message only)

RESOLUTION: lc301 closed with clarification of the status quo, soapaction applies to initial message only

<Jonathan_Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0046.html

LC304

HTTP serialization properties/attributes

<sanjiva> Hugo: just push the property down to the <input>/<output>/<fault> elements and you are back to 2 properties :)

hugo: need six properties in order to fully define things
... need to specify input/output/fault serialization, then input/output/fault content-type.
... this seems needlessly complicated (provides example)
... would require return to last call if we made such a change

sanjiva: there are really only two properties, just push the properties down to the input, output, and fault elements.
... this reduces the number of properties to two.

hugo: the uri proposal also would probably require a return to last call, because it is substantive to the commenter.
... simplified proposal: since messages are defined in terms of xml, then the application/xml serialization format is adequate for application/*+xml, so we can define the serialization format property for the three styles.
... and if it's not one of the ones that we've defined, then use application/xml serialization and the content-type specified.
... if it doesn't suffice for other purposes, people will need to define extensions anyway, so let them also define serialization.

umit: sanjiva's two-property approach, pushing down to message level, seems more appropriate.

marsh: but weren't the properties on operation so that they can default?

hugo: two-property approach is cleaner and more extensible, but not sure of consequences of design and would take us back to last call.

umit: simplified approach requires convoluted design for extension; other proposal provides cleaner extensibility.

hugo: simplified proposal preferable because it's simple, one sentence, and we understand it.

tom: would we have to return to last call?

clarification of proposal. if one of three media-types we've defined, then we use one of three serialization formats. if not one of those media types, use application/xml serialization.

sanjiva: doesn't appear to permit multiple media types.

marsh: that's a separate issue, resolved at face to face.

hugo: clarifies proposal [see above; i've typed it several times now, i think]

marsh: doesn't cover something like image/jpeg, or how one would serialize xml into image/jpeg format.

sanjiva: how would we describe flickr, for example?

umit: seems to prohibit the use of an extension that would enable something like this, since it would implicitly use application/xml

(discussion of some other elliptically-referenced proposal)

hugo: likes sanjiva's proposal, but feels that it is too late in the process.

marsh: other feature is a means of mapping from base64binary to message.
... maybe this is interest in raising a new issue, how to describe image/jpeg in http binding.
... does wg prefer hugo's simplified proposal, or sanjiva's suggestion of moving two properties onto messages?
... is it possible to resolve this issue without resolving image/jpeg issue?
... question of composition. which proposals work together, and support something like image/jpeg?
... discuss the image issue on the list, and return to the issue next week.
... administrivia: next week will be shorter than usual; we will be setting agenda and action items so that all issues can be decided at face to face.

meeting ends.

Summary of Action Items

[NEW] ACTION: Jonathan to schedule january/february meetings [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action01]
[NEW] ACTION: Marsh to propose Jan meeting dates. [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action02]
[NEW] ACTION: Marsh to remind WG members of change in times [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action04]
[NEW] ACTION: Marsh to send tony's comments on behalf of working group [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action03]
[NEW] ACTION: Umit to look at SOAP 1.1 binding whether soap action on response is prohibited or ignored (should be ignored) [recorded in http://www.w3.org/2005/10/27-ws-desc-minutes.html#action05]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2005/10/27 16:40:50 $