- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 15 Nov 2002 10:03:31 -0800
- To: <www-ws-desc@w3.org>
-------------------------------------------------------
Wednesday 13 November
-------------------------------------------------------
Present:
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Macromedia
Youenn Fablet Canon
Steve Graham Global Grid Forum
Martin Gudgin Microsoft
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Philippe Le Hégaret W3C
(phone) Amelia Lewis TIBCO
Steve Lind AT&T
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Dale Moberg Cyclone Commerce
(phone) Jean-Jacques Moreau Canon
Don Mullen Tibco
Adi Sakala IONA Technologies
(till noon) Jeffrey Schlimmer Microsoft
William Vambenepe Hewlett-Packard
Don Wright Lexmark
Joyce Yang Oracle
Observers:
Francisco Curbera IBM
-------------------------------------------------------
09:30 Properties and features
Glen's "slice" [40].
Canon's change requests [41].
Amy's comments [42].
Tibco proposal (revised) [43].
Tibco SOAP email binding [44].
Scribe: Tom Jordahl
GlenD: Starts explaining history and concepts
... HTTP gives us request/response, but not every protocol does
... a feature is a specificaiton of a semantic
... Some features might do something (i.e. secure connection)
... Some features might pass data (i.e. user authentication, correlation)
... properties are part of features, that are typed
... so a feature spec has a description of what it does and the properties that implement it
... Example: Secure channel
[alewis: Security might be a slightly complex example. Features can express much less complicated sorts of things, which may be a great deal more composable. Examples of features (contained in the email binding example): message addressing, message correlation, mime content. Other feature examples: SOAP 1.2 Attachment (published).
[alewis: They would have to be designed for composability.]
GlenD: Example - Web Method feature
... Has a property "method", which apears in the GET for the HTTP binding
... Features can be required or not
JacekK: Thinks the proposal breaks layering
Discussion and questions about the proposal to clarify points
Gudge: Why does the WSDL processor need to know about the modules/headers?
[jjm: Not the processor, but application]
GlenD: if we put modules/features in the WSDL, then we can agree on how they are implemented.
[alewis: Note that SOAP modules (that is, features implemented as SOAP headers) only work if you're doing SOAP. If you're doing some other XML sort of stuff, described in WSDL, then you need to be able to specify the feature binding, which can't be to a module, since it isn't SOAP and there aren't any SOAP headers.]
[jjm: Jeff: I agree we could apply the same model/URI to SOAP body blocks]
[youenn: with meps and properties like messageInputType...]
[jjm: Jeff: At least in principle. Body blocks are undefined as far as the SOAP spec]
[jjm: is concerned]
Amy: Questions if we should be talking only about this proposal, or deciding between this and others.
Tom: What is the specific rationalae for adding the feature feature?
GlenD: We don't fully support SOAP 1.2 if we don't have it
[jjm: +1 to Glen]
[jjm: If we don't support features, we support only SOAP 1.1]
[alewis: +1 to support]
Marsh: Not clear if we couldn't support SOAP 1.2 in the SOAP binding, not using features.
Straw poll: Interest in pursuing features and properties
Yes: most
No/abstain: a few
[40] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0004.html
[41] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0080.html
[42] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0104.html
[43] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0149.html
[44] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0126.html
---------------------------------------------------------------------
10:30 Break
---------------------------------------------------------------------
10:50 Properties and features (continued)
GlenD: continuing to talk about features and properties
On the board:
<web:meth xmlns:web="featureuri"> (when properties were qnames)
<property uri="..."> (now that properties are named with qnames)
Issues:
1) scoping (binding/portType)
2) Property value expressiveness
3) composability
[alewis: What Glen is talking about allows you to further constrain *properties* (not features) (properties are contained by features), so that one can say, for instance, that an HTTP server only supports Content-Encoding: gzip and plain old stuff.]
[alewis: <wsdl:binding>
<wsdl:protocolBinding uri="anyURI">
<wsdl:featureBinding uri="anyURI" />
</wsdl:protocolBinding>
</wsdl:binding>
Probably an optional location="anyURI" attribute for both bindings. Note that this model effectively replaces transport="anyURI".]
GlenD: continues to describe details of how the features will work
[JacekK: what I meant by the binding extensibility proposal is Sanjiva's proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/att-0117/01-bindings-2002-07-24.html]
[jeffsch: But how does that relate to this "features" discussion?]
[JacekK: if we disallow features in portTypes, that Sanjiva's proposal would do the thing Glen wants]
[alewis: JacekK: Your interest, then, is to ensure that feature information always remains in the <wsdl:binding> tree?]
[JacekK: my interest is to ensure that portTypes stay at the abstract interface level]
[JacekK: we may want to introduce an intermediate level between bindings and portTypes. 8-)]
[alewis: JacekK: I stand corrected. *laugh* I agree, btw, to keeping portType abstract; it was a matter for discussion among the interest group.]
[JacekK: sorry, I must have missed that, what interest group?]
[jeffsch: Amy might mean the informal task force on soap features in wsdl]
[alewis: JacekK: Glen, Jean-Jacques, Chris Ferris, me, Don, and Youenn, who all worked to try to be able to present a common front on feature support.]
[JacekK: oook, thanks]
[alewis: jeffsch: I was trying to avoid the term "task force," because it implies that we have some sort of mandate ... we didn't/don't; we have a common, strong interest.]
[jeffsch: alewis: understood. thanks for clarifying.]
Paco: THere is a URI that defines features and protocol
[alewis: A little example of something that you could do:
<wsdl:binding>
<wsdl:protocolBinding uri="http://whatever.the.uri/is/for/soap/over/http">
<wsdl:featureBinding uri="http://www.example.org/compression">
<wsdl:propertyConstraint uri="http://www.example.org/compression/compression" type="tns:enumRestriction" />
</wsdl:featureBinding>
</wsdl:protocolBinding>
</wsdl:binding>
tns:enumRestriction is in the schema; it restricts the compression feature's compression property .]
... why not go all the way and define *everything* about SOAP (or whatever) and remove everything from the WSDL
(already an enumerated type, containing empty string, zip, gzip, compress) to empty string and zip only.]
[Marsh: jjm, paco is asking the big question about putting things behind a URI.]
GlenD: IT is useful to be able to specify the generic stuff about SOAP once
... AND parameterize the stuff the bindings care about.
[Gudge: tomj: Imagine I'm the king talking to Mozart: 'Use fewer notes'!]
[alewis: Make a reference to the things that don't change; specify the things that may change.]
[Gudge: amy: great summary]
[alewis: <-- has a notable facility for making complex issues simple, easy to comprehend, and wrong.]
[Don: .me or RFC1149??]
TomJ: how does adding features affect interop?
[alewis: I think it's possible to claim that what you can do with this is to move the failure zone from "send something, find out that the feature isn't supported," to "look at WSDL, don't bother."]
[alewis: I agree that this is going to improve interop.]
GlenD: This will have a positive affect on interop
[alewis: You get *explicit* specification of what is required, instead of having to build a mailing list and agree to it, over the course of two years.]
.. Specs will be avaialble for features, so everyone can implement them
[alewis: And still not know whether the service (or Joe Random Client from the dph toolkit) supports it. Feature support means that you get to know in advance, see what other people are using and supporting, and helps bring on convergence of support, plus the ability to support new and experimental features.]
Gudge: Why dosn't soap:header do the job for these things?
[alewis: Gudge: soap:header is only going to use for SOAP. The proposal should support additional types of binding properties, not just to modules.]
GlenD: for simple cases, header works, BUT the module URI indicates that you must understand the Specification and all it implies
[alewis: Do we have enough information to be able to move on to the part 2 issues?]
[Gudge: don't know]
---------------------------------------------------------------------
12:00 Lunch
---------------------------------------------------------------------
13:00 Properties and Features (continued)
Jonathan: how do we move forward? Any questions about the motivations/proposals?
Dale: those features will be added as part of the binding or toplevel features?
Glen: that's part of the question
Jonathan: sounds like it makes both ways but we may want to constraint it
Dale: substitute groups and extensibility options.
Glen: built in in the SOAP binding
Jonathan: [summarizing] there is an extensibility mechanism. based on URIs on specifications to describe the features. This URI would represent a certain kind of spec, described using the SOAP framework. It is another extensibility mechanism. You extend the value of the properties instead of extending the xml markup itself.
[alewis: It seems to me that it could be used to describe non-SOAP features as well, so long as the use the same sort of model as SOAP features.]
Jonathan: how would do this using the extensibility mechanism? do we need a specific extensibility mechanism?
[silent]
Gudge: there is any doubt using the extensilibity mechanism, using a namespace.... should we do it in the wsdl namespace?
[alewis: They aren't just properties. They're references to protocol bindings, feature bindings, and constraints on properties.]
Gudge: 3 points:
1) those new elts go in the wsdl namespace (soap:module, feature ...)
2) every feature define elts in their own namespaces.
3) mid solution: there is an other namespace used to define feature. not the wsdl namespace but an other (and unique) one.
Roberto: the mid solution is we define an extensilibity elt for them.
Jonathan/Gudge: s/we/somewhere/
Paco: what are the effects on the soap binding and others?
[alewis: A fairly significant number of things are, conceptually, shared among features, MEPs, and bindings. The identifier (URI) is one. It makes sense (to me) to put common things in the common namespace.]
Paco: talking about <> level of changes, can we clarify that? One would be extend the soap binding to support soap 1.2 features. An other one would be a generic mechanism to describe those uri extensions.
[alewis: Moreover: if some things are in the common namespace (the WSDL namespace), then learning/comprehension for new features/MEPs/bindings is reduced.]
paco: the 3 rd level is to put them in the core abstract level
glen: it might help to start at the bottom. we want some wway of being able to say soap module. If we get soap module, then do we want to tweak properties, if yes, then in bindings? and if yese, in the abstract features description. then we can decide soap binding vs abstract level.
jonathan: first one is fixing soap headers in soap modules.
glen: we need some construct like soap module. the understanding of the module implies that headers will show up at the appropriate headers.
jacek: soap allows defining headers outside modules?
glen: soap is silent on that.
jjm: today, modules are the combined syntax and semantics of soap headers.
glen: do we want to support the use case where you want to understand a specific header without understanding its module?
gudge: sounds like it is possible to have a feature without a module.
[alewis: It *is* possible to have a feature without a module. I thought that Gudge was suggesting that you could have headers without a module.]
jonathan: the convention is that the namespace of the feature can also be the uri of the module?
glen: yes
jonathan: so the syntax changes requires is to indicate it's no longer a feature but a module.
roberto: reading the processing model of soap, it doesn't say that you must have a module.
amy: sounds like features are tied to modules. seems to me that features don't have to be implemented and tied to a module.
glen: 2 separate questions: we add a soap:module to express the uri of the module and if it's required or not.
after that, do we want to remove soap:headers? and say you should do it in terms of modules.
[GlenD: <soap:module uri="http://my-security-thing" required="true/false"/>]
[alewis: What's the parent of soap:module?]
[GlenD: xmlns:soap = WSDL SOAP namespace]
[alewis: Is it wsdl:binding?]
[GlenD: ya]
[GlenD: though could also be binding operation]
the proposal is [whatever glen said]
[Roberto: I thought it would be wsdl:operation (within binding)]
allen: is there gonna a wsdl:module?
glen: no modules don't make sense outside of soap.
straw poll: shoud we add a soap:module in order to indicate in the binding for this thing.
14 for
nobody against
a few abstention.
Consensus: we add soap:module in the spec.
Next layer: do we want to remove soap:headers?
glen: a module that there is some semantic about a particular header.
glen: if you assign a uri to a header, you still need to have some documentation about this header.
gudge: a module has a qname. I think it's perfectly reasonnable to understand one header out of 60.
glen: then you should have a module for it.
gudge: I want the ability to just say: I accept this header, because that header definition right now has no soap 1.2 module.
microsoft published headers (and still does) without soap 1.2 modules.
roberto: and the processing model does not depend on modules being defined anyway.
gudge: can you define headers outside a module?
amy: soap says yes.
gudge: not clear to me.
jonathan: given that soap is not enforcing to play by the module rules ...
[silent]
[long silent]
jonathan: straw poll?
jonathan: should we encourage the use of soap modules?
roberto: the xmlp could have noticed that in their spec...
jacek: if they noted this issue...
straw poll: should we remove soap headers?
2 for
3 for
10 against
objection?
glen: not happy with it.
jonathan: should we vote?
glen: if we have clarification from architecture or xmlp, can we revise the decision?
jonathan: yes
do we have a minority opinion?
-> consensus
jonathan: next layer?
glen: we should talk about properties with respect to modules.
glen: what do we want to support? what lvel of richness?
paco: example?
jonathan: and next layer?
glen: next layer is: once you have a way of defining properties, abstract features.
jjm: and MEP?
glen: kind of a separate issue.
jjm: let's keep that in mind for latter then
glen (on the whiteboard):
<soap:module uri='http://my-security-thing" required='true'>
<my-security-cipher>BLOWFISH</>
</>
amy: doesn't seem adequate. other proposal was using a restriction of the type of the property, embedded inside the xml schema.
[alewis: <propertyConstraint name="whatever" type="constrainedType" />]
youenn: yes, why now reusing the schema definition. we can validate using the schema that way.
youenn: (on the whiteboard)
gudge: <property name='foo' type='bar'/>
youeen agrees
youenn: if you want to allow blowfish and dsa, it's better to have the type.
paco: you have a generic property, everytime you define a setrvice, you have to define the schema type for it?
youenn: if you know the module, you know somehow the schema
gudge: so paco, you're suggesting to come up with a new language to define those properties? doesn't seem right.
glen: and soap says that you must use xml schema.
paco: having to define a type for properties seems overkilling
[alewis: I like the name "propertyConstraint" because it makes it clear that this is not a property definition, it's simply a reduction of the range of permitted values for a particular property.]
[GlenD: What we're suggesting is that the element name == the property name (assuming property=qname)]
paco: you just skip the body/value of the property.
[GlenD: i.e.]
[GlenD: <mySecurity:cipher>VALUE</mySecurity:cipher>]
[GlenD: - or -]
[alewis: I agree with Gudge and others: we should *not* be in the business of defining Yet Another Schema Language. (almost certainly badly)]
jonathan: but you would still have a way to define enumeration? and minVal/maxVal?
[GlenD: <mySecurity:cipher constraint:type="myConstrainedType"/>]
gudge: if the type of the property is duration and I want a fixed range, how would you do?
[GlenD: (where myConstrainedType is assumedly an enumeration restriction)]
paco: let's concentrate on simple cases. enumeration are part of it.
jonathan: (on the whiteboard) <algo type=''>BLOWFISH</>
[alewis: Gudge: agreed. We can specify content of things we define; content of extension elements is up to extension authors (and we can't recognize it as the name of a property).]
glen: would be <wsdl:property uri='...algo' type='qName'>value?</>
[discussion <property /> vs <"propertyName" ../>
]
glen: we leave up to the editors to come up with a syntax
<wsdl:property uri='...algo' type='qName'?>value?</>
amy: should be "propertyConstraint" instead of "property"
jonathan: will be considered by editors first
[kevinL: I like the first one better, it avoids the confusing that we are redefining property here]
[kevinL: by first one, I meant "propertyConstraint"]
straw poll:
<wsdl:property uri='...algo' type='qName'?>value?</>
12 for
no one against
next step
glen: we can hit the use of transport uri vs soap binding
http://www.w3.org/2002/ws/desc/2/06/issues.html#x28
-> http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html
jonathan: start of the issue. might be other emails.
[alewis: soap:binding]
glen: proposed solution is ...
s/transport/uri/
(on the whiteboard)
[alewis: Oh, yuck. Why are we only solving this for soap?]
<soap:binding uri='http soap binding uri'>
<algo type='..''>BLOWFISH</>
</>
[alewis: I don't like this proposal at all.]
[alewis: Earlier discussion moved more in the direction of something in the wsdl namespace, that would identify the protocol binding and the composed features, at least.]
paco: i thought the transport was specified in the port
glen: soap:binding goes in wsdL:binding
[alewis: It looks more like:
<wsdl:binding>
<wsdl:protocolBinding uri="anyURI">
<wsdl:featureBinding uri="anyURI">*
<wsdl:propertyConstraint />*
</wsdl:featureBinding>
<wsdl:propertyConstraint />*
</wsdl:protocolBinding>
</wsdl:binding>
]
gudge: why are we changing from transport to uri?
glen: symetry with soap
the uri is the uri of the soap binding.
jonathan: we're changing the name and soap:property is available inside.
gudge: soap:module is inside wsdl:binding?
amy: I don't like the proposal. we are solving the problem for soap only.
we're talking about binding to protocol, and binding to features. and it's for soap only.
glen: soap:binding have a well understood structure. wsdl:binding don't.
[youenn: http://lists.w3.org/Archives/Public/www-ws-desc/2002Aug/0009.html]
glen: i would like to have abstract features, that you can indicate the http binding of wsdl does some of those features. on the other hand, I don't want to have an explosion of wsdl:binding
paco: I thought that the module in use depends on the transport.
[...]
glen: does transport exist outside our soap:binding? I don't think so.
paco: are we specifying the transport in 2 places (binding transport and port location)?
jacek: the address i not specific to a transport.
glen: so paco's point is to move the transport binding specific stuff from the binding to the port.
glen: does it address amy's concern?
[alewis: The transport in use changes *lots* of things inside wsdl:binding. I don't see how we could move all transport-specific information out of the wsdl:binding tree successfully.]
paco: [summarizing]
we specify the uri transport inside the soap:binding and it's not multiple protocol mechanism.
[Gudge: alewis: does it change things? Or add things?]
I suggest we specify inside the port
amy: my issue is that it strikes as ending as a repetition of information or as a blocker to create a generic format. you can't successfully move the transport outside the binding.
you can't tell from the scheme, which protocol binding is actually in use.
glen: [summarizing]
<binding uri=''>
...
</>
you can use it for soap or something else.
with the uri, you would know if it's soap or not.
suggests amy to write down her proposal here
glen: we need to specifi properties with at least the soap:binding. would be good to specify them for any binding.
jonathan: so amy, would you object to the current proposal?
amy: yes. restricting inside soap:binding is going to create either an error producing redundancy or prevent us from creating generic ones.
glen: they are something within soap that are soap specific.
glen: others are related to soap but are transport dependent.
[alewis: How to solve for SOAP is, in my opinion, the wrong question. How we are going to handle the problem in general is the question that I think solves it generally, and for SOAP as well.]
glen: don't care where they are, as long as they exist and they make sense.
amy: seems to me that soap:binding should not contain general utilities, or how are we going to define for other protocols?
[GlenD: <port location="http://endpoint" binding="http://soap-http-binding">
<propertyConstraint...>
</port>
]
[GlenD: <port wsdl-binding="binding1" protocolBinding="http://soap-http-binding">]
[JacekK: what about:
<port binding="binding1">
<soap:address>...</>
<soap:transport>...</>
</>
]
gudge: so the binding would be a binding to a messge format. and the rest would be done at the port level.
[alewis: I don't think that you can know the set of MEPs that can be supported without knowing what protocol/transport context you are in.]
[alewis: In general, the abstract state machine is defined by a MEP, and merely modified by the binding (typically decorated).]
[GlenD: agreed, but you know that because it's in the <port>]
[alewis: GlenD: I don't think that you can define a binding independent of transport/protocol, which is the point, presumably, of moving the transport stuff into port. It looks like a nice solution, but I don't think it can actually work, in implementation.]
glen: the first simple proposal is soap:binding uri= ....
and that's inside a wsdl:binding and each wsdl:binding will have one of those.
[DaveO: Glen, are you arguing for protocol+binding pairs? Like HTTP-SOAP-POST, or HTTP-SOAP-WebMethod?]
[GlenD: Dave: Not really, no - I'd rather not.]
ACTION: Glen to write the 2 proposals and send them to the list.
jjm: am I hearing correctly that a proposal for separating the message format from the protocol binding? I think that's a good idea.
[GlenD: +1]
the wsdl:binding do the message binding and then do the rest somewhere else.
jonathan: other action items for higher layers?
glen: next layers:
within a soap binding, not tied to a particular transport, smae thing for properties.
if you're running soap, do we want to support the same kind of property constraints?
this feature needs to be supported, ...
web methods or correlation are examples
bindings implements features and modules implements, so why do you need it in soap binding?
gudge will ask specific questions on Glen's proposal
---------------------------------------------------------------------
15:00 Adjourn early due to early departures by many members.
---------------------------------------------------------------------
Postponed items:
Part 2 issues dependent on properties and features
- Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [45].
Jean-Jacques proposal at [46].
Jacek's addendum at [47].
- Issue 28: transport='uri' [48]
- Issue 6a, 41: HTTP Binding Issues
Jeffrey recommends no change [49].
Sanjiva is mulling this over [50].
[45] http://www.w3.org/2002/ws/desc/2/06/issues.html#x2
[46] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0050.html
[47] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0056.html
[48] http://www.w3.org/2002/ws/desc/2/06/issues.html#x28
[49] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0102.html
[50] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0067.html
Work items awaiting further work on the abstract model.
- BindingType proposal from Kevin [51].
- Issue 25: Interaction between W3C XML Schema and SOAP Data
Model. Gudge explains at [52], Roberto's options at [53].
[51] http://lists.w3.org/Archives/Public/www-ws-desc/2002Aug/0009.html
[52] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0186.html
[53] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0071.html
Raw IRC log: http://www.w3.org/2002/11/13-ws-desc-irc
Received on Friday, 15 November 2002 13:04:00 UTC