Web Services Description F2F - Thursday

19 Jan 2005

See also: IRC log, IRC log


Glen Daniels, Sonic Software
Paul Downey, British Telecommunications
Youenn Fablet, Canon
Tom Jordahl, Macromedia
Anish Karmarkar, Oracle
Michael Liddy, Education.au Ltd.
Kevin Canyang Liu, SAP
Jonathan Marsh, Chair/Microsoft
Jeff Mischkinsky, Oracle
Mark Nottingham, BEA Systems
David Orchard, BEA Systems
Tony Rogers, Computer Associates
Arthur Ryman, IBM
David Booth, W3C
Roberto Chinnici, Sun Microsystems
Hugo Haas, W3C
Amelia Lewis, TIBCO
Dale Moberg, Cyclone Commerce
Jean-Jacques Moreau, Canon
Bijan Parsia, University of Maryland MIND Lab
Asir Vedamuthu, webMethods
Umit Yalcinalp, SAP
Prasad Yendluri, webMethods, Inc.
Paco Curbera, IBM
Steve Winkler, SAP
pauld, arthur


<Marsh> Scribes: Paul, ?, DaveO, Arthur

<scribe> Scribe: pauld

Status Check

marsh: we've still lots of last call issues ..
... schedule - we're not going to close them all this F2F and we're going to have to go to the director

<Zakim> hugo, you wanted to talk about justification to the Director and LC status

hugo: we do have a few issues, and some new ones still arrising, so we have to go to the director. we have some in relation to the addressing work and async. we have formal objections, etc. what does the WG think about aligning ourselves with addressing rather than racing to meet our schedule
... do we want to rush something out or produce something more appealing to users

dbooth: why would someone want to adopt WSDL 2.0. do we push it out as it stands or create something better targeted at addressing

marsh: even if we ignored addressing, we'll still have to coordinate with them. difficult to ignore addressing procedulary (sp?)

glen: it's hard to ignore addressing given the overlap. it's going to happen anyway.

paul: we're at the point were we have to make this kind of decision

glen: we have tons off issues which aren't addressing based

paul: someone else might come along and have similar difficulties ..

amy: ws-chor also gave us feedback, if we call out other WGs we might have to include them

marsh: addressing has raised a lot of issues

tom: how can we meet our current schedule?

marsh: close all our issues here
... we could divide the WG up and deal out the issues

tom: we could just close down and ship
... group should change it's thinking into 'we're shipping'

dbooth: a better spec will get adoption

tom: so would shipping now

jeffm: my experience is we can't rely upon promises to work in a certain way

arthur: jonathan's made an effort to achieve concensus. let's empower him now to be more dictatorial

marsh: you guys can help me!
... progress would be helped by timely completion of AIs. we still have many outstanding, e.g. fatal faults ..

paul: lets put a time on AIs and drop them if they dont' get delivered on time?

marsh: yup. we tend to rely upon people who are overworked, so maybe we should spread the load

hugo: what's the conclusion of this discussion?

marsh: inconclusive. we have to just work faster. no formal change in how we're going to work
... umit has been talking to henry about his LC comments. TP could be a good time to meet him F2F about this issue if it doesn't resolve quickly
... soap 1.1 binding note is fairly small. no open issues/actions on that. makes sense to wait before publication due to dependence on other documents
... and the primer?

dbooth: we got more comments before than after publication. we still need to solicit help.

marsh: let me know if you need telcon time and we'll make it happen

kevin: (to dbooth) we can discuss this on our regular call
... what's out time frame for publication?

marsh: ideally by the end of the TP?
... primer doesn't really go into CR, so we can synchronise publications at PR

<dbooth> ACTION: dbooth and KevinL to scope remaining primer work and identify who needs to supply what advanced topic sections

marsh: media type editors encouraged to answer LC comments and inform the WG via email

Agenda Bashing

agenda rearranged for Roberto's benefit

Single interface per service - Issue LC73/LC75n

roberto: we made a descision to have a single interface per service, however we've had comments that this is not realistic for management interfaces, meta data services, discovery and other motivations
... Versioning is an important use-case.
... [continues to outline proposal]

tom: the service is only a set of angle-brackets that collects endpoints. how do i know which one i'm using?

glen: it's just like WSDL 1.1

roberto: you can select the service you like based upon information available, e.g. which binding you want

tom: so it's a more interface centric approach which i prefer

glen: we had a long conversation about this.. i want to keep the status quo with the service element. association can be best met by another mechanism, e.g. "service group" or other meta-data

<alewis> note that we have last call comments asking for multiple interfaces per service from Anne Thomas Manes, Jeffrey Schlimmer, and Rich Salz.

tom: i'd accept this proposal over "service group" or any other radical rearrangement. i'm firmly opposed to multiple interfaces for a service. but i want to answer these use-cases, so i'm open to roberto's proposal

arthur: there are 2 kinds of bindings: generic and ones which specify an interface

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

kevin: what's the effort to explore this given we now have more evidence and use-cases to support the proposal?

<TomJ> Proposal URL: http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0094.html

paco: i understand you have discussed this long ago. it's a nice separation of concerns. there are other better ways of describing an association.

jeffm: if we reopen this, then people can make whatever proposals they want

<alewis> that's not what roberto said!

roberto: i'm not adocating going back to how things worked in WSDL 1.1. other specs layered on WSDL 2.0 would tighten up the relationship

<alewis> yes, that looks right ....

dbooth: adding this may increase adoption

<Roberto> I also said that endpoints that implement the same interface would be functionally equivalent (unlike in WSDL 1.1)

glen: there are other ways to achieve this functionality
... (to roberto) would service group or target resource satisfy your concerns

roberto: we shouldn't abuse the word "service" we need to think about what "web service" means

glen: i don't think a web service is a group, it's a single 'type' of thing ..

<prasad> I support Service group idea instead of overloading one service for multiple interfaces. KISS for the most usable case

arthur: like status quo. it's cohesive. and there are other ways of expressing relationship. the group as a whole already agreed upon these clear semantics and don't want to reopen this issue

daveo: i'm torn. BEA like the status quo - not least it helps tooling. but what do you do about the multiple interface problem?

tom: there already is a syntax grouping

jeffm: i'm with arthur. we've already had the debate and there is no new information. look at the record. unless we can resolve "what is a resource", "what is a web service", we're not going to make progress here


do we reopen the "single interface per service" issue?

marsh: 10 no, 5 yes, 6 abstained
... we've not going to reopen this issue

<scribe> ACTION: Editors to call out the difference between WSDL 1.1 and 2.0 in this respect

dbooth: we should offer an alternative method for expressing this relationship

<dbooth> There are at least three alternatives: 1. Group in the same <description> element; 2. Group in the same targetNamespace; 3. Separate documents that happen to use the same endpoint address

marsh: no objections to closing issue LC73/LC75n

<umit> There is another alternative. Add an extension that links all services that represent different views of the same thing together.

RESOLUTION: close last call issues LC73/LC75n with no action

<dbooth> Good point umit

RDF is the answer. what was the question?

<Zakim> asir, you wanted to ask clarification

Single interface per service - Issue LC89k

asir: i don't understand the relationship of this to the inheritance model

<scribe> ACTION: editors to call out the difference between WSDL 1.1 and 2.0 in respect to single interface per service, and indicate alternatives

RESOLUTION: close last call issues LC89k with no action


<Arthur> here is my wording for LC73/LC75n:
<div2 id="single_interface_per_service">
<head>Single Interface per Service</head>
<p>WSDL 1.1 imposed no restriction on the portTypes implemented by the ports within a service. WSDL 2.0 requires that within a service, all endpoints (previously called ports) implement the same interface (previously called portType). Therefore, when migrating a service from WSDL 1.1 to WSDL 2.0 any service that implemented more than one portType must be mapped to one or more services, each of which implementing a single interface. To indicate that these new services are related to each other, they should be placed in the same document, or in one or more documents with the same targetNamespace.</p>

<asir> arthur, the last sentence is best practice, right?

<umit> I don't think that we agreed on that targetnamespace clustering is the only approach.

<Arthur> yup

<Arthur> that's what we decided

<umit> Therefore, we can not say SHOULD.

<asir> no, we did not discuss that part at all

<Arthur> the section is explicitly marked as non-normative

<asir> oh

<Marsh> OK, starting as soon as street sweeper passes...

<Arthur> want me to change should to can ?

<umit> yes

<asir> that'll be cool

Operation Name Mapping Issues

LC82 - Operation Name Mapping has a bug


dbooth: summary of presentation.. conclusion. granularity is wrong. what you need to determine is the verb, not the operation. verb being a generic unloaded term.

daveo: verb is loaded

glen: we decided it's an issue and we should look at it

dbooth: Sanjiva used 'op-code' associated on a per-message basis at the abstract level. it's closely related to ws-addressing: how do you indicate action in WSDL which is on a per-message basis

marsh: no AI for sajniva on this or anything on the list about this?
... have we missed something, and how can we make progress

hugo: how is this different to ws-addr action?

<Arthur>fyi: ed to do for LC73/LC75n is done. See http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#single_interface_per_service

umit: we discussed if we could use anything unique as a defaulting mechanism.

hugo: following ws-addressing discussions, wouldn't wsa:Action be good enough?

glen: no

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

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

dbooth: this approach would solve what i was talking about

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

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

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

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

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

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.

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).

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

... maybe that a message may result in multiple 'actions'

<PaulD> +1 to dbooth, with feeling

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

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

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.

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!

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

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

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

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

paco: action is just one of many possible mechanisms

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

marsh: should we require actions to be unique?

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

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

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?

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!

<PaulDI'm coming round to amy's POV on this topic, but have yet to convince folks back home

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

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

glen: then we can toss out operations

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.

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

marsh: i need some concrete proposals here

dbooth: sanjiva was working towards one

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

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

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

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

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

tom: yeah, it gives you the 'verb'

daveo: people may or may not be using ws-addr

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

anish: action values don't have to be unique

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

... 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.

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?

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

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

... who cares if the outputs aren't unique

marsh: in the case where there are two outputs.

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

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

<prasad> I agree :)

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

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

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

discussion of 'client' and 'server' roles

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

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

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?

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

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

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

... problem is terminology is overloaded

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

tom: yup

<umit> ouch!

... that's the way it works

tom and anish play dispatch tennis across the room ..

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

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

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

tom: a complex MEP requires a corollation mechanism

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

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.

... 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!

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

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.

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

<Arthur> wsdl MUST support code generation

<alewis> horsefeathers, arthur.

tom: this relaxes what we currently have

... this may make amy happier

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

<Arthur> call me Pegasus then

... within an interface

<hugo> proposal #2 for me

<prasad> Distinguishable based on what criteria? GED?

<alewis> return at +25 after next hour?

<Marsh> Yes.

LUNCH, BACK at 13:30 local time

<umit> Ah, I may miss this fun

<prasad> Me too

<alewis> ugh.

<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

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 symmetrical exchange of messages.

Arthur: WSDL 2.0 as currently spec'ed ( 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.


<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

<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.

Jonathan: go on break then take the formal vote

<anish> --- break ---

<alewis> 30 mins?

<alewis> x:40?

<Roberto> wasn't it 20 minutes?

<alewis> x:30, then?

<Marsh> No, 20 min

<Marsh> yes,

<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

RESOLUTION: Convert the Operation Name Mapping Requirement 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.

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

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

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 intersection of the allowed value sets.

i.e. that is the semantics

but that may not be checkable in all cases

<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.

ACTION: Part 1 Editors to add the intersection rule for f&p composition.

<Marsh> Adjourned.

Adjourn at 5pm

Summary of Action Items

[NEW] ACTION: dbooth and KevinL to scope remaining primer work and
... identify who needs to supply what advanced topic sections
[NEW] ACTION: Part 1 Editors to call out the difference between WSDL 1.1 and 2.0 in respect to single interface per service, and indicate alternatives
[NEW] ACTION: Part 1 Editors to rewrite ONMR as above.
[NEW] ACTION: Hugo to write a proposal for adding an optional Action attribute in line with WS Addressing (LC84b)
[NEW] ACTION: Arthur and Asir to look for more edge cases ref LC20 and LC27.
[NEW] ACTION: Part 1 Editors to add the intersection rule for f&p composition.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.107 (CVS log)
$Date: 2005/01/19 23:41:00 $