See also: IRC log
<scribe> Scribe: alewis
Minutes 2005-10-20 approved.
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
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
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.