Web Services Description F2F (continued) -- 20 Jan 2005

<pauld> marsh: are you proposing a mapping from wsa:action into a wsdl 'op-code' ?

<pauld> hugo: i think this is more or less what we were talking about

<pauld> dbooth: this approach would solve what i was talking about

<pauld> paco: how would this help, unless action values are distinct

<pauld> hugo: possible to have multiple different messages with the same action going to the same operation, e.g. logging service

<pauld> discussion of uniqueness, GED and action may form a unique pair

<Zakim> dbooth, you wanted to explain motivation for uniqueness

<pauld> dbooth: operation mapping requirement tries to solve "what do you do with a message" problem

<pauld> glen: no, operations exist for a reason - i want to "do something". the operation is the verb, not just a bag

<umit> The reason that the default ACtion values solve the problem is that it uniquely identifies both the operation and the message. The moment one starts from deviating from assigning the default Action values, then uniqueness requirements must be met in order to identify the operation and the message.

<pauld> dbooth: well know. you might not necessarily want to think this way. WSDL describes the Web service (there may be zero, one or many WSDLs in play).

<pauld> ... what do i need to do with a message when it comes in

<pauld> ... maybe that a message may result in multiple 'actions'

<pauld> +1 to dbooth, with feeling

<pauld> glen: you need to know, somehow. which operation is in play

<pauld> marsh: what has this to do with unique actions

<Zakim> hugo, you wanted to say that he think that the (action, message) pair needs to be unique, not the action alone

<pauld> hugo: i think that the (action, message) pair needs to be unique, not the action alone. possible to have 2 op-codes for different messages.

<pauld> umit: action might not identify anything, you have other mechanisms. we might not be able to solve this problem, only make suggestions.

<dbooth> PaulD: "WSDL isn't the Web service. WSDL *describes* the Web service."

<dbooth> +1 to Paul's quote!

<pauld> discussion between dbooth and bijan about higher level actions, grouping operations into choreography. maybe extra information in the header to achieve this

<pauld> amy: there are lots of other mechanisms for determining the actual processing undertaken beyond 'action' encoded in the message

<pauld> tom: what can we do to go forward here. close with no action!

<pauld> paco: do we have to provide an actual mechanism? the default dispatching could be 'action'. current text allows you to do what you want.

<pauld> paco: action is just one of many possible mechanisms

<pauld> anish: action satisfies this requirement, action+GED satisfies this requirement. we're done

<pauld> marsh: should we require actions to be unique?

<pauld> anish: we already said (in ws-addr) no

<pauld> ... it's up to you if you want to use an extensibility mechanism

<pauld> marsh: maybe it's only action+GED that is unique, then you'd have an invalid WSDL. my service could still work with other magic dispatching mechanism

<alewis> why do you have to have something at some level to tell anyone else how you're doing this?

<pauld> paco: suspects there's a bug in the spec: why do we cite the interface as the place to describe the dispatching mechanism?

<alewis> this is the same silly argument as before!

<pauld> i'm coming round to amy's POV on this topic

<pauld> but have yet to convince folks back home

<alewis> if you're wearing a straitjacket, you don't *need* an overcoat.

<pauld> dbooth: you need an explicit way of describing the 'verb' at the abstact level. this is a foundation spec. once that is done we can drop the operation mapping requirement

<pauld> glen: then we can toss out operations

<pauld> paco: context may provide dispatching.

<TomJ> I am not willing to support any addition to the spec that introduces a 'verb' that replaces the operation.

<pauld> dbooth: operations are convinient metaphores. also there are protocols that do request-response

<pauld> marsh: i need some concrete proposals here

<pauld> dbooth: sanjiva was working towards one

<pauld> anish: we can take the last F2F discussion and form a proposal aligned to ws-addressing

<pauld> marsh: maybe we need to move sanjiva's proposal forward

<kliu> +1 to amy's why statement - all we have to do is to provide a way so people can indicate what mechanism they use to distinct the message if they choose to do so, no MUST is necessary here

<pauld> tom: we spent a lot of time on this already. let's vote and move forward. i vote no

<pauld> prasad: it's a small change at the ws-addr level to require unique action uris for all input or output messages in an interface

<pauld> daveo: keen to vote, but interested in relationship between this and wsa:action.

<pauld> tom: yeah, it gives you the 'verb'

<pauld> daveo: people may or may not be using ws-addr

<pauld> paco: it's only on the server that an ambiguous WSDL is a problem. doesn't impact client interoperability

<pauld> anish: action values don't have to be unique

<pauld> daveo: nothing we can do here that makes wsdl 2.0 simpler here?

<pauld> ... i haven't heard anything that makes WSDL 2.0 simpler when ws-addr is engaged. lets close this issue.

<prasad> Anish: We can require them to be different (not unique) in an interface. I.e. distinct URI for each different message in an xface.

<pauld> anish: you can still have two 'in' messages for an operation which aren't unique

<dbooth> Anish is right. The granularity of the op name mapping requirement is wrong.

<umit> We already agreed that there is a granularity issue, didn't we at the last f2f?

<pauld> marsh: what do we need to change to resolve paco's bug?

<dbooth> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#Interface_OperationName

<pauld> arthur: it's only the input GEDs that have to be unique - the service executes the operation based on the inputs, output is causality

<pauld> ... who cares if the outputs aren't unique

<pauld> marsh: in the case where there are two outputs.

<pauld> arthur: corollation of outputs back to the input is a different problem.

<pauld> ... back to LC82. text seems like overkill in the way it's written. it's lawyer-speak

<prasad> I agree :)

<pauld> marsh, tom: just the first message in a MEP has to be unique

<prasad> Text in the spec not the issue ..

<pauld> glen: yes, but also the first in the OUT as well

<pauld> discussion of 'client' and 'server' roles

<pauld> jeffm: forget client/server and think in terms of recipient. response doesn't have to have uniqueness

<pauld> marsh: we're getting close here. two buckets - in messages, out messages

<pauld> jeffm: it's the side that's doing dispatch that requires uniqueness

<prasad> If I redirect responses via replyTo, don't I have to worry about which operation and other such at the recipient end?

<pauld> rapid discussion of dispatch info required in respect to the MEP in play

<pauld> tom: i only need to understand which operation / MEP is in play. first message does that

<pauld> tony: need a new term e.g. "initiating message" or "unsolicited messgage" (brits giggle)

<pauld> ... problem is terminology is overloaded

<pauld> kevin: how does this work. are we requiring 'state' in an operation?

<pauld> tom: yup

<umit> ouch!

<pauld> ... that's the way it works

<pauld> tom and anish play dispatch tennis across the room ..

<pauld> anish: in the message, there is some kind of client identitiy? if that is the case, i could buy unique GED for first message argument

<pauld> tony: starting more than one MEP async without corollation mechansim isn't going to work

<pauld> paco: do we need to specify the corollation mechanism in play as well? a service doesn't want to divulge its implementation

<pauld> tom: a complex MEP requires a corollation mechanism

<pauld> kevin: could have two alternative ins, this would imply they would have to have a unique GED

<umit> Uniqueness is always defined with respect to a domain. What is the domain we are talking about here anyway? I made a posting to WS-Addressing for this issue: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0035.html

<pauld> amy: i'm violently opposed to making this stricter. it's none of your buisiness how my messages are dispatched. other out of band dispatch mechanisms not described in WSDL may be in play.

<pauld> ... you're preoccupied to code-generation langauges. it isn't the web service generation language

<pauld> +1 to amy

<dbooth> +1 to amy also

<TomJ> But that doesn't invalidate the use case that code generation *is* important, and if a generation engine doesn't have enough info in the WSDL do the job, then perhaps the WSDL is not complete.

<umit> I disagree with Amy on one point. WSD is for clients to be able to communicate with the service. If the service requires a specific way of interacting with it from the client to aid in dispatching, then it must be explicit, either in the usage of WS-Addressing, marker,etc

<alewis> horsefeathers, tom!

<pauld> tony: corollation is the key here

<dbooth> WSDL is never a complete description of the service anyway.

<alewis> if you want a web services code generation language working group, petition the director! i call scope creep!

<TomJ> Are you saying that my use case is not valid?

<alewis> yes, tom, code generation is out of scope for a description language.

<Roberto> I disagree with Amy too. If operations surface in the description, it should be possible to discriminate them. Otherwise you can define one operation per service and you're done.

<alewis> more to the point, my use cases (describing legacy services) conflicts with your use case (demanding explication of service internals)

<Arthur> sorry amy, but i disagree. we absolutely need wsdl to be complete enough for a client to access the service without the need for any additional out-of-band information

<alewis> irrelevant, arthur.

<alewis> not what the argument is about.

<Arthur> no it isn't

<pauld> marsh: need to wrap up. we're not going to get agreement here given it's a difference in architectural views

<Arthur> you are an in obvous minority here

<umit> Ah, that is a separate discussion Arthur. Is WSDL the complete and one-and-only contract?

<alewis> the client *has* the information: it can construct the message.

<Arthur> if it isn't even complete enough for a client to access the service, then it has failed to meet a significant requirement

<alewis> i repeat, there isn't a question of the client being unable to access the service.

<alewis> the use case presented, instead, is for generation of code to implement the service.

<alewis> i don't buy it.

<pauld> proposal #1: initiating message of an operation must be distinguishable

<Arthur> wsdl MUST support code generation

<alewis> horsefeathers, arthur.

<pauld> tom: this relaxes what we currently have

<pauld> ... this may make amy happier

<pauld> proposal #2: all messages in a given direction need to be distinguishable

<Arthur> call me Pegasus then

<pauld> ... within an interface

<hugo> proposal #2 for me

<prasad> Distinguishable based on what criteria? GED?

<alewis> return at +25 after next hour?

<Marsh> Yes.

<pauld> LUNCH, BACK at 13:30 local time

<umit> Ah, I may miss this fun

<prasad> Me too

<alewis> ugh.

<alewis> not there yet?

<Marsh> OK, we're about to start again.

<alewis> for i in $(cat issues.list | cut -f 1) ; do echo "Issue $i closed" ; done

<Marsh> resuming

<Arthur> scribe: arthur

<Marsh> Scribes: Paul(done), Arthur, DaveO, Anish

taking a poll now

<Marsh> Proposal #1`: /initiating message of an operation must be distinguishable

<Marsh> proposal #2: all messages in a given direction need to be distinguishable

<Marsh> Proposal #3: All messages in the "in" direction need to be distinguishable.

<alewis> NOTA?

<Marsh> Status quo: All messages need to be distinguishable, right?

<alewis> could "none of the above" be added to that list, please?

<Marsh> Proposal #4: none.

<Roberto> 2

results of poll are #1 has 7, #2 has 5, #3 has 2, #4 has 2

now distinguish between #1 or #2

<Marsh> proposal #2: all messages in a given direction need to be distinguishable

<scribe> new results are #1 has 6, #2 has 10

Tom: this means if two operations return the same GED, e.g. PurchaseOrder, then they must be distinguished

<pauld> paul: this is reopening the discussion

Anish: yes, that's why we had 3 proposals

Glen: this does not allow the common case where the return message is distinguished by the content, e.g. the response if correlated to the request which is normally distinguished

Anish: the GED is not the only way to distinguish

Glen: does that mean the MEP can be used, e.g. if the outs are correlated to the in?

Mark: I'd like to see the proposals restated by how the messages are distinguished

Arthur: points out that the spec currently only discussed the GED as the way to distinguish operations

Jonathan: does anyone object to #2?

Arthur and Glen object

<alewis> we're forcing people to say things that they may not need to say.

<Marsh> Bijan: Are we allowing people to say things they wouldn't be able to say otherwise, or are we restricting them from something something they can't say now.

<dorchard> And DaveO objects without seeing the exact wording. This feels like something is being slipped in.

<dbooth> Bijan: Would this be allowing people to say things that they wouldn't otherwise be able to say, or restricting them from saying bad things?

<asir> Arthur and Glen, what are your objections ??

<pauld> paul: went for #2 as a second best option. an operation is symetrical exchange of messages.

Arthur: WSDL 2.0 as currently spec'ed (2.2.1.1) makes many WSDL 1.1 operations illegal

Glen: request-response operations establish a correlation so #1 is less restrictive than #2

Tony: Is Anish's concern related to asynch?

Anish: I can buy the argument that we don't need this feature at all since its up to the designer of the service to route the inputs anyway it sees fit
... We are saying that the designer of the service must advertise to the world how operations with the same inputs are distinguished
... I can see the point that is being made by the people who filed the minority opinion, but why are we taking half measures?

Arthur: do we have to add information to the definition of MEPs to indicate that they have a way to distinguish operations, e.g. by correlating the request to the response?

Tony: discuss asynch versus synch

Paul: there are many ways to correlate messages, depending on the transport, etc.

<pauld> VOTE VOTE VOTE

<Marsh> dbooth, we're really deep into Arthur's issue #82.

<dbooth> Oh, we've passed my issues?

<dbooth> I guess we've bumped back to Arthur's.

<asir> well they are interconnected

<Marsh> pretty much I think. This poll doesn't seem to be a complete solution to yours as well, AFAICT

Arthur: maybe we need to have the MEP specify it's key which is a subset of the messages that are sufficient to identify the operation

Jonathan: how many people are in favour of removing the ONMR versus trying to fix the spec?

<anish> btw, the action attr does not help u, david, as it is not required to be unique

<dbooth> Anish, I don't think uniqueness is necessary. If the action is the same, the semantics are the same. That's fine.

Glen: i feel we need to capture something

<pauld> you're less likely to cut yourself with a sharp knife

Jonathan: yes, but is is practicle and testable? we can't prevent people from writing bad interfaces

<anish> david, then why are there two different operations/messages if the semantics are the same

<dbooth> anish, i dunno, i didn't write that WSDL document!

<anish> :-)

straw poll

Who is in favour of removing ONMR as a normative part of the spec

<jjm> abstain

<Roberto> opposed

<anish> opposed -- don't throw the baby out with the bathwater

14 in favour of dropping ONMR and 4 who want to keep it

Formal vote now.

<dbooth> +1 to best practice

Proposal on the table is to move ONMR to a Best Practice document.

<asir> +1 to best practice

<jjm> abstain

<dbooth> Non-normative note

Jeff: best practices have little practical impact

Jonathan: I recommend that we simply rename the current section to make it a Best Practice and not a Requirement

<dbooth> Damn, fire alarm at MIT again

<Marsh> qa+ mark

<dbooth> Hugo and i need to evacuate again

Amy: TIBCO would remove our formal objection if ONM is a Best Practice

Anish: Even if it is a Best Practice we need to resolve the issue. What do we recommend? #1 or #2.

Paco: We could clearly state the requirement instead of recommending the solution.

Mark: In RFC 2119, SHOULD is fairly strong, so not appropriate here

Arthur: this problem is wider than interface design since it is possible to have two services at the same endpoint, each with different interfaces, which may receive messages with the same GED.
... The Best Practice should not be confined to the interface design.

Tony: +1 to Paco - just document the problem

<kliu> VOTE, let's vote

Jonathan: In summary, we need to have a Best Practice and explain the problem and possible solutions.

<alewis> 30 mins?

Jonathan: go on break then take the formal vote

<anish> --- break ---

<alewis> x:40?

<Roberto> wasn't it 20 minutes?

<alewis> x:30, then?

<Marsh> No, 20 min

<Marsh> tes,

<alewis> 'kay

resume at 3:30pm Melbourne time

<Roberto> 'k

<Marsh> Will resume with a Vote on whether to convert the ONMR to a Best Practice section, carefully delineating the problems that might arise from not having an identifiable mechanism in the message to distinguish which operation the message belongs to.

<Marsh> Resuming now.

<dbooth> ONMR == Operation Name Mapping Requirement

Voting begins...

<dorchard> glenn, why did you abstain?

10 yes, 3 no, 3 abstain

Jonathan: Would any no voters file a formal objection?

Jeff: Very possibly.

<Marsh> Yes: W3C, BT, Canon, TIBCO, SAP, Microsoft, BEA CA, IBM, webMethods

<Marsh> No: Sun, Oracle, Macromedia

<Marsh> Abstain: Sonic, Education.au

<asir> did u miss SAP?

Jeff/Anish: express concers, BP carries little weight, still need to decide on the wording

<asir> all right, 1 of 3 down :-)

<Roberto> for the record, Sun will consider filing a formal objection too

Now discussing LC82

Jonathan: Can we ask editors for wording and then discuss it?

Anish: The argument has been on what "bucket" of messages need to be unique. We need to decide that.

Jonathan: We couldn't agree on that so we decided to make it a Best Practice to avoid the problem.
... Do we need to make the Best Practice applicable to more general MEPs

<dbooth> Arthur: This is only a problem when you have a mental picture of how you want to implement your service.

<dbooth> Arthur: It's not a problem if you implement differently.

Arthur: We can defer LC82 pending the rewrite of the section.

Moving on to LC84a, LC84b, and LC84c

dbooth: LC84a goes away

LC84b deals with verbs

discussion on use of WS-Addressing to solve LC84b

Tom proposes to refer to WS-Addressing to answer LC84b

dbooth: I recommend that we proceed in the direction of how we accomodate WS-Addressing

Bijan: is this exposing implementation?

dbooth: No.

Amy: It is easy to imagine a Web service whose only verb is "process".

<alewis> agreed, Bijan.

Jonathan: we need to move on

Tom: Propose to close issue with no action

Jonathan: Any objection to closing LC84a?

No objections.

RESOLUTION: Close LC84a with no action.

Taking a poll on b and c.

No interest in requiring an Action with each operation.

No interest in requiring WS-Addressing.

<alewis> could that issue be presented to the WS-Addr/Desc joint task force?

Interest from dorchard in an optional Action.

<dbooth> Yes, amy, good idea.

Jonathan: Is there more widespread interest in adding an {action} property to the component model with a reasonable default value?

This must be coordinated with WS-Addressing.

Tom objects. Need to close down spec now.

Jonathan: There is currently a Property to set this. Do we want to make this easier?

Taking a straw poll to close these or to specify a default {action} at the abstract level.

<Marsh> ... and an optional attribute for specifying the action value.

<alewis> +1

<asir> +1

6 in favour, 3 opposed

<jjm> abstain

<scribe> ACTION: Write up a proposal for LC 84b. Assigned to Hugo.

<dbooth> ACTION: Hugo to write a proposal for adding an option Action attribute in line with WS Addressing

<scribe> ACTION: Modify Part 1 to write Operation Name Mapping Best Practice - assigned to Part 1 Editors.

Composition Edge Case issues

Discussing LC20

Arthur: I raised a similar issue. The spec needs to specify a "calculus" of Features and Properties.
... The reasonable meaning is to intersect (and) the constraints, so "true" trumps for Features

<alewis> isn't that union, rather than intersection? ( || rather than && )

No, you need to satisfy both constraints. No required attribute is true or false.

Similary, for Properties, you need to intersect the allowed values.

<asir> Or, may be order of precedence

<asir> Or, the strong guy wins

<alewis> i thought that status quo was the scoping mechanism: closest wins.

<asir> yep, that is scoping

<asir> this is composition

<asir> while assembling components

<alewis> hmm. think i'm missing important bits of the discussion required for comprehension

The semantics of Property components is that they specify an allowed set of values (possibly a singleton).

When composing Property components, all constrainsts must be satified, so this means we take the intersetcion of the allowed value sets.

i.e. that is the semantics

<jjm> no its all mute suddenly

but that may not be checkable in all cases

<Marsh> Yep, we lost you.

<asir> what is the intersection of two {value constraints}?

an arbitrarily complex Type Definition may be uncheckable at development time

any actual value that is transmitted at runtime can be checked (e.g. by a validating XML parser) and an error can be detected

the service should probably generate a Fault

Glen: a Property value is not necessarily transmitted. It may be set.

<asir> why would the property value be transmitted?

<Marsh> Feature composition is the same - intersection is effectively "true trumps".

<Marsh> asir: E.g. action becoming wsa:Action header. Glen clarifies not all properties are transmitted though.

<asir> ok

<asir> I hear {in-scope-properties} ..

<asir> what are the two proposals?

<Marsh> When composing Property components, all constrainsts must be satified, so this means we take the intersetcion of the allowed value sets.

<Marsh> Feature composition is the same - intersection is effectively "true trumps".

Proposal is to accept the above rules to close LC20 i.e. for Feature, "true" trumps, and for Property, value sets intersect.

and to revisit the equivalence issue after we discuss Arthur's issue to restrict inheritence to diamond inheritence, which simplies the definition of equivalnce

<Marsh> ACTION: Arthur and Asir to look for more edge cases ref LC20 and LC27.

<Marsh> PARTIAL RESOLUTION: Adopt intersection rule for props and features, revisit equivalence after we discuss Arthur's general equivalence issue.

<Marsh> Adjourned.

Adjourn at 5pm

<Marsh> only 6 in the room so far.

<Marsh> will wait for maybe 2 more...

<asir> Jonathan, what happens to import & include issues? Are we discussing those issues today?

<Marsh> OK, dial in, we're ready to roll.

<Marsh> hugo, wanna do your magic?

<hugo> sure

<dorchard> scribe:dorchard

test

<scribe> scribe: dorchard

Issue 74: types, roberto's proposal, nov 44

<dbooth> Meeting: Web Services Description F2F

<dbooth> Chair: JMarsh

can't use schema types for xml 1.1, so we invented our own!

roberto's proposal: fix bugs in our type system

microsoft: complicatioins to support XML 1.1 outweigh benefits

rich salz: agrees, abstracting away.

daveo: support just XML 1.0

pauld: i wanted to support 1.1 given it's a W3C rec, but having seen the complexity introduced i now think we should just stick to 1.0

ibm +1

tom: we thought we could get away without any complications, but there are. time to remove.

Hugo: xml 1.1 is a w3c rec, not supporting may help prevent it from being deployed, allow xml 1.1 somehow

<asir> asir: drop xml 1.1 support, prefer to use XML Schema types, ideally XML Schema WG and Core WG should address the real problem (for pauld)

<Roberto> +1 to asir's statement

<pauld> yes, i'm now convinced it's schema's problem

daveo says some brilliant stuff about xml 1.1 not being adopted because of types. The types are the thing

jonathan points out xml core was focused on xml validation, not the types. And they didn't "purposefully" make it lame.

<Zakim> TomJ, you wanted to call the question: Should we drop XML 1.1 support from WSDL 2.0?

asir: schema wg needs to fix types.

roberto agrees with asir

hugo: at w3c ac, there were a # of schema, wsdl, xquery, etc.
... at w3c ac, there were a # of schema, wsdl, xquery, etc. people. They said we were doing the right thing..

<asir> Hugo, where can I find that joint report?

<hugo> asir, it's on MSM's to-do list; I have some personal notes if you want

<asir> that will help

more mutterings of "drop 1.1" from various wg members

Vote is 11 to 2 for removing 1.1

w3c, the 2 against, do not object.

<asir> obsoletes LC 23

Resolution: close 74e, 75q, 89b, 89c as we have removed 1.1

issue definition of "node"

David Booth extolls the virtues of his proposed definition...

DB does not want to add the "pattern" (scribe not sure what pattern is)

<Roberto> is that the definition in http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0088.html?

db if reply directed to a different address, this can be the same node.

<Marsh> Nov 70, Nov72

<hugo> thanks

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0070.html

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0072.html

<pauld> prefer "agent" as opposed to "client"

daveo laughs that there seem to be problems with the URI for agent in web arch document

<kliu> support reuse "agent" definition from ws architecture document

<asir> support the use of the word 'agent' in this context, its ok

scribe is doing terrible job because he's recalling debates on the TAG and Web Services architecture of agent and service and node and client and server and requester and provider and sender and receiver.

proposal: A node is an agent., sometimes called client and service.

Note: it may be accessible by multiple protocols.

DB: refers to agent, but we don't use it.

JM: any objections to adopting David Booth's proposal?

DO: problem arises that in-out requires out message goes to same node, which can be seen as violating the in-out contract if one perceives "node" = different address. By changing "node" to handle multi-address.

no objections to adopt DB's proposal.

Resolution: Add DB's text + "Note: " in 2nd sentence, and close issue 50.

<dbooth> http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0070.html

A concrete example is at http://www.pacificspirit.com/blog/2004/12/01/versioning_service_data_using_wsdl_application_data_feature

<Marsh> I muted you immediately because of noise on the line.

<Marsh> We'll fix it in a moment...

<bijan> marsh that's me

<bijan> Sorry about the noise

<Zakim> asir, you wanted to summarize

BEA is fine with having a "header" at the interface, as long as more than SOAP is supported.

BEA observes 2 HTTP headers of interest: content-location, as being used by Atom and HTTP applications, and WebDAV's depth.

<TomJ> I am supportive of the idea of putting back the concept of headers in place of the application data.

<asir> I would like to explore the abstract "header" at the interface level, as spelled out by DO

<asir> DO, extrapolationg, what will be relationship between "header" and SOAP Module?

asir, there's at least 2 headers needed: soap headers and http headers. I could see a solution of header at the interface level, then the soap Module means serialize as soap headers.

<asir> thanks DO

<Marsh> Tony: Why not use another term than "headers" - sideband data, etc. Keep it abstract from SOAP.

<TomJ> we got it wrong because we have at least one comment that said 'where are the headers?' We have abstracted headers so well that people don't even realize that Application Data is how you set headers.

<asir> :-)

<Marsh> DO: All(?) other protocols sem to have a concept of headers.

<TomJ> all the interesting one do....

<Marsh> ... Abstraction is leaky, that's just a fact of life.

<Marsh> ... Nothing wrong with stating that the data is intended to go in a header.

<Marsh> Tony: SOAP headers are special, you can have multiple headers that can be targetted independently.

<Marsh> Tom: WSDL needs to be able to describe that "these angle brackets go in a header".

<Marsh> Tom: Important last point that "header" is being used.

<asir> if there isn't any interest in re-introducing the concept of "headers", then another option is to rename AD to HD, that is header data

<Marsh> Glen: Not very much.

<Marsh> DO: How do you quantify that?

<Marsh> Marsh: Proposal is not to go back all the way to WSDL 1.1 headers, but to keep some of the benefits of AD, such as the requirement to mark WSDL:header generated headers, best practise about abuse.

<Marsh> Glen: Also likes the separation of the abstract feature and the SOAP module.

Tom, it looks like <soap:module uri="http://www.w3.org/2004/08/wsdl/module/AD" required="true"/>

<Marsh> Glen: For instance, I could bind it into a single bucket at the message level, which contains all the individual headers.

<Marsh> Glen: We could change the syntactic sugar.

<Marsh> Jeff: Feel like I'm viewing a hall of mirrors of abstractions that aren't going to serve people. You don't need as many layers.

- DRAFT -

Web Services Description F2F (continued)

20 Jan 2005

Attendees

Contents

Composition Edge Case issues

Issue 74: types, roberto's proposal, nov 44

issue definition of "node"

Summary of Action Items

Scribe.perl diagnostic output