Web Services Description Working Group call
25 Mar 2004

Minutes approval

<Scribe> Approved

Review of Action items

3.  Review of Action items [.1].
PENDING   2003-09-18: Marsh to review the QA operational
                      guidelines.
PENDING   2004-01-08: Pauld to write up examples of schemas for the
                      Primer.
PENDING   2004-01-28: Philippe and JMarsh will look at the ipr for 
                      test suite.
PENDING   2004-01-30: DaveO to write up a proposal for augmenting 
                      schema information to enable versioned data.
PENDING   2004-02-12: DaveO to produce a refined proposal for Asynch 
                      HTTP binding addressing the concerns of folks 
                      that object to leaving replyTo info out of WSDL.
DONE [.2] 2004-03-04: Editors to add back the WSDL Component 
                      Designators back to the spec as SHOULD.
DONE [.6] 2004-03-05: Editors to write in the spec the wsdlLocation
                      global attribute proposal along what has been 
                      done for xsi:schemaLocation.
PENDING   2004-03-05: DavidO to notify TAG about our decision on safety.
PENDING   2004-03-05: Editors of media type proposal to give Jonathan a 
                      list of open issues.
DONE      2004-03-11: Sanjiva to fill in data for May FTF on logistics 
                      page.
PENDING   2004-03-11: JMarsh, David Booth, David Orchard to form adhoc 
                      group to explore stylistic rendering options.
DONE [.3] 2004-03-18: Editors to clarify the meaning of 'change' WRT to
                      optional extensions.
DONE [.4] 2004-03-18: Editors to implement David Booth's proposal on 
                      making all notes non-normative and moving 
                      the normative text into the regular
                      paragraphs.
DONE [.5] 2004-03-18: Editors to incorporate Jonathan's proposal for 
                      issues 146 & 150 (with #empty changed to 
                      #none).
DONE [.6] 2004-03-18: Editors to make binding/operation/(input|
                      output)/@messageLabel optional and have the 
                      same rules as the corresponding thing in
                      interface/operation for computing the value.

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0196.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0193.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0188.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0195.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0284.html

Sanjiva: I want to propose to specify the semantic of any as any *one* element

Jonathan: Gudge sounds interested in allowing a sequence of elements, but I don't know why

Administrivia

Jonathan: the week of August 2nd looks best

we should decide on the length of the meeting; a 4-day meeting is possible

Tom: 4 days sounds like a long time

Jonathan: I would like to have a Tuesday-Thursday meeting

Arthur: are we collocating with another Group?

Jonathan: no

William: Is it possible to do a noon to noon meeting on 4 days?

Jonathan: if we don't do it in London, I could look into organizing it in Redmond

Privacy

<dbooth> Hugo: P3P allows a privacy policy to be expressed in machine-readable form. The P3P WG is working on P3P 1.1, a generalization of 1.0, to random XML vocabularies.

<dbooth> Hugo: They released first WG in Feb. We wrote a team submission that shows how a generic P3P attribute can be attached to an element in WSDL and what it would mean.

<dbooth> Hugo: The first part shows abstractly what it would mean to attach a privacy policy to a WSDL 2.0 component. The second way shows two concrete ways to do it.

<dbooth> Hugo: More recently I saw email from Glen about Features and Properties that seems to indicate that F&P is more restrictive.

Philippe: this is an experimentation at this point

Jonathan: so the output would be a list of issues again the spec

<asir> http://www.w3.org/TeamSubmission/2004/SUBM-p3p-wsdl-20040213/

Jonathan: volunteers?

<dbooth> Hugo: (Answering "Why are there 2 ways to do this?") To illustrate that it could be done in two ways, and illustrate the differences between them.

Tom: it seems that you have found that the use of attributes is more flexible than the use of features and properties

<sanjiva> +1 to using this example to learning about F&P vs. extensions ..

<Scribe> ACTION: Hugo to look at the Handling Privacy in WSDL 2.0 for issues against our spec

Jonathan: people are encouraged to read and review this informally

Review of the XML Schema PER

Jonathan: Volunteers?

we have 3 weeks to do this

Paul: I am interested in having a look

Asir: I haven't seen anything which would be a problem to us

<Scribe> ACTION: Paul to review the XML Schema PER

Task force status

Jonathan: I have seen some emails by the Media type description

task force

Umit: I am almost done converting the document

the plan is to publish as is, and then modify Anish is now officially the co-editor on the XMLP WG side

Jonathan: XMLP has more constraints than we do on this

they should be driving the timing the Schema versioning task force still needs some work on the charter to be started

New Issues. Issues list

<WilliamV> zakim ??P18 is WilliamV

Jonathan: we have Issue 157: f&p at the service level

#any should mean "any element" not "any thing" has several proposals for it

Arthur: somebody said that they wanted to use simple types

Yaron: a good test for our feature set: would our declarative model permit to describe any allowable SOAP content?

Paul: security is a good use case; with lots of pointers

Jacek: I would like somebody to champion the use cases for this

<sanjiva> I'd like to propose that we limit element=#any to mean *any one element* for right now. If someone wants to generalize it further then can raise an issue and/or make a proposal.

<Roberto> +1

<TomJordahl> +1 to sajniva -

<alewis> +1 to sanjiva's proposal.

Umit: if we are saying that we have an element-based model, we should just stick to the model

<umit> +1 to Sanjiva.

Arthur: do we want a more flexible message model, or have a simpler message model and force the work into the binding?

<prasad> +1 to sanjiva

Sanjiva: I'd like to propose that we limit element=#any to mean *any one element* for right now

Jonathan: would anybody object to changing our status quo as proposed by Sanjiva?

<Scribe> no objections

RESOLUTION: limit element=#any to mean *any one element*, and open a new issue

Jonathan: Jacek proposed some "paths" to detail processor conformance

DavidB: I dropped Jacek's proposal accidentally when integrating the text

I think that we need to do more work on wording in the spirit of Jacek's proposal

Umit: if we want to adopt Glen's description, we will be in a place where we'll be arguing about which MEP will be in the conformance set, etc.

<sanjiva> ACTION: editors to update draft to change the semantics of element=#any to mean *any one element*

Umit: I think that we should be concerned only about document conformance and leave out processor conformance

Amy: if we are going to talk about processors at all, then we need to make it clear that a processor that isn't going to go a particular path shouldn't throw certain errors

RESOLUTION: open a new issue about processor conformance "paths"

MIME Binding

<dbooth> I think we need to think of this (or define this) in terms of dependencies, but we need to be clear and careful in defining those dependencies.

<sanjiva> +1 to closing non-existant MIME binding issues

Jonathan: we don't have a MIME binding in our charter

I would propose that we close those issues

Prasad: how do you describe attachments at the binding level?

Jonathan: we haven't started working on MTOM; when we do, we will know the answer to this question

RESOLUTION: issues 58 & 59 without action

Amy: will we be able to describe attachments without SOAP?

Jacek: I think that it's out of scope

Sanjiva: isn't this related to the media type work?

Philippe: I believe it's different

my plan was to support XOP in the HTTP binding

Issue 66: How to represent the equivalent of hypertext links?

Jonathan: I believe that this was asking for service references and that it is therefore satisfied

Arthur: we can close it on the understanding that you can't address XLink

RESOLUTION: issue 66 closed

Support for SOAP 1.1

Jonathan: this is in our charter now

I have a volunteer: Asir I am appointing him as our editor for the SOAP 1.1 binding editor what is our timeline?

Arthur: we just need to have it by the time we get WSDL 2.0 spec out

Asir: I think this can be done in parallel, and that it goes along with part 3

Jeff: I think that we need to give priority to SOAP 1.2

Jonathan: how long do you think this will take?

<sanjiva> +1 to bring forward the old binding, appropriately subsetted per Jack's suggestion

Jacek: I would just subset our SOAP 1.2 binding and change the namespace

<TomJordahl> I agree with Asir, that the SOAP 1.1 binding shold go in lock step with part 3

<sanjiva> also +1 to keep that in the flaky wording of the old spec .. no infoset/component model stuff

Jonathan: so it would be easier to do it when part 3's stabilized

Arthur: what is the scope of the SOAP 1.1 binding? do we want to limit ourselves to WS-I compliant or do we want for example to support the SOAP encoding?

Tom: we're not supporting the SOAP encoding, so it should not be done

Yaron: the question we need to answer is: does our binding enable interop with existing systems?

<sanjiva> +1 for defining interop as per ws-i does

Yaron: if there's features that we can leave out that don't impact interop, then it should be OK

the question raised is what is the status of the WS-I work in relationship with this work

Jacek: I think that the WS-I represents the industry's consensus what should be interoperable

<yaron> +1

Philippe: I don't think that we should discuss what is interoperable

Jonathan: I propose to first focus on part 3, and then work on the SOAP 1.1 binding

<Scribe> no objections

HTTP Binding

Jonathan: Philippe's HTTP binding is now in part 3

I am accepting this as the status quo 85 and 110 are obsolete IMO

Jean-Jacques: there are issues that Hugo raised too

Jonathan: I added them

85 is about description of message parts

Philippe: it can be closed, but we still need to address HTTP headers

RESOLUTION: issue 85 closed

new issue about HTTP headers

Jonathan: issue 110 is in Philippe's text

RESOLUTION: issue 110 closed

<Scribe> ACTION: Part 3 editors to put text about Full URLReplacement issue back in the spec

Jonathan: issues 153 is Base URI for operation/@location in HTTP binding

Philippe: WSDL 1.1 was using the address of the service, and not XML base

<sanjiva> +1 to using service addr as base URI .. without that the practical usage of this will be zero IMO.

RESOLUTION: issue 153 is resolved by making the location relative to the address of the service

Jonathan: issue 154 Multi-part post in HTTP binding

Philippe: the proposal is to just follow XOP

Jacek: that means that we would specify how to use XOP in the HTTP binding

?

Philippe: yes, but I don't believe that it will add complexity as it will be used by the SOAP binding

I would recommend to tackle the issue for SOAP first, and then look at the HTTP binding

RESOLUTION: we will do a XOP serialization after we have looked at MTOM

Jonathan: issue 155 Out patterns in HTTP binding

Philippe: once again, I would first look at SOAP and then look at HTTP

Sanjiva: we may not want to address all patterns

Philippe: we need to look into the serialization of the body

SOAP binding

Jonathan: the draft and the issues list don't match very well

<plh-lap> jjm, the issue that needs to be added back in the draft is http://www.w3.org/2004/01/21-httpbinding.html#URIPath

Jean-Jacques: I was planning to send a draft schema for the binding to the group

I am missing the explanatory text

<plh-lap> Missing issues: http://www.w3.org/2004/01/21-httpbinding.html#SerializationForm, http://www.w3.org/2004/01/21-httpbinding.html#XSI

Jonathan: then we will discuss this next week

Jean-Jacques: my proposal will show what elements in SOAP we need to support

Jonathan: a lot of our issues about this look obsolete, so we'll be able to reconsider them

I am shooting for the end of our May f2f to have 0 issues we should be able to go to LC 2 to 3 weeks later

Sanjiva: some people asked me if we were going to do a SOAP 1.2 binding for WSDL 1.1

if a document was to be submitted, would the WG publish it as a Note?

<dbooth> Hugo: We should be careful about submitting the document to the WG, because then we'd have to take some time to discuss it. Perhaps you should make it a submission to W3C.

Jacek: once we publish WSDL 2.0, we will be saying that WSDL 1.1 is obsolete, maybe it's better for XMLP WG

Philippe: if it has to be published, it has to be done very soon

so that we don't send mixed signals

Paul: there should be a list of bindings available; I am not sure how and who should maintain this list though

Jonathan: we could list bindings we know about on our home page

Amy: the WG doesn't wrap up completely, does it?

there are errata to take care of

Sanjiva: I think that it is important to have such a binding because of the timing of WSDL 2.0

Jonathan: then I encourage you to either look for a way outside of this WG or propose a charter amendment

<Scribe> ADJOURNED

<alewis> hmmph. Czech isn't even south slavic. *laugh*