<Marsh> Scribes: Paul, ?, DaveO, Arthur
<scribe> Scribe: pauld
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 rearranged for Roberto's benefit
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
STRAW POLL
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
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
BREAK
<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>
</div2>
<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
http://www.w3.org/2004/Talks/1110-dbooth-opname/slide25-0.html
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?
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 (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
<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.
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