Web Services Description WG
22 Jul 2004

<Marsh> Scribe: DBooth

Approval of Minutes

Minutes of July 8 accepted

Minutes of July 15 accepted - Jmarsh to fold in DBooth's correction.

Review of Actions

3.  Review of Action items [.1].
PENDING   2004-04-01: Marsh will get schema tf going.
?ED       2004-05-19: Editors to include in the primer an example 
                      that uses MTOM.  (Issue 72) 
DONE      2004-05-20: Editors to incorporate Hugo's full potato 
                      proposal.  (Issue 54)
?ED       2004-05-20: David Orchard to update HTTP binding to 
                      include discussion of how to generate an 
                      accepts header from schema annotations 
                      conformant to the media types extension 
                      document, and to use outputSerialization 
                      based on that information.  
?ED       2004-05-21: Editors to add ednotes to the spec to 
                      indicate areas that had contention.  (Issue 
                      190)
DONE [.7] 2004-05-27: Editors to add http:faultSerialization 
                      attribute.
?ED       2004-06-17: Editors to incorporate David Booth's clarification
                      in section 8.3 about what required means on MTOM
                      feature.
DONE      2004-07-01: Editors to add cross-references for component
                      properties, per DBooth's example.
DONE [.5] 2004-07-08: Editors to deal with issue 235, come back to 
                      the WG with issues if any.
DONE [.6] 2004-07-08: Editors to deal with issue 226, come back to 
                      the WG with issues if any.
?ED       2004-07-08: Editors to implement resolution to 177 as 
                      amended.
  (Some Part 1? component may remain.  Roberto will check.  Plus conformance section.)
PENDING   2004-07-08: Glen to verifiy composition model.
PENDING   2004-07-15: People who want to file a minority opinion 
                      should do so by July 22.
DONE      2004-07-15: Editors to change styles from list to set.
DONE      2004-07-15: Editors to make message label property 
                      required and make sure it always has a value.
DONE      2004-07-15: Editors to implement item 4 and 5 from 
                      Roberto's proposal.
?ED       2004-07-15: Editors to incorporate Operation Name proposal v3
DONE [.2] 2004-07-15: DBooth to send email to Mark Baker about issue 168.
?ED       2004-07-15: Editors to implement
                      /www-ws-desc/2004Jul/0047.html (Issue 211).
?ED       2004-07-15: Editors to implement
                      /www-ws-desc/2004Jul/0011.html (Issue 236).
DONE [.4] 2004-07-15: Hugo to clarify the second part of the proposal
                      (readibility).
DONE [.3] 2004-07-15: Paul to research the fault decisions we've taken
DONE      2004-07-15: Editors to implement
                      /www-ws-desc/2004Jul/0011.html 
                      except for faults and SOAP binding readability
                      problem. (Issue 237)
DONE      2004-07-15: Roberto to check if feature and property placement
                      in the infoset representation prose is consistent 
                      with the schema.
DONE      2004-07-15: Editor to include DaveO's wording:
                      /www-ws-desc/2004Jul/0073.html (Issue 240)
?ED       2004-07-15: Editors to indicate error for AD HTTP binding in 
                      case of conflict. (Issue 241).

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0280.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0257.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0263.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0253.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0287.html
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0301.html

<hugo> Hugo notes: "The type of the targetNamespace attribute information item is xs:anyURI." or "The type of the name attribute information item is xs:NCName"

<scribe> ACTION: GlenD to review Part2 text relevant to AD feature

<scribe> ACTION: Part2 Editors to follow up with GlenD about Part2 text relevant to AD feature

Administrivia

<scribe> ACTION: Sanjiva to check on logistics for Toronto F2F

<scribe> ACTION: dbooth to follow up on XMLP request for response on comment

New Issues

SOAP 1.1 binding: Asir to present something at F2F.

Media type: postponed

Issue 247: Which came first, the function or the binding?

Amy: This is about info organization -- not needed for LC.

(postponed) [Chair will treat this as an agenda item rather than an issue for now.]

Editorial issues: 226 Cross-binding HTTP features

Hugo: DaveO's approach was not bad.
... Asir thought it was ok. Draft is now okay, so it only needs links.

RESOLVED: Issue 226 closed

Editorial Issues: 235 Definition of Fault

JMarsh: Paul suggested text to clarify definition of faults. Where should it go?

Sanjiva: I think what we have is sufficient. Any more info belongs in the primer.

JMarsh: But this involves the definition of fault.

MarkN: Part1 makes more sense.

dbooth: At least one person thinks it needs clarification, so it would seem prudent to clarify it.

<scribe> ACTION: Sanjiva to add Paul's clarification of fault in an appropriate spot.

RESOLVED: Close issue 226

Editorial issues: David Orchard's action to update HTTP binding

Hugo: To differentiate what DaveO proposed, he proposed using the AD feature to set the accept header. My proposal was that each implementation would have different features and set the accept header differently. So apps should be able to set the header as they want, and they should take into account the media type when they do that.

Umit: I don't think this affects the media type Note. It only affects part3 -- a hint for how to use the media type Note -- not the other way around.

Hugo: I proposed two changes. Expected media type placed on an input header acts as an accept header from the point of view of the service.

JMarsh: So can we separate this from part3?

Hugo: Yes.

<scribe> ACTION: Hugo to incorporate media type fix into part3

webMethod issue: Issue 229: useOperationWebMethod proposal & Issue 169: Syntax for webMethod - property or attribute?

Considering proposal described at http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0288.html

Roberto: Did you intend this attribute to be in the wsdl: namespace?

DaveO: No. Should be same namespace as interface operation. When it uses the location it should use that namespace.

Sanjiva: So it's not a global attribute.

JMarsh: It would appear on wsdl:operations.

<asir> is a local attribute

Sanjiva: the proposal suggests putting HTTP method values on abstract operations, which might not go over HTTP.

JMarsh: You don't find us renaming the attributes to be generic -- they use HTTP names.

<sanjiva> Our SOAP binding makes use of this facility when we're sending SOAP/HTTP .. if the SOAP/SMTP it does not make use of this facility.

DaveO: Why in the interface and not in the binding? If you look at all of our bindings, they can make use of this facility, whether it is over HTTP or SOAP. It is not binding specific.

<GlenD> That's a specious argment.... Dave means the SOAP-over-HTTP binding, not the generic SOAP binding, I think.

<umit> +1 to Sanjiva

<GlenD> yeah

DaveO: Re: the issue of binding to protocols that don't support generic operations, they wouldn't make use of it.
... SQL has four generic operations like HTTP, and many other things do also. It works extremely well when the protocols are using HTTP or SOAP. Not clear with other protocols, but there is applicability.
... I showed how much simpler the binding would be if we had this facility at the operation level.

JMarsh: Formal vote on accepting this proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0288.html
... PaulD gave DaveO his proxy on this issue.

Yes: Agfa-Gevaert N. V., British Telecommunications (by proxy), W3C, BEA Systems

No: Lexmark, Rogue Wave Software, Sun Microsystems, SeeBeyond, Macromedia, DERI, TIBCO, SAP, webMethods, IBM, Oracle

Abstain: Computer Associates

Total no: 11, yes: 4

Motion is defeated.

<sanjiva> I'd vote +1 for http:webMethod on <wsdl:operation> FWIW. :-(

DaveO: I'll probably resubmit this as a binding-specific proposal after LC.

RESOLVED: issues 229 and 169 closed

Issue 130: Need async request/response HTTP binding

DaveO: Operation as in/out can be bound into two different HTTP request/response pairs (in HTTP for example).
... An HTTP request contains the input message, with null response. Then HTTP request with the output, with null response.
... Difference from Sanjiva's proposal: HTTP binding makes use of 2 req/res HTTP MEPs to do this. I.e., One interface:operation MEP becomes two MEPs on the wire.
... The binding assumes 1 MEP, so you can do the usual things, such as the SOAP action sets the protocol.
... I propose we allow the binding of the output to specify the SOAP action/protocol.
... How to specify the callback location: either a fixed address, or a magic runtime value.
... The reason for a fixed location for a callback: Two parties (Walmart and supplier) exchange WSDL. They'll exchange messages every once in a while, using an established callback address. It allows the callback address to be specified in the address.

<Zakim> sanjiva, you wanted to explain my proposal and explain why I made it at all ..

DaveO: Sanjiva's proposal instead introduces a new SOAP MEP -- a callback MEP.

Sanjiva: My problem with DaveO's proposal: It uses 2 soap MEPs to do one WSDL MEP, and [missed].
... I have one in and out message. If it's over HTTP, we just need to define another one to say how it's done with two HTTP connections. Seems cleaner to me. I don't understand fixed response address. How would I know it if I'm a service?

<Zakim> asir, you wanted to ask a question

Asir: Looking at both proposals, why is this in scope for WSDL 2.0?

Sanjiva: Several people wanted to support async interactions.

MarkN: Sanjiva's proposal seems to require a new MEP every time we want an async interaction. The Liberty async MEP hasn't gotten good pickup.

<alewis> I agree with Sanjiva: any asynch soap/http is effectively creating new stuff.

Sanjiva: I agree adoption is difficult.

MarkN: If we use a more generic way, we don't have to solve the problem again and again. I'm afraid of explosion of MEPs.

Sanjiva: We're not defining a new MEP -- it's a new binding for the same MEP.

GlenD: Mark's proposal is misleading. Every time you give a new MEP, you'll still have to explain it.
... Another possibility: WSDL over WSDL. The input is this wsdl:operation, and output is this wsdl:operation. Not ready to make a full proposal on this thoough.

Ugo: This is like adding a correlation mechanism.

<umit> ws-md has already solved this problem

Ugo: If you're async, you need correlation. I would not require the correlation mechanism to be specified, but want the option to specify the correlation mechanism.

Roberto: I like much of GlenD's suggestion, but it points to the problem: We're getting into choreography space.

<asir> Agree with Roberto that we are invading the Choreography space

Roberto: We might get it wrong.

<Marsh> unmute DaveO

Roberto: If we make the in-out pattern fit everything, it becomes meaningless.

Umit: You should be able to change the reply address for the situation. Glen's proposal is one way of looking at it. Another way is to use two different in-out operations. There is a need for async interaction.
... I've been exploring looking at two different WSDLs, and wouldn't support any approach that fixes the reply address.

Sanjiva: Simple req/rep with async response pattern is likely to become the dominant pattern in use, so I think it should be handled gracefully in WSDL -- something simple.

<Helen> david: fully agreed with your above point

Hugo: we don't have a requirement for this, so we should consider that any proposal on this may take a lot of time.

<asir> thanks to Hugo, I agree with you

(JMarsh takes a straw poll)

Total votes: No: 10, Yes: 4

Helen: This is quite important in our case -- medical systems. Can we have another round of proposals?

JMarsh: We already discussed this some before you joined. Last Call implies that we won't revisit this unless we get a LC comment that forces us to consider it, which your employer could decide to do.

<Zakim> alewis, you wanted to ask: wasn't the straw poll about whether asynch soap over http should be considered a requirement?

Ugo: We should point out that we aren't saying WSDL shouldn't support this -- just that we aren't supporting it at this time.

Amy: I thought this was about whether we should have a requirement to do this.

<Helen> I thought this is not a requirement but providing a way to enable asy service

JMarsh: We're addressing issue 130, which considers whether we have a requirement to meet this. That doesn't necessarily mean we won't consider it.

<asir> Amy, that sounds like a question for the XML Protocol WG ..

Amy: Issue 130 is something that could be reasonably done outside of WSDL in an interoperable way, and might be better to do that way.

Sanjiva: This is a binding we're talking about, and bindings are extensible. IBM and others could get together and submit it to the WG to publish as a Note.

CONSENSUS: Close issue 130 with no action.

Issue 168: Which operation

JMarsh: dbooth got confirmation back from Mark Baker: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0281.html

RESOLVED: Close issue 168

Issue 237: Editorial issues with Part 3 -- readability

Hugo: Section 3 in part3 is easier to read than section 2, because the pseudo-schema is presented first. So I proposed putting the pseudo-schema earlier.

<scribe> ACTION: Editors to move pseudo-schemas up front

RESOLVED: Close Issue 237

Issue 189: Binding message content to URI

(JMarsh summarizes proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html )

Hugo: Would a trailing slash conflict with some other purpose?

DaveO: I don't know.

Hugo: I could have a URI ending with a slash, in which case it would be a problem, but maybe we can escape it.

DaveO: Can't have a slash in a local name.

Asir: What if you want a trailing slash in the URL?

<Marsh> location='temperature/{town}'

<hugo> location='temperature/town/{town[@id]}){/}'?

<asir> thanks hugo

<Marsh> Not the {/}, AIUI

<asir> why not http:doNotAppendQueryParameters=true

DaveO: If I have an element with three things, and I want to do a PUT on that document, I need to serialize part of that instance data into the URI, but not the whole thing -- a subset.
... Without this facility, you need two different datatypes: one for GETs and another for PUTs.
... or DELETEs.

Sanjiva: This proposal only applies to the extension for HTTP binding, right?

DaveO: This applies only to HTTP PUT and DELETE.
... Because in a GET you put everything in there.

Asir: You establish a relationship between the verb and the location syntax.

JMarsh: This is a mechanism for overridding the default. To turnn off anything that remains as a query parameter.

(JMarsh conducts straw poll on proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html )

<JacekK> noop

Total votes: Yes: 3, No: 1, and MANY abstentions

<GlenD> hm

Helen: I voted no because when we talked about URI, and there is a parameter for temperature, when we work toward the semantic web we want a distinction -- a value versus a location.

RESOLVED: Proposal adopted (No objections)

JMarsh: Proposal 2a is to add attributes.

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html

(Proposal 2a is in http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html )

DaveO: We use IDs a lot in XML, but you can't put an ID attribute into the URI, so you're forced to use an element and can't use an XML ID attribute.

<Zakim> asir, you wanted to argue against 2a and 2b

JMarsh: We'll take these two proposals (2a nd 2b) together.

Asir: At a high level, this is about mapping an XML data model to a URI data model. Instead of that, i think we should see what is possible to map from URI model to XML model.

JMarsh: How does that address DaveO's desire for an ID attribute?

Asir: you can't.

Roberto: Doesn't 2b cover 2a?

JMarsh: Yes. Today, you can pick specific elements and put them in the URI. Any other elements appear as query parameters. 2a adds attributes (missed), and 2b allows you to bind attributes if you want.

Roberto: I like 2b but not 2a.

Asir: Do we have the concept of an ID in the URI data model?

JMarsh: No.

Umit: I share Asir's concern. If you don't specify a URI model to XML model, where do we draw the line?

JMarsh: These proposals are very specific.
... 2b would allow attributes to be bound, but not by default.

DaveO: But then you can't do something like artist ID=5, and then add content to that element.

JMarsh: The proposal is not to propose attributes be bound by default.

Roberto: I'm proposing taking your proposal 2b but not 2a. Would that meet your need?

DaveO: I could live with that.
... I'm mainly concerned about and ID attribute or an HREF attribute.

( JMarsh conducts straw poll on proposal 2b from http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html )

Total votes: Yes: 3 No: 2 and MANY abstentions

JMarsh: Any objections?

dbooth: I would object, given the opinion is that close and there are that many abstentions.

DaveO: It's easier to take something out after LC than put something in.
... I'

<Marsh> Asir seconded dbooth's objection.

DaveO: I've done a fair amount of work on this, and think that the default mode should be to accept someone's proposal who has done a lot of work on it and thought about it a lot.

<Zakim> hugo, you wanted to talk about W3C process

Hugo: It's not necessarily easier to remove than to add -- it's easiest to keep the status quo. The process document says there may be features that are clearly marked "at risk", which means that they may be removed at the next phase. If the status quo is to add them, then taking them out would be harder.

Roberto: I think this is a minor addition to the spec. No reason to turn it down. The proposal is a natural solution to an actual problem.

Asir: I followed DaveO's proposals, and it isn't a minor addition.

DaveO: It's a subset of XPath -- not adding XPath.

JMarsh: Consensus to NOT add this?

DaveO objects.

<JacekK> what's the vote question again?

<asir> what is the question?

(JMarsh conducts formal vote on whether to adopt proposal 2b in http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html )

Yes: Lexmark, Sun Microsystems, BEA Systems

No: Rogue Wave Software, Agfa-Gevaert N. V., Macromedia, TIBCO, webMethods, IBM

Abstain: SeeBeyond, Sonic Software, W3C, DERI, SAP, University of Maryland MIND Lab, Oracle

Vote totals: Yes: 3 No: 6 and many abstains

JMarsh: Let's consider DaveO's proposal 3a on how to use qnames ( http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html )

DaveO: This is the simplest way I could see to allow mixed namespace serialization. It seemed like an easy addition.

<GlenD> sorry folks - hard stop for another call :(

<asir> item (c) in http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0210.html

Asir: Where do we draw the line? June 22 i offered a counter proposal: item (c) in http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0210.html
... Counterproposal is to disallow qnames in URI style.

DaveO: Do you want XML to element URI mapping? How far does your objection go?

Asir: We should do whatever is possible in the URI.

<Zakim> Marsh, you wanted to ask whether using prefixes out of context is completely broken.

JMarsh: Restrict the URI style to whatever maps naturally into a URI.
... This looks like using undefined namespace prefixes out of context. How could this possibly work?

<TomJ> +1 to Jonathan, using prefixes in this way seems broken to me. Prefixes can change

JMarsh: The URI doesn't give me a context for the namespace prefixes.

DaveO: Recipient would know the WSDL.
... If you don't want it, you shouldn't support it.

Umit: But two XML documents could use different namespace prefixes that are defined the same.

DaveO: The WSDL document gives the prefix definitions.
... in my model, somebody creates a schema with artist:name. The WSDL says how you can convert it to a URI.

JMarsh: What if I used default namespace declarations instead of prefixes?

MarkN: So that would make the WSDL brittle? JMarsh: Yes.

DaveO: I don't see people doing that a lot. They define their namespace prefixes in a set, and then use them. I'm trying for the simplest possible thing that would allow us to transmit mixed namespace content. I know it's not full featured.

Umit: I think you're making a simplistic assumption. You don't need to retain the namespace prefixes. I could use a processor that doesn't retain them.
... This would require processors to retain the namespace prefixes.

DaveO: Umit, are you saying you support the need for mixed namespace content? or that this specific solution is too simplistic?

Umit: I would consider another proposal.

DaveO: The one piece I want to include is the ability to mix namespaces. I think that's important.

Sanjiva: I think the qnames are a stretch, because it's ugly to support them.

DaveO: Three positions: Don't support mixed namespaces; partial support of mixed namespaces; full support of mixed namespaces.

Straw poll on DaveO's proposal 3a: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0276.html

Vote totals: Yes: 2 No: 11

RESOLVED: Reject proposal 3a

<asir> (c) {type definition} of an element declaration [2] in the complex type that

<asir> defines the body of an input element MUST NOT be a xs:QName, xs:NOTATION, or

<asir> any simple type derived from xs:QName or xs:NOTATION.

<hugo> http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0210.html

<hugo> Proposal (c)

(Discussion of Asir's proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0210.html )

Straw poll on Asir's proposal c:

Vote totals: Yes: 4 No: 2

JMarsh: (This would disallow qnames in content if you use the URI style)

RESOLVED: proposal c accepted ( http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0210.html )

ACTION: Part 3 editors to incorporate Issue 189 proposal 1, 2b, and c.

JMarsh: We'll vote on July 29 on going to LC on Aug 3.

Remaining Issues

Issue 238 - refer to editors.

Issue 243 - adopted, need to change component references to be consistent. Issue closed.

Issue 246 - adopted.

Issue 248: Property component's dependency on XML Schema -- adopted.

Issue 249: HTTP binding mismatch and identification missing -- editorial.

Issue 247: Which came first, the function or the binding? -- deferred to F2F.

JMarsh: Editorial action to remove ed note on media type.
... Issue to remove property inside soap module (mentioned by Asir) -- needs more discussion on the list.
... Issue about needing schemas for SOAP binding -- editorial.

ADJOURNED