- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 4 Feb 2004 09:49:30 -0800
- To: <www-ws-desc@w3.org>
Web Service Description Group
Minutes, FTF meeting 29 Jan 2004
Bedford, hosted by Sonic.
irc: http://www.w3.org/2004/01/29-ws-desc-irc
Present:
David Booth W3C
Michael Champion SOftware AG
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Tom Jordahl Macromedia
Philippe Le Hégaret W3C
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Adi Sakala IONA Technologies
Jerry Thrasher Lexmark
William Vambenepe Hewlett-Packard
Umit Yalcinalp Oracle
Observers:
Hugo Haas W3C
Phone:
Allen Brookes Rogue Wave Software
Amelia Lewis TIBCO
Kevin Canyang Liu SAP
Yaron Goland BEA Systems
Jean-Jacques Moreau Canon
Sanjiva Weerawarana IBM
Prasad Yendluri webMethods, Inc.
Regrets:
Youenn Fablet Canon
Jacek Kopecky Systinet
Ingo Melzer DaimlerChrysler
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
scribe: Arthur Ryman
-------------------------------------------------------
Thursday 29 January
-------------------------------------------------------
09:00 Attribute styles "at risk?"
- Word from GGF that they don't want attribute styles [10].
- Issue 103: Proposal for combining the two attribute operation
styles to one [11, 12]
[10] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0086.html
[11] http://tinyurl.com/ysgl#x103
[12] http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0164.html
Jonathan: Are there any objections to dropping them?
Umit: Yes. They are useful outside of GGF requirements, so why
remove them? They are a good example of how to extend
styles.
Glen: Could they be put in primer?
Jonathan: Sounds too advanced for primer.
Glen: Should not be in spec.
Arthur: IBM position is to support GGF spec WS-ResourceProperties,
etc., so there is no need for this function in the WSDL
spec.
Jonathan: There is significant cost in leaving it in our spec.
Umit: We still need an example of using styles.
Philippe: HTTP style is an example.
Jeff: The argument that another group (GGF) is doing it isn't
valid. Why did GGF duplicate our work?
Bijan: Not a valid argument since GGF was the group that proposed
it.
Jeff: Steve Teucke advised us that GGF was not interested in the
"weakened" support this group was adding and that they
were proceeding on their own.
Dave: The GGF did a lot of work that was more than this group
did, i.e. this group only did a subset.
Jonathan: Umit, do you still disagree to pulling it out?
Umit: OK, I agree to pull it.
Bijan: What about a Note?
Jonathan: That can happen at any time independently of the WG.
Jonathan: Resolved to pull attribute styles.
Jonathan: Issue 103 is now irrelevant so I propose to close it.
RESOLUTION: Remove attribute styles.
RESOLUTION: Close issue 103 as irrelevant since styles are removed.
-------------------------------------------------------
09:30 Features and properties "at risk?"
- WSChor statement [13]
- Issue 108: properties and schema languages other than XSD [14, 15]
If properties remain, we need to discuss requirements for a
solution to this issue and recruit a champion.
[13] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0066.html
[14] http://tinyurl.com/ysgl#x108
[15] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0006.html
Jonathan: Support for F&P seems to be dropping. Can we reaffirm our
desire to keep F&P? Also need to discuss message from
WS-Chor about F&P.
Glen: WS-Chor needs F&P so ensure compatibility betweens multiple
nodes in a business process.
Jonathan: Aren't F&P isomorphic to extension elements?
Glen: Not exactly. Properties augment nodes with additional
information.
Jeff: WSDL can be used to declare properites used in choreography.
Why do we continually discuss removing F&P?
Jonathan: There is still lack of understanding on the text in the spec.
Need more clarification in the spec.
Jeff: Compositor proposal should clarify F&P.
Umit: Compositors are used in useful examples.
Jonathan: Are compositors necessary for F&P, i.e. accept both or
neither?
Glen: Compositors are great. Very useful.
Dave: Similar constructs are used in other languages.
Glen: e.g. how to determine which operation is invoke, e.g.
SOAPAction, QName of Body element
Paul: The key use of properties is that provide a policy framework
Glen: True, but F&P goes beyond policy frameworks since it also
covers parts of the runtime.
Paul: There are other ways to add metadata, but the F&P approach
is attractive
Philippe: Compositors are not part of the WSDL requirements, so you
are proposing to add this
Sanjiva: Where else are we using Features?
Glen: We are planning to add the Operation Name feature. e.g. if
two or more operations produce identical messages, how do
you differentiate them and identify the operation.
Jonathan: Umit, please present your proposal.
[umit: the presentation is in http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/att-0189/CompositorF2FPresentationForWSDL.pdf]
Umit presenting: Compositors for WSDL 2.0
Sanjiva: why do we need compositors when we have had trouble finding
use cases?
Umit: Compositors allow F&P to be applied to more situations and
therefore more useful. e.g. the Choice semantics cannot be
otherwise expressed
Glen: This allows richer semantics on how properties are combined
Roberto: We found we needed compositors to apply F&P to real
situations
Bijan: Are compositions names (e.g. with a URI)?
Umit: Not at present, but we could do that.
Sanjiva: In the Pseudo-Syntax, but does a specific binding, i.e. soap,
show up?
Glen: That was a common case but we could replace the specific soap
module element with a general extensibility element. An
example of using soap modules would to say that several
security modules but only one at a time.
[TomJ: You can currently get all and zero-or-more with the current
required syntax. Compositors are adding one or more and
choice.]
[jjm: ... and also nesting.]
Glen: In some cases choice can be expressed with appropriate
designed properties
Umit: Compositors give you the power to compose arbitrarily
designed properites and features
Sanjiva: Is the uri on the compositor element an extension point? If
not why not use four elements with better names, e.g. <all>,
<choice>, <zero-or-more>, <one-or-more>
Umit: Having the four elements makes the schema more complicated
Sanjiva: Is the uri extensible?
Umit: Yes, it is extensible.
Tom: the example on Slide 12, Feature Configuration using
one-or-more, make what was once simple very complicated
Glen: the example may not be good. A better example is to specify
the type of authentication required by an operation, e.g.
X.509, Basic Authentication
Tom: Example on slide 13 looks overly complex. why wrap a
compositor around a single property
Umit: Because in general there can be more than one feature
Tom: There is far too much complexity in compositors for them
to be easily implemented on small devices
Roberto: Compositors allow the composition of indepently developed
features.
Bijan: Compositors are very expressive, they are not primarily for
compensating for poorly designed feaures
[end of presentation]
10:40 Break
11:05 Features and properties (cont.)
Glen: We should be done with discussing about dropping F&P since
we have gotten support in the past
Jonathan: There was dissent at the last F2F about F&P
[alewis: Doesn't that imply that it needs to be clarified, not
dropped?]
Jeff: While it's in the spec it is valid for us to work on it,
e.g. the compositor proposal
Glen: F&P is useful on its own as is. Compositors make it even
more useful.
[jjm: R116: The description language MUST allow describing abstract
policies required or offered by Services. "The description
language MUST allow describing which SOAP features are
offered by or required by an Operation or a Service."]
jjm: R116 says we should support abstract policies, so we have a
requirement on the books.
Dave: Compositors are directly coupled to F&P. I am concerned that
we may need even more technology to make F&P real. WSDL 2.0
needs to focus on other areas first, e.g. bindings, meps.
[alewis: horsefeathers]
Dave: F&P makes WSDL 2.0 too complex and diverts attention from
the core problems. BEA position is that we should be
addressing the other areas to complete WSDL 2.0.
[alewis: TIBCO completely backs Glen/Sonic's statement on the
inclusion of features and properties]
[jjm: +1 to Glen and Amy]
Glen: Disagree that F&P is not core and too complex
[TomJ: I agree with Dave O's statement that there are much better
uses of our time.]
[sanjiva: +1 to TomJ :)]
[jeffm: -1 to sanjiva and tomj :-)]
[jjm: ;-)]
Glen: There are other solutions, like WS-Policy, and if its
authors contributed it to WSDL then we would be done
Arthur: Since the requirement specifically addresses SOAP, why not
put this in the SOAP binding and perhaps arrive at a simpler
design?
Glen: The design would not be simpler and leaving it in the core
language makes it available for broader usage
Sanjiva: Isn't the F&P information more useful outside the scope of
WSDL? i.e. F&P is metadata which may be useful in other
contexts.
Amy: The scope of this WG is WSDL and until the other solutions
(WS-Policy) are offered RF, then we are obligated to work
on a solution
Jeff: Compositors are basic computer science and needed to
express real world situations so it should be in the
foundation. There is no universally useable spec so this
WG should provide a solution.
Dave: There is a lot of overlap between F&P and WS-Policy and we
are asserting that if WSDL provides this function then
vendors will implement it. I challenge that assumption
and feel that F&P will put WSDL 2.0 at risk. There is not
a consensus that adding F&P is the correct thing to do.
e.g. it took a very long time to develop WS-Policy and the
work is ongoing so doing a similar job here will also take
a long time
[alewis: It was accepted into the specification at the March 2003
face to face, after about six months of task force work.]
Glen: We have already done a lot of work on F&P so the work that
exists already helps solve the requirement. The mission of
this WG is to define metadata to describe Web services
and we need to be able to describe arbitrary extensions,
this is a major contribution of WSDL 2.0
Sanjiva: It seems that a major motivator for F&P is that WS-Policy
is not available in RF terms
[jeffm: WS-Policy is not available under any terms]
Sanjiva: We have just requested a schedule extension and it is
likely that WS-Policy will be refined in that time frame
and be made more widely available
[sanjiva: hahahahaha ;-)]
Amy: Point of Order: Should discussion of WS-Policy be ruled out
of order since it is not available on W3C terms. And should
representatives of those companies recuse themselves from
discussion?
Philippe: The IP issues are not a concern. Also I will [not] support a
further schedule extension.
[alewis: ARyman: based on the value of licensing revenues to the
companies represented.]
[jeffm: DaveO has claimed that there has been lots of work on the
WS-Policy has been occurring. That is certainly not
avalable to anyone but the spec authors. I'm not saying
it should be, anymore than any internal Oracle product
specs are available to the public.]
[jjm: +1 to sanjiva on this point!]
Paul: Interoperability is a major requirement of Web services so
we need to have an interoperable way of expressing F&P and
Policy info.
[sanjiva: Hypothetical question to Glen: If WS-Policy were submitted
to an alternate standards body, say OASIS, would you want
to stop the f&p work here or still continue it?]
[DaveO: Jeff, I'm saying that work has been ongoing. So adding the
roughly equivalent stuff to WSDL will add the same kind of
schedule. ]
jjm: This is the fourth time so I wonder why the requirement has
not created an issue before.
[alewis: It's already been worked on, Dave. Since March 2003, when
it was accepted, and approximately six months before in
the task force.]
[jeffm: But we are not proposing adding roughly equivalent stuff
-- unless of course you guys in the smoke-filled room :-)
have performed some drastic surgery]
jjm: We do have a schedule constraint. The bulk of the proposal
could be in the spec by next week.
[jeffm: If we were going to boil the policy ocean you might be
right, but we're not]
[sanjiva: Response to JJM: The requirements have been there but I
personally felt we had met them by having F&P. This new
compositor stuff didn't come to existence until the last
month (or was not surfaced until this week or so). So I
find it hard to accept that this stuff is designed to
satisfy that requirement.]
Umit: I agree with jjm. Priority is in the eye of the beholder.
Dave suggests that work is continuing on WS-Policy and
that we should not discuss it, but we have not had access
to that work.
Glen: In reply to Sanjiva, I feel strongly that F&P should be
core to WSDL even if WS-Policy was RF.
[sanjiva: Reponse to Glen: So you are saying that no matter what
we would ignore WS-Policy and put similar function here?
(Clearly the current published policy spec and this work
does overlap.)]
[jjm: jjm also said requirements about features and policies
have been sitting quietly for 2 years (almost), without
having been objected. Also, if need to cut work, could
stop other items instead.]
[GlenD: Not really, Sanjiva. I'm saying that IF the policy work
was contributed to this group, that would be fine,
potentially with some work.]
Jeff: There is other work going on (OASIS XACML). The work on
F&P has broader applicability. The OASIS and WS-Policy
work is more aimed at enterprise applications.
[sanjiva: Then what Glen? I don't understand your position .. its
"core" to WSDL, but if its in OASIS you wouldn't stop it? ]
[GlenD: But the functionality should be IN wsdl.]
[sanjiva: So its either WSDL WG or nothing? OK now I understand your
position.]
[GlenD: It's like saying "wsdl shouldn't do bindings". It's core, imho]
[sanjiva: No is there an alternate binding thing?]
[alewis: +1 to jeff]
Jeff: I also feel it is disingenuous that companies that have
product plans based on competing specifications are
blocking the work of this group.
Tom: My company has no plans to develop competing specs and I
agree with Dave that this will take a long time.
Bijan: We have a requirement to support SOAP and there is
interest from WS-Choreography.
[TomJ: But schedule isn't my primary objection, unnecessary
feature creep and complexity are my main problems]
Jonathan: We can meet the SOAP requirement without a generalized
WSDL language feature, i.e. adding it to the SOAP binding.
The meets minimum solution does not require a general
mechanism.
Glen: Disagree. We need to support the SOAP extension mechanism.
Dave: This is the issue of what is in scope. I would like to
consider what is the minimum we need for success. Where
do we draw the line?
Dave: We learned a lot from WSDL 1.1, e.g. we feel the syntax
is too hard. Or the 80% case should be the default and
be easy to specify in WSDL. BEA position is that the 80%
case needs to be very simple and we feel F&P is too
complex and at present unbounded.
[jjm: Not, not me, not the semantic web]
[jjm: DaveO, I don't think it's fair to compare compositors to
the semantic Web]
Sanjiva: Concerning Jeff's comment that we are blocking progress,
I disagree. WS-Policy is more flexible than the F&P proposal.
[DaveO: jjm, my point was that I don't know how far the scope
goes. I don't know where to stop on this work.]
[sanjiva: IBM/MSFT statement of intent to give WS-Policy under RF
Terms: http://news.com.com/2030-1069-5079712.html]
Sanjiva: Concerning Glen's comment that F&P is core, I disagree.
Things like security are about how a service is deployed.
[jeffm: A statement of intent is worth the bits it is written on.
It is always subject to modification based upon "changed
business" conditions]
Sanjiva: Concerning Amy's IP concern, there has been a statement
intent to offer WS-Policy under RF terms.
[jeffm: Could we please not reduce the arguments to dueling press
releases]
[GlenD: lol]
[GlenD: (ok, not ol really)]
[jjm: Sanjiva, would you (your company) consider submitting
WS-Policy to W3C?]
Umit: On lessons learned from WSDL 1.1, you cited the header
problem which is an excellent example of F&P.
[sanjiva: I would but I don't get paid enough to make those kinds of
decisions. ]
Umit: Other aspects, e.g. security and reliability are a big
concern now.
[pauld: Other forms of policy which could be considered
as part of the interface: idempotency, safeness, etc]
Jonathan: Vote?
Glen: Not ready yet. Can we remove the F&P at risk issue?
Jonathan: (with his Microsoft's hat) I'd like to get some experts
at Microsoft before having a clear technical position.
Jonathan: Let's close the compositor discussion for now and entertain
further discussion later as well as counter-proposals.
[plh-ws: Jonathan: objection to the status quo? i.e. keeping FnPs in the spec?]
Jonathan: Since the requirement exists and there is WS-Chor
interest and we should not be altering the a lot, I
propose we leave F&P in and not label it at risk.
Dave: I would like to label it at risk. BEA position is to
remove it from spec.
Sanjiva: IBM objects to it but agrees to leave it in.
[Issue 108 deferred.]
12:10 Lunch
scribe: Tom Jordahl
-------------------------------------------------------
13:00 WSDL structure issues
- Issue X: BEA Simplified Syntax Proposal [16]
Overview and initial thoughts.
[16] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0071.html
Chair: Wants to touch on the BEA issues, simplified syntax
and headers/body
DaveO: Simple syntax - its hard for humans to write WSDL documents.
Thinks that is important. WSDL first implementations are
going to be widespread. How can we make the syntax more
straightforward? 3 proposals put forth by BEA. First:
include things by value instead of by reference.
Jonathan: Points out that Sanjiva made a similar inline proposal 9+
months ago
Glen: Might not have reached proposal stage, but was involved in
rolling up binding atrributes
All: Discussion of how an inlined syntax would affect the
component model.
Arthur: Would make WSDL more like Schema - it is a simplification.
Umit: How does it changes the component model? We need to think
that through.
Roberto: Not convinced this is the 80% case. Creates problems with
tools and users when changes or additions are needed.
[WilliamV: +1 to what roberto said]
Dave: We want to hit the 80% case. We think this does hit it. If
you change your mind, yes you have to go to the complicated
syntax.
Arthur: Agrees that "WSDL first" is taking hold. Likes the inline
approach, makes this more like programming languages.
Should be baked in to the language.
Amy: Does not think it is possible to provide the inline
functionality without rewriting the component model. Then
we get in to if the content model changes when they are
inline. Fairly significant rewrite.
[alewis: +1 to Tom (to my *great* surprise ... :-)]
[prasad: +1 to opposing inlining. Agree that inlining would only
complicate things than simplify. QName based ref is like
object programming, define it and reuse it as and where
needed. Well understood use case already from WSDL 1.1.]
Tom: Firmly opposed to adopting a whole new syntax. This is
NOT the way to go about making WSDL simpler, other things
we have done (binding, fault roll-up, etc) are better.
[sanjiva: +1 to opposing inlining]
Jeff: Might be that the changes to the component model wont make
it better/worse, but it will take time.
Paul: Found that nesting Schema types inline didn't work very
well. What will the choice give you? Where is the benefit?
[prasad: Likes to see simplification accomplished via facility to
assume defaults for things not explicitly supplied rather
than via alternate syntax etc.]
Arthur: If I can mechanically transform the inline document in to
the normal syntax that fits in our component model, why is
there any work needed?
Amy: If we described the syntax and provided the transform in
an appendix, this might work.
[prasad: Such mechanism could be private and add on by tools
providers than something specified in the spec.]
Jonathan: We already have a syntax to model mapping, we would just
need to enhance it to describe 2 syntaxes.
Phillipe: two different syntax are a bad idea.
[alewis: I think I'd be a lot happier if someone were to take the
time to make the effort to create a very concrete proposal,
showing what changes need to be made, where. I realize
that if there's a chance that this might not be accepted,
it's hard to commit to the work ... but that goes for
the WG, too.]
[prasad: +1 to phillipe; We don't need two different syntaxes for
people to use]
[DaveO: How about if we did some more work on the component model?]
[alewis: DaveO, How about if who did what kind of work on the
component model?]
Umit: Inlining sometimes looks 'sexy' but it turns out it doesn't
really make it simpler.
[DaveO: either the wsdl wg or BEA..]
[alewis: Sorry, that was the ambiguity I was hoping to get resolved.
(with the additional choice: proponents of the simplified
syntax as an informal group)]
Bijan: Is WSDL an authoring format or a message exchange format?
Philippe: I'd like to see implication of the proposal on the
inheritance mechanism, in particular since we don't allow
operation overloading.
Jonathan: It has shifted over time, and not shifting as fast to
machine only as he would have thought.
[alewis: DaveO, If BEA or a small group of WG participants were to
offer a proposal that showed "change this, this, this", my
ability to evaluate cost and complexity would be greatly
enhanced.]
[umit: +1 to Amy. ]
Dave: To address two syntaxes are bad: In some cases it works out
great. Ex: Xpath slash syntax
[bijan: I think the XPath example isn't particularly useful as an
example]
[bijan: For this issue]
[umit: The proposal has to take into an account component
equivalence and component designators and how they will be
affected. ]
Dave: Another syntax is XSLT
[prasad: I would rather see us put extra effort to try and simplify
WSDL syntax rather than come-up with another simpler syntax.
I also disagree that tools can not reduce the pain of the
language users.]
Jonathan: XPath is not a good example. XSLT is a good thing. But
isn't sure if WSDL needs this functionality.
[KevinL: +1 to prasad.]
Roberto: Comparing Schema and RelaxNG inlining makes things much
harder for Schema.
Tom: Would like to vote on the proposal
Jonathan: strawpoll: "How interested are we in pursuing an inline
syntax?
[prasad: Opposed to inline syntax]
[plh-ws: 3/6 (without the phone)]
[jjm: pass]
[alewis: Opposed.]
[KevinL: opposed]
[jeffm: I'm opposed to inline syntax]
[Allen: Opposed]
[prasad: Opposed]
[sanjiva: opposed to inline syntax]
3 for, 11 against adding an inline syntax.
-------------------------------------------------------
Topic: Simplified elements
[dbooth: dbooth notes that it took several minutes to decide whether
to take a straw poll, 40 seconds to agree on the straw poll
question, and 70 seconds to perform the straw poll.]
Dave: the idea is to introduce elements that would reduce the
syntax of common (I.e. SOAP over HTTP) WSDL scenarios.
Amy: We have already got an approach to this based on the
attribute roll-up stuff. Don't see great value in this.
[KevinL: instead of introducing new elements, I would strongly
prefer that we define defaults.]
Tom: Does not think it accomplishes it goal by adding more
element to WSDL
[prasad: +1 to Kevin. Lets look to simplify things via defaults
rather than new syntax. Isn't this the same issue as
before in a new bottle :)]
Tom: thinks that maybe we have already accomplished lots of
this simplification
Strawpoll: Should we persue creating new elements (Dave O proposal item #2)
[alewis: Opposed]
[Allen: Opposed]
[prasad: Opposed]
[KevinL: opposed]
[sanjiva: opposed]
[jjm: abstain]
[umit: opposed]
Results: 2 for, 11 against
Dave: Going to drop proposal #3 (a non XML syntax)
-------------------------------------------------------
14:45 Issue X: Headers/Body [17]
deferred till after break
-------------------------------------------------------
14:45 Issue 102: Schemas in imported WSDL [18]
Review Glen's specese [19]
[18] http://tinyurl.com/ysgl#x102
[19] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0017.html
Arthur: Why SHOULD instead of MUST?
Glen: Some Schema processors might not be able to handle
importing components from a WSDL documents directly
(I.e. by handle them a chunk of XML).
Authur: We should say MUST because it will help interop.
Tom: Agrees with Authur, but is worried that someone though
we couldn't say MUST.
Umit: Says that MUST should not be used. We are putting a burden
on the Schema processor which you may not be able to
control.
Roberto: Agree with Authur.
[prasad: I agree w/ Arthur, if that is the desired behavior, lets
make that a MUST]
Discussion about Schema processors and what they can and can't do.
[sanjiva: +1 for changing to "MUST"]
[alewis: +1 to Glen.]
[prasad: I think this msg captures the issue well:
http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0148.html]
[plh-ws: 'When a schemaLocation is present, it must contain a single
URI reference which the schema author warrants will resolve
to a serialization of a "schema document" containing the
component(s) in the <import>ed namespace referred to
elsewhere in the containing schema document. ]]
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#composition-schemaImport]
Much discussion about how processors might work and how import works
that the scribe was unable to capture/
Jonathan: We seemed to be decided on MUST, but Umit still has a few
concerns
Aurthur: We should collect examples of documents that may have
problems with MUST in the spec.
[alewis: +1 to Arthur; use the test cases to insure that the spec
defines things unambiguously]
Arguments over the wording, including if to include a location or
fragment ID.
Change SHOULD to MUSt and 'root'
... To "importing"
RESOLUTION: Issue 102 is closed with Glens wording with "root"
changed to "importing".
Time to take a break. Back at 15:25 EST
15:00 Break
-------------------------------------------------------
15:25 Issue X: Headers/Body [17]
[17] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0069.html
Dave: See [17] for proposal. Describes the proposal. Explicit
support for defining headers.
Glen: Headers should be in an extension spec, and don't belong in
the interface. The one use case I see for headers are
cookie-like functionality.
Dave: This is saying at the interface level - I expect this
header.
Glen: If their is anything more complicated then "always put this
header" then you should be using features & properties.
Dave: We think our proposal allows us to specify optional and
required headers and doesn't layer on top of other
functionality of WSDL 2.0 - this make it simpler to use.
If you have more complicated stuff, then you can go to
features. This hit the 80% in straightforward syntax.
Roberto: We used to have headers in the interface operations. We
removed them.
[prasad: The difficulty with introducing concept of "Headers" at
the abstract level is that some of the bindings may not
have a concept of a "Header". ]
Roberto: This proposal is just like what we had and removed with a
different name and syntax. This is not really a 'style' in
the WSDL sense of the word.
Glen: What will this be used for?
Dave: If its specified in your interface, you can at least access
the types and work with them
Umit: We have the facility to do this with features and properties.
[alewis: argumentam ad absurdam]
Yaron: Why don't we just use F&P for everything? We need an easy
way to describe things that the service expects, and I
expect WSDL to do that for headers. If we get rid of headers,
then we might as well get rid of message bodies too.
Glen: Messages are different, with headers you don't know when they
might appear and how to use them.
Yaron: Sometimes headers are used for versioning and stuff that is
application specific. Other headers are more transport
specific and perhaps they belong in the binding. In many
cases we have application data required or not) we are
asking to be able to defined these headers in the interface.
Glen: Drilling down in the versioning example - where does the
WSDL come from on the old server.
Yaron: I have to see the header in the interface, so new clients
can know that they can send it.
Paul: I don't want to see headers in my application code
Umit: We have had this conversation before.
[plh-ws: I would note that, while you don't see it in the application
code, the content-type header is still useful for the entire
application.]
[pauld_: want's WSDL to describe the ultimate receiver for a header
- what about intermediaries ?]
Umit: If we were able to require importing Schema for a feature,
then this might help the problem.
Sanjiva: The idea of an application header doesn't appeal to me.
Security model my be a problem. I like the simplicity of
the way we have things now
[umit: A soap module or feature may specify a schema. There is
an example, OperationName feature specifies such a schema]
Dave: HTTP mixes application and app data. Cookies a good example.
This is an example of application data in headers. Maybe
people will make bad choices and put bad stuff in there,
but why are we preventing from doing it
Tom: Didn't much support removing headers from the interface, so
is in favor of putting them back in. Why should we prevent
people from doing that?
Yaron: Security model isn't compelling because you will have to sign
the headers no matter what. Disturbed by presumption that we
know best for users and they have to use features. Also don't
much like features so they don't make me happy to have to
use them just to set a header.
Glen: We will define a feature that will be in WSDL, so everyone
will support, that will allow you to define a header.
Yaron: I want headers that are purely application specific
Sanjiva: It does complicate security. I don't buy the argument that
an app will have one header its wants to stick them in. Much
more likely that there will be complex rules about when headers
appear or don't. WS-Addressing has a reference thing which
are like cookies and are not defined in WSDL. Headers just
don't go far enough and its not worth it. F&P is the right
solution.
Dave: We should put security behind us.
[umit: Can we have a straw poll?]
Yaron: We are talking about a single, very very important, case.
Maybe we shouldn't call it header in the interface. There
should be this other thing, defined at a syntax level, that
will define this kind of app data.
[sanjiva: Isn't a <property> the thing that Yaron is referring to?
A piece of data that's associated with one or more
features?? (Or at least that's what I understand as a
property.)]
Sanjiva: points out that we have the soap:header in the binding that
allows you to put whatever header you want.
Yaron: Not good to put these app headers in the binding, doesn't
belong there. IF we can take the proposal to have a feature
to set a single header with a bunch of elements and change
it to be able to have headers in different SOAP headers we
might be good.
[alewis: there's a tradeoff between validation and extensibility]
Yaron: Don't tell users that they can't use headers - we have
customers that do it.
Glen: We are trying to promote best practices
Roberto: Lets see Glens proposal for the feature and stop the discussion.
Moving on....
-------------------------------------------------------
16:00 Issue 95: service/@name required? [20]
Options:
a) No: remove service/@name
b) Yes: close issue.
[20] http://tinyurl.com/ysgl#x95
Marsh: Dependency between issue 95 and the service reference
stuff which hasn't been fully incorporated into the
spec yet. Defer.
-------------------------------------------------------
16:05 Issue 79: How much validation? [21]
Options:
a) In scope: need volunteer to write up a proposal.
b) Out of scope: close issue
[21] http://tinyurl.com/ysgl#x79
Umit: This is about conformance. Do you have to understand all
of the bindings all of the MEPs etc.
Tom: For instance, if I don't understand the out-in MEP am
I still in conformance.
Amy: If you support at least one you are OK. Can't require
everyone to support all MEPs and bindings.
DavidB: Two kinds of interop.
1. Interop of 'agents' (client/server).
2. Interop of processors
#2 requires a different kind of interopability. We don't
have the task to define what the processor does.
[alewis: question: is the use of a MEP URL in an operation an
implicit wsdl:required?]
[TomJ: Discussion about how a processor would treat documents
that have things in it that it doesn't understand]
[GlenD: amy: yes (imho, natch)]
Aurthur: We are a language. All we say in our spec is what a document
should have in it to be in our language.
[GlenD: Also, have we determined whether a wsdl:required element in
a section of the document you aren't caring about needs to
be understood to process the sections you do care about?]
i.e. is scoping more important or is wsdl:required more
important?]
Umit: Everything in our spec is normative - you follow our spec
you are OK. Even only a section. Is everything in our spec
required?
[Discussion about what parts of our spec are required, including
wsdl:required, Part 2, etc.]
Glen: It should be possible to declare a document with
wsdl:required and force any processor to handle it.
DavidB: We don't want to talk about a WSDL processor, but XML
talks about an XML processor.
Arthur: Proposes describing what required means in the component
model
DavidB: volunteers to change the few places in the spec where we
talk about a processor without changing the intent.
ACTION: David Booth to suggest improvements to the spec clarifying
"WSDL processor".]
New Issue: Is there something we can do to improve conformance on the
wire between WSDL-based agents? This would prevent us from
getting immediately profiled.]
-------------------------------------------------------
17:30 Inheritance issues:
- Issue 76: Pointing at derived interfaces [22]
Options:
a) Yes: need volunteer to write up a proposal.
b) No: close issue
- Issue 81: Account for interface inheritance [23]
Options:
a) Yes: come up with an alternative.
b) No: close issue
[22] http://tinyurl.com/ysgl#x76
[23] http://tinyurl.com/ysgl#x81
Deferred.
17:30 Adjourn
Received on Wednesday, 4 February 2004 12:51:07 UTC