Web Services Description WG meeting
14 Sep 2006

Previous minutes

-> http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/att-0010/20060907-ws-desc-minutes.html Previous minutes

Tony: any objection to the previous minutes?

Resolution: minutes approved

Action items

<scribe> ACTION: [PENDING] 2006-03-30: Marsh to make XSLT improvements for RDF publication. [recorded in http://www.w3.org/2006/09/14-ws-desc-minutes.html#action01]

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

<scribe> ACTION: [PENDING] 2006-07-06: Glen to contribute some extension test cases. [recorded in http://www.w3.org/2006/09/14-ws-desc-minutes.html#action03]

(Glen is attending the Policy f2f meeting)

<scribe> ACTION: [PENDING] 2006-07-13: Roberto to produce an updated proposal for CR044. [recorded in http://www.w3.org/2006/09/14-ws-desc-minutes.html#action04]

<scribe> ACTION: [PENDING] 2006-07-20: Arthur to update "Proposed Part 1 Text for REQUIRED Extension Properties". [recorded in http://www.w3.org/2006/09/14-ws-desc-minutes.html#action05]

Arthur: link to this action item?

Jonathan: look at the minutes. there is a link to them from the home page

<scribe> ACTION: [PENDING] 2006-09-07: Marsh to propose workarounds for CR78. [recorded in http://www.w3.org/2006/09/14-ws-desc-minutes.html#action06]

Administrivia

Jonathan: Sept 28th will be about RDF Mapping issues
... we'll also try to do other business as well on that day

Tony: we also have questions from the editors.

Jonathan: thanks to Jean-Jacques for catching up. would like to refresh drafts at the end of september

CR026

Jean-Jacques: the commentator thought the text was clear enough. When I tried to change the text, I realize that the case was covered. Maybe we changed the text since then.

Arthur: it used to be "should" instead of "SHOULD"
... I was wondering it should be a MUST or a MUST
... it struck me as being inconsistent

Jean-Jacques: not sure if we can impose a MUST on the SOAP side

Arthur: if the WSDL sayd mustUnderstand="true", then it MUST be there at the SOAP level

Jonathan: looks like we need to reopen this issue

Arthur: the proposed fixed was to strengthen it. I believe it ought to be a MUST

Jean-Jacques: and the group agreed to clarify the SOAP level

Resolution: CR26: s/SHOULD/MUST/

ACTION: Jonathan to update the issues list on CR26 [recorded in http://www.w3.org/2006/09/14-ws-desc-minutes.html#action07]

ACTION: JJM to update the draft with new CR26 resolution [recorded in http://www.w3.org/2006/09/14-ws-desc-minutes.html#action08]

CR041

Jean-Jacques: Isn't this covered already by the last paragraph of 6.5.2?

It is an ERROR for a Binding Message Reference or a Binding Fault component's {http headers} property to contain multiple HTTP Header components with the same {name} property.

Jonathan: so it is placed in a less visible spot?
... Arthur was expecting to see the information. Did he miss it or are we inconsistent in the document?

Tony: Arthur commented on 6.5.6, and the response from JJM is in 6.5.2

Arthur: maybe I was reading in the description of the http header component
... the test is clear. I thought we agreed not to have an error, just "not valid"
... seems fine

Resolution: drop the editors action item on cr41

CR057

Jean-jacques: It looks to me like an xs:string already. (It's "type" which Is an xs:QName.)

"{name} REQUIRED. A xs:string whose pattern facet is..."

Jonathan: in 6.5.4, in the example, the name attribute has a qname

<Arthur> <whttp:header name="xs:QName" type="xs:QName"

<Arthur> required="xs:boolean"? >

Jonathan: it is just in the pseudo syntax

<Arthur> here is ed copy:

<Arthur> <whttp:header name="xs:string" type="xs:QName"

<Arthur> required="xs:boolean"? >

Arthur: the editors copy seems correct

Resolution: close action item linked to cr57

features and Properties at risk

Jonathan: we're missing Roberto and Glen
... I've got requests to look at the features/properties again. The official state is that we had two objections about them: remove them, add compositors
... at this point, Sonic is the only one left on "add compositors"
... the Director looked at those objections and disposed them. We did end up marking them at risk. The creation of WS-Policy is adding new information.

Jonathan: we also talked about trying to collect more evidence about their use
... everybody probably has a good idea now how they will use features and properties and policy
... Canon expressed in the past to have a way to specify MTOM without engaging a policy engine
... we'll wait before making a decision. any comments at this point?

Arthur: giving the progress on WS-Policy and the almost withdraw of the compositors objection, it seems that features and properties are superceded by WS-Policy. It's now confusing to people
... it complicates the spec
... given that Policy is in W3C and is richer

... given the current WS-Policy Attachment for WSDL 2.0
... let's drop them

Paul: I've been very careful in the past about this. Now, we see features and properties as competes with W3C WS-Policy and don't see a marketplace for features and properties
... we spent hours on this
... it's historical interest at this point

Anish: agree with the sentiment expressed. editors, how much work is involved in removing features and properties from the draft?
... Roberto said in the past it wouldn't be a trivial task

Arthur: I volunteer to remove them from part 1

Amy: one of the points that made in comparing features and properties and policy, features and properties has a more strictly defined syntax, so Glen would argue that policy might not fully supercede features and properties. However, if that is the case, it ought to be a suggestion made to the policy WG.

<Arthur> +1 to asking WS-Policy WG to consider current design of features and properties

Amy: from our prospective, TIBCO agree with the other commenters. there is not a good case to keep features and properties. we should let it go

<charlton> +1 to that

<charlton> (+1 tp having WS-Policy consider current design of features and properties - in particular features which features and properties handles well which are not yet handled in Policy)

Youenn: Agree with Paul, let them go. We want to have support for simple things like MTOM without engaging policy. Policy is too complex for our use case. One solution is unable SOAP modules to refer to SOAP features.
... for example, <soap:module ref="...MTOM"/>, even if it is not strictly speaking a SOAP module
... this is one proposed compromised. MTOM is an important use case for us. Maybe we would have pushed to have a dedicated syntax for MTOM

Arthur: another point, we will have a transitional period between WSDL 1.1 and WSDL 2.0, and WS-Policy works with both. We'll simplify the migration

Jonathan: if we do make a change to the spec and pull out something at risk, what about our interop schedule?
... if we decide to remove features and properties (or MEPs), I don't think we need to go back to last call
... we can refresh our CR and I don't think it will have a huge impact on our CR progress

plh f&p and mep were marked at risk, so no need to move back to LC. earlier, the director was unsure about the impact on the rest of the spec. if no impact, no need to go to LC. Youenn, why not create our own extension for MTOM today?

Youenn: a specific MTOM extension does not have the same scope.

<Arthur> MTOM should be included or enabled by the SOAP binding in Part 2

Youenn: it's possible to have such as an extension to MTOM

Jonathan: you want something in the REC document for MTOM?

Youenn: we had this capability with features and properties, we are reluctant to loose it

<Arthur> note that features and properties enables MTOM but you'd still need a spec for it

Jonathan: MTOM was still an extension even with features and properties, it didn't provide guarantee

<pauld> a MTOM extension for WSDL 1.1/2.0 sounds like a good topic for a member submission

<Arthur> btw, removing features and properties may improve the schedule

Charlton: I don't see what impact on the schedule it will have. I'm not aware of features and properties implementations

Youenn: our implementation have support for features and properties. Don't know about Woden. We could of course remove them

<pauld> less is more, we'll ship earlier without having to process test cases, comments and errata on features and properties, especially the problems we've had with inheritence

Arthur: Woden support features and properties, ie it is parsing them, but it's a little problematic: we store as a DOM element
... but the composition rules were also unclear

Youenn: our implementation is also partial

Jean-Jacques: if we were to remove features and properties, would it possible to have something else instead without going back to last call?

Jonathan: Youenn proposed changing the prose around the soap:module description. the difference between modules and features is fuzzy to me. An other possibility would be an extension attribut
... one thing that would be great would be to have a proposal on the mailing list

Youenn: we don't want to go back to LC!

<Arthur> -1 to another LC

Jonathan: if we go back to LC, will that be the end of the world? We look at 6/8 weeks before going back to CR, the schedule is not blocking us from moving out of CR. So I'm optimistic even if we go back to LC

<pauld> with our testing and implementations, could we go from LC to PR?

Jonathan: we might even skip going to CR and go directly to PR

Philippe: I don't think we can add MTOM as a WSDL extension and move forward, The WS-Policy WG might have a say in this

[Glen joins the call and Jonathan summarizes the situation]

Glen: I have nothing to add
... we certainly are not going to stay in the way. We would pull out of the "add compositors" objection
... the objection is still somewhat valid, but we're not going to stay in the way

HTTP binding at risk

Jonathan: this is not marked at risk.
... removing that would be more problematic

Arthur: Woden builds the components, but Axis 2 doesn't do anything with those

<pauld> "Serialization of the instance data in parts of the HTTP request IRI" is at risk in Part 2 as are "the Robust In-Only, In-Optional-Out, Out-Only, Robust Out-Only, Out-In, Out-Optional-In message exchange pattern"

Arthur: HTTP binding is useful for doing REST style, I wouldn't like to see it go

<charlton> +1 to Arthur - I would prefer not to see HTTP Binding removed for the same reasons

Tony: Mark Nottingham raised a comment against it

Jonathan: and Microsoft sent a last call comment saying we wouldn't implement it

<chinthaka> We do have an implementation in Axis2 based on HTTP binding but we haven't integrated that with Woden for stub generation so +1 to Arthur, as we see lots and lots of users of Axis2 interested in our REST impl based on HTTP Binding rules

Youenn: we don't have support to serialize HTTP messages. We would prefer to have it in the specification and not have an additional LC.

Chinthaka: Axis2 does implement HTTP binding and lots of people are interested in this.
... especially for RESTful style of interaction

<pauld> sees more benefit in resource centric approaches such as WADL for REST; WSDL 2.0 could be useful for people interested in POX

plh: I don't know what would be the position of W3C at this time. Yy own, personnal feeling is that we should remove the HTTP binding, since WSDL isn't the best to represent REST applications anyway. I do understand however why people are interested in our current HTTP binding since they don't have anything else around. I'd rather a resource centric approach however

Jonathan: but you would loose the capability to bind your service to SOAP and HTTP at the same time without the WSDL HTTP binding. WSDL and Resource-centric approach have a place out there.

Philippe: correct.

Arthur: Web Services are already getting complicated. we prefer to have a reduced number of specs and keep it in WSDL.

Jonathan: certainly not have strong support to remove it at this point

MEPs at risk

Jonathan: we only have In-Out, In-Only, and Robust-In-Only implemented. The other ones could be cut and putted into a Note
... specifically In-Optional-Out, Out-Only, Robust Out-Only, Out-In, Out-Optional-In

Amy: it wasn't only about the existing bindings.

Jonathan: do you have such a binding?

Amy: can't talk about it, but it is worthwhile to mention that we didn't put those extra MEPs for the SOAP/HTTP bindings.

Jonathan: do we need to go on a search now?

Amy: can we ask WG Members to bring search results by next week?

Jonathan: yes

Tony: I'm in favor of getting rid of MEPs that aren't used

Jean-Jacques: I don't remember what the tests for MEPs are. Do we have any?

Arthur: for Woden, there are just IRIs.
... we don't have enforcement for the moment.

Jean-Jacques: what did we agree to check? plan to compare the runtime?

Arthur: we do it for SOAP in a limited way
... between Canon and Axis2

Jonathan: might be hard to test MEPs at the runtime

Jean-Jacques: Canon will not add more MEPs to its implementation

Philippe: propose that unused meps be moved to a note, which can then be referenced by other specifications since they are yet unsupported by the SOAP/HTTP bindings. I don't like to recommend MEPs that can't be used by just reading the WSDL 2.0 specification.

Amy: the use case that I know of don't include all of the MEPs, but for the ones that I do know , having a Note is acceptable
... are they normative as they stand? Not sure if there is a meaning in having them normative anyway. I *think* we can support a Note but need to check

Jonathan: let's make a call for usage of MEPs

ACTION: ALL to come back with MEP usage (specs?) by next week [recorded in http://www.w3.org/2006/09/14-ws-desc-minutes.html#action09]

Issue CR079: Fragment identifier syntax not XPointer Framework-compatible

<TonyR> http://www.w3.org/2002/ws/desc/5/cr-issues/#CR079

Jonathan: a small tweak would enable us to be fully compatible with XPointer
... so far, we allow only a WSDL 2.0 XPointer part, which is against XPointer. Moving the wording would resolve the issue. [...]

<TonyR> ACTION: Jonathan to separate the canonicalisation from CR079 as a separate issue [recorded in http://www.w3.org/2006/09/14-ws-desc-minutes.html#action10]

Resolution: 79 is closed by adopting the proposal