- From: Philippe Le Hegaret <plh@w3.org>
- Date: 26 Feb 2003 12:01:02 -0500
- To: public-ws-pnf-tf@w3.org
Participants: Jean-Jacques (scribe), Amy, Philippe, Glen, Steve, Colleen, Don, David, Sandeep Regrets: Sanjiva, Paco, Youenn Missing: Jonathan, Chris Previous minutes: http://lists.w3.org/Archives/Public/public-ws-pnf-tf/2003Feb/0047.html Agenda: http://lists.w3.org/Archives/Public/public-ws-pnf-tf/2003Feb/0051.html Glen: extra 30 minutes? (no objection) Glen: 1) Indicate a particular feature is provided 2) Indicate a particular feature is required 3) Indicate a particular property constraint Considering that each of these things may be scoped in various ways (service / portType / operation / binding), does that about cover what we need to do here in WSDL? Glen: anything else missing? the list should enable us to quickly evaluate solutions. Don: sounds good; but the group will also be interested in knowing why the standard extension is not enough. Glen: agree. Don: pick one feature, do it side by side Amy: lower barrier and provide modularized property set Glen: like amy's example, however properties critical for implementing, not describing Amy: disagrees, you find it in the choreography spec (WSCI, BPEL) Glen: they define a slot for correlation id. they wouldn't say correlation id is "5", woudln't make sense. content id or web method example might be better don: the better the demonstration the better the example Glen: no WSDL binding today to declare using SOAP-Response MEP and Web-Method feature set to GET Amy: look also at scenario 5, to be less SOAP centric? Glen: this particular property goes into this particular MIME header? Amy: yes, essentially Amy: SOAP and HTTP would in my view restrict the discussion to SOAP Glen: however, SOAP and HTTP well understood Amy: agree, as long as not restricted to SOAP and HTTP Glen: are people comfortable with expressing features at abstract level? should show this through examples Don: simple and easy to understand examples Glen: have wide range of scenarios already. some of them require WSDL descriptions. proposal to dive in and to that? Glen: first class feature or property attribute. S7 interesting, shows given propertyConstraint affects more than one feature. several proposal suggested already. maybe do by email, rather than IRC don: agree Glen: so, now, go into the scenarios in detail and offline propose syntax. S2 good example. however, too complex. could reuse my earlier security example (not certificates, just raw HTTP authentication) sandeep: [...] Glen: anyone having problem with feature at the abstract level? [assent] Glen: abtract security feature. implemented by concrete feature either through module or underlying protocol Sandeep: so would provide secure channel glen: yes Sandeep: abstract feature would be expressed by namespace, name/value pair. how it gets mapped would be independent Glen: yes. properties in SOAP 1.2 used to be qnames. however, now they are URIs. so, could do same thing, but syntax would be different. some fairly good suggestions have been made regarding specifying property constraints. unanswered question: where can property constraints go? e.g. you might want to set the value of a property just for the inbound message Sandeep: might also want to restrict value to a string of a certain length Glen: don't think property constraints should be within features, since properties might be shared Amy: suggest have constraint attribute and value attribute, which would contain either value or token list Glen: understand optimisation; however, two separate issues Amy: probably right Glen: that deals with typing. where to they go? one container element to contain properties (whether at service, portType, etc. level). properties are somewhat orthogonal to features (can be shared by features). non-repudation feature would refer to a user name, which would be a property defined by an authentication feature Amy: how would you refer to an element? Glen: if using WSDL extensibility? Amy: no, if want to refer to property... one property set to the value of another property (probably advanced function). qnames as property names are analog to pointers in programming languages, not URI David: why? Amy: URIs have been abused Glen: infoset value space of particular xml tree; virtual URI space of properties, already defined by SOAP. URIs have benefit of making properties compliant with semantic Web (policy assertions, etc.) David: and policy assertions [David's cat agrees] Don: if can share properties between features, would you need to scope properties to features? Amy: no Glen: up to the spec writer David: there's a corresponding TAG finding Don: if property has same URI and default value, and want to override default in second feature only? Glen: cannot do this. properties must be defined uniquely David: wonderfull description; need to see it written Glen: need to test SOAP 1.2 endpoint on inbound flight. maybe on way back David: could volunteer, but would be difficult to recreate your nice wording Glen: 1) crisp definition of choosen scenario 2) syntax proposal by Thursday EOB PST 3) select best proposal by Friday EOB PST Glen: one or two examples? David: 1 Amy: 2 David: 2 if enough volunteers Glen: 1st example: security example Amy: if 1 example only, need properties Glen: would then suggest Web Method feature Amy: hum... don't understand WebMethod Don: might have pushback; why not done by SOAP binding itself? Amy: share concern Glen: well, done generically, since might want to tweak the abstract feature Jean-Jacques: maybe also use WebMethod to set the method for HTTP binding, not just SOAP binding Glen: yes, could set GET at abstract level, and HTTP binding would infer that the HTTP method is GET David: follow the REST guidelines? David: would separate Web Method from REST Glen: agree, not talking about REST Glen: not sure the WSDL extensibility mechanism would suffice. talking about framework around extensibilty mechanism. akin to SOAP enveloppe David: it's a framework too Glen: shall we go for this one as well? Jean-Jacques: sounds good to me Glen: need 3 volunteers. description with a) extensibility and b) properties and features. volunteer to write up the scenarios. need volunteers to grab each one and propose syntax Jean-Jacques: could spend some time but what to do with extensibility? Glen: could do: <soap:binding> <webmethod>GET</webmethod> </soap:binding> Glen: anyone else? Amy: don't quite like what I know of WebMethod. might do security stuff; but need starting point Glen: will provide starting point. continue by email ACTION: Glen to decribe the scenarios we're focusing on ACTION: Jean-Jacques to help out with writing them up ACTION: Glen to make dinner reservations for Sunday night
Received on Wednesday, 26 February 2003 12:01:03 UTC