?* 2004-11-11: Anish to propose additions to the test suite for
the purpose of interoperability testing,
due 2005-05-12.
?* 2005-03-31: Marsh to take on (or recommend closing) Bijan's AI
to produce a component/property table via XSLT,
due 2005-05-28.
DUE 6-28 2005-04-21: Pauld to craft, publish Common Schema structures
to WG for review for publication as WG Note,
due 2005-05-28.
DUE 6-9 2005-04-22: Amy to provide examples for the advanced section
of the primer. Amy to send them to Kevin and test
materials to Arthur, due 2005-05-19. (LC61c)
DONE 2005-05-05: Sanjiva to writeup a proposal for LC71,
due 2005-05-26.
?* 2005-05-12: Glen to add scoping example to primer,
due 2005-06-01.
?* 2005-05-19: Umit to provide #none for Primer, due 2005-06-01.
DONE 2005-05-19: DaveO to ressurect option to indicate GET more
directly, due 2005-06-01.
DONE [4] 2005-05-26: Marsh to ask Rich about the worst example for
LC89j, due 2005-05-31.
?* 2005-05-26: Paul to describe LC124 proposal in more detail
(where does the attribute go, what's the value
for normal Schema validation?), due 2005-05-31.
?* 2005-05-26: Glen to put an LC101 proposal on the table,
due 2005-05-31.
DONE 2005-05-26: Tom to provide a concrete proposal to address
LC82, due 2005-05-31.
DONE 2005-05-26: Marsh to ask DBooth if the concerns in LC84c
are still valid, due 2005-05-31.
[3] http://www.w3.org/2002/ws/desc/#actions
[4]
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005May/0087
.html
Paul's 2005-04-21 is reassigned for 2005-06-28
Amy's action item 2005-04-22 is due 2005-06-05
Discussion is for introducing the proposal and previous proposal on using two separate attributes
Arthur proposes that we dont call this an extension, and it should go to Part 1.
scribe: should be a required part of the specification.
Discussion as to how to accomplish this goes on.
Marsh: This is optional, we can not enforce it for code generation.
Arthur: It is not only for code generation, the information is useful at runtime as well.
... If you are sending an attribute at runtime, it needs to agree with the definition made statically at description time.
... The status quo now is a testable assertion. We can enforce it at runtime. In order to accomodate the counter proposal, there needs to be a similar characteristic for this proposal.
... The proposal should apply to URI, service type, endpoint type type.
... This can be used for XLink type references as well.
... Summary: We predefine for well known types. WS-Addressing should take care of its own types. We should use two attributes.
Umit supports friendly amendement to have two attributes (interface and binding)
Discussion on how EPRs will use this in WS-Addressing.
Arhur: 1) Two attributes
2) It should be in Part1.
3) We predefine service type, endpoint type and URI. Other specs can define for other schema types.
Anish: Does this change the idea that it applies to WSDL 1.1 ?
Arthur: It should be like in Part 1.
Umit: wsdli:Location is in Part 1 too.
Arthur: It is partially testable.
... This is part of the core language and belongs to Part 1.
Marsh: Does this have any CR criteria?
Arthur: Part 2 is about extension points that you plug in. Type systems, MEPs, bindings...
Anish: What is the namespace?
Marsh: A new namespace or WSDL namespace.
Anish: If this is used by wsdl 1.1, it is easier to accomplish this by restructuring just like location.
Umit: As Arthur suggests, put this in Part 1 and use wsdlx...
WG looks at the examples that Umit provided.
Glen: The attribute should apply to extension/restrictions. (subtypes)
DavidO: In Schema 1.1, they simplified xsitype and substitution by changing the refinement rules.
Roberto: We don't have a notion of sub bindings. Therefore, we don't have extension for binding.
Anish: Isn't the proposal should be interfaces should be compatible but the bindings should be exact?
Roberto: Leave the proposal as is and put two separate issues for binding extensibility and interface extensibility
Umit, Glen agree
Discussion on whether the addressing EPR and endpoint type should be reconciled.
Glen: There should be a single type
... The same structure can accomodate both runtime and design time constraints
David O: I like to have two different types.
Glen: The structure is going to be either in WSDL or will be available at runtime. It would be nice if it was the same structure.
Discussion as to whether there should be two separate types or a single type...
Hugo: We had an opportunity to make a LC comment and did not make it.
15 minute break
Arthur: At the time when we designed service refs, WS-Addressing did not exist.
We are stepping on their toes, we should encourage the usage of EndpointTypes
Glen: Why don't we just pull out Endpoint Type ?
Arthur: We are not going to get to having a single type right now. Lets not encourage using Endpoint types for runtime. We illustrate it for URI. We let WS-A define how to use them for EPRs.
... I will do a primer example for XLink and URIs.
Glen: It seems wrong WSDL to require a different namespace to use it.
Anish: We seem to discuss a different issue here just because we wanted to solve the original issue to designate in the schema the interface of the service.
... We are not solving the original problem anymore if we do not illustrate it beyond URIs.
Rehash of why we are here. Arthur explains how we ended up with extending two separate types due to Schema problem that was not anticipated.
Anish: I can not extend from two separate types, i have to choose one or the other.
... we should discuss the solution of the problem instead of discussing single type or not.
Proposal: Introduce two separate attributes interface and binding. We define what they mean in our spec for URI for element / attribute content. Illustrate them in the primer. Ask the WS-Addressing wg to illustrate how to use them at design time.
Umit: There are three different cases which we discussed: Static, semi static and dynamic cases
... The annotations allow us to use machinary to check for static and semi static cases.
Anish: I agree with the proposal. The question is why we don't say what the attributes mean on the endpoint element.
Arthur: We don't want to encourage the usage for endpoint type.
Glen: Nothing prevents me to do it.
Arthur: There is an overlap with WS-Addressing
Marsh: When you apply these attributes to an address this is how you use them. The presence of the attributes assert that it is an endpoint
... Instead of spec'ing an endpoint reference type, the presence of the attributes imply that it is an endpoint reference
Anish: We don't restrict their usage with types.
Umit: That is where i started from. Does it affect toolability?
Discussion on the granularity on what needs to be described in the specification beyond Jonathan's proposal
David O: Why is this useful with URIs?
Arthur: I am assuming that there is a WSDL and you have interfaces. You know your references at design time.
David O: It sounds like this is creating a hyperlinked choreography language as you know up front that you will get a document that contains a resource.
scribe: I don't see the value of this proposal with 80/20 HTTP Get.
Paul: I see some value with it, but I am not sure about the metadata
Arthur: This is about describing and using the metadata at design time.
... Endpoints are going to be part of the messages.
Anish: Q about the usage of URIs.
... In the message itself, you would get a WSDL construct in the message with the original design.
... With URIs, you will not a WSDL constructs. If at runtime they are not useful. Do you want to extend the URI to allow using these attributes to occur as part of URIs?
Arthur, Marsh: These attributes are used for static, semistatic case.
Anish: Why are we then distinguishing the usage of URIs? Wouldn't they use ERPs instead?
Arthur: For certain simple applications, using URIs is useful and sufficient instead of using EPRs.
Anish: This is also useful for dynamic case as well, then.
Lots of discussion what to put into the spec.
Anish: It is not a good idea to define it with URI but not with WSDL contructs.
Roberto: Define the annotation attributes, but do not provide usage.
The attributes are provided to designate endpoint references, not the other way around.
Anish: It is strange that we are not defining the usage in the spec with the specific constructs in WSDL.
... We have service type, endpoint type...
Proposal: 1) REmove service reference section
2) Define wsdlx:interface/binding. These attributes are intended to be used as annotations.
3) Illustrate the use of URIs with these attributes.
4) Make @name with service type required.
5) Pass the hot potato to WS-Addressing
6) Find the potato handler from WSD wg
2 should be described in Part 1
There is a separate WSDL namespace for this.
3) is handled in Primer.
Any objections to closing LC 117 by adopting this proposal?
RESOLUTION: LC 117 is resolved by adopting the proposal
However, he is scribing offline
<TonyR> Have I lost sound?
<TonyR> any chance of someone transcribing the options into IRC?
<TonyR> anyone paying any attention to the IRC?
<TonyR> Certainly no one seems to be paying any attention to the phone :-(
<bijan> IRC attendence seems lacking
<bijan> They having connectivity trouble?
<TonyR> apparently they are having trouble at Berlin
<bijan> *Tear down the (irc) wall!*
1 status quo
2 examine contents of operation
3 abs uri + token (a union or b relative URI with base)
4 srongly typed operation
5 default to in-out
6 DTD entities
7 strongly type input, output within operation
8 default added to interface
<TonyR> thanks for transcribing the options, umit - I appreciate it. Unfortunately, I don't understand the subtle differences
<bijan> 5, 4, 7, 1
are you abstaining Tony?
<TonyR> yes, I'm abstaining (I'm also a tad irritated - couldn't hear a lot of the debate, and no one paid any attention)
<TonyR> are you having trouble, umit? dropping in and out?
<TonyR> Umit is at the FTF
<Tomj> why isn't anyone else on?
<Tomj> no internet?
<Tomj> what adgenda item are they on?
<Tomj> that would be good
<TonyR> You missed a half day spent on LC117, and two hours on LC71
<Tomj> Did they resolve it?
<Tomj> how early were you up Amy? :-)
<TonyR> I thought it was from after lunch to afternoon break
<Tomj> what timne is it there? 3:00pm?
<Tomj> ONM! ha!
<TonyR> 7 and a quarter hours after start
<Tomj> Did they approve my LC82 proposal?
<Tomj> amy: bummer
<Tomj> 4:20 pm in berlin. I guess I have to get up earlier tomorrow.
<bijan> And the latter thought was a fire in my brain --- *burning* itself deep into my intellect and affective structure
<bijan> So, even though it was clearly a VERY BAD IDEA, I was compelled...*nay*...I was *transfigured* by it!
There are three options.
1. Move it to the primer and fix.
2. Leave it where it is, but make it accurate
3. Rip it out.
<Tomj> good, them I don't have to prefix everything with a "slash me"
<bijan> Heh
<Tomj> Hey Umit, tell Janathan that I am on the phone!
<bijan> /me doesn't think so
<Tomj> thanks
We are discussing LC82.
<alewis> 1, 2
<bijan> 2, 1
<Tomj> 2,1
<TonyR> 2, 1, 3, 4
<bijan> Tomj, what did you *think* would happen? :)
<bijan> So, you can get paradoxes
<bijan> A: 1, 2; B: 2, 1; C: 3, 1
<bijan> 1, 2 and 3 all lose in the first round
<bijan> Second round 2 gets two votes and 1 one
<bijan> So 2 wins
<Tomj> yeah, I am just worried that the weighting will give a bunch of people who vote the second choice
<bijan> But A prefered 1
<Tomj> enough weight to make it win
<bijan> And *if* she'd voted for 1 in the second round, it woudl have won
<Tomj> far too much math for a voting thingy
<alewis> tom, the point of sv is to remove false polarity in voting.
<alewis> it lets people vote for what they *prefer*, rather than voting for something that they hate but that they think is more likely to win, for some reason.
<bijan> tomj, votings is ALL about heavy math :)
<TonyR> bijan's analysis is incorrect.
<Tomj> I thought I had it internalized, but I guess I was reading about some of the strange things that can happen and it muddied my thinking
<bijan> Really? Oops
<Tomj> So move it to the primer won, right?
<TonyR> The algorithm in use says, in your example, pick one randomly and kill it, transferring its votes to next valid preference
<bijan> pick one voter?
<bijan> Or one candidate?
<TonyR> one candidate
<bijan> HMM.
<alewis> yeah, i saw that. with the vote evenly split, it would randomly drop one, but then looks at second place, and decides not to drop #1, then decides not to drop #2, so #3 is dropped, and #1 wins.
<TonyR> if there are multiple "least votes" candidates, pick one randomly
yes, we are moving to the primer option 1 wins
<TonyR> No - doesn't attempt to second-guess - just choose one randomly from the "lowest"
<alewis> TonyR: yes, but (depending on the algorithm) it can look forward. chad does, for instance. so it isn't random at all, in that case.
<alewis> in the particular example bijan gave, i believe that chad *does* do look-forward.
<bijan> http://en.wikipedia.org/wiki/Single_transferable_vote
<TonyR> I'd be surprised - that's certainly not my understanding
<alewis> TonyR: if it can avoid complete randomness, it does.
<TonyR> hmmmm :-)
<bijan> STV doesn't obey the monotonticity creterion (don't knwo about chad's algo specifically)
<bijan> So something analogous to my example presumably can happen
<alewis> chad's based on modified stv, though. partly because true randomness tends to unnerve people.
<bijan> Yeah!
<bijan> http://en.wikipedia.org/wiki/Instant-runoff_voting
<bijan> No kidding.
<bijan> "In case of tie, flip a coin"
<bijan> http://www.electionmethods.org/IRVproblems.htm
<TonyR> Bye
<Tomj> the defaulting?
<bijan> Who knows!
<alewis> yes.
<Tomj> I would like simple names: "in", "in-out"
<alewis> well, it's not happening.
<Tomj> Then we wont have to default anything because it will be simple
<Tomj> AMy, you wanted to keep URIs?
<alewis> i can live with uris or with short names.
<alewis> i can live with the decision taken, for that matter.
<Tomj> yeah. How did in/out win? or were you napping. :-)
<alewis> what i couldn't live with was the wsdl 1.1 disaster.
<Tomj> ha!
<bijan> Piffle! More beach time :)
<alewis> if i understand the decision, all that's happened is that, if the @pattern attribute is absent, it defaults to [uri of in-out pattern]
<Tomj> ok
<Tomj> I just wonder how that got support over just aliasing the 4 MEPs to simple names
<alewis> which means it's still possible to look at an operation and validate the number and type of input and output operations that it contains.
<Tomj> ahhh
<alewis> i don't know. as tony mentioned, i fell asleep. i was trying to take a nap, to be a little sharper, and instead went blotto for an extra two hours. /me is stupid.
<Tomj> well, you are in EDT right, so 5 AM is a hard time to nap
<alewis> should've run around the block or something instead. oh, well. it's not likely that i could have changed things that much, anyway.
<bijan> 5 am is a *great* time to nap
<bijan> Unless you want a *short* nap :)
<Tomj> :-)
<alewis> and of possible bad decisions, that one is less bad than others. so all's for the best, in this best of all possible specifications. :-)
<Tomj> ok, well it doesn't look like too much damage has been done, other than the ONM moving farther away from reality
<Tomj> but hey, we are all sick of it anyway. :-)
<bijan> OH yeah
<alewis> *shrug* so long as onm is best-practice rather than a requirement, our customers won't lynch me (or require us to be non-conformant to spec)
<Tomj> I hear you.
<alewis> okay. now off to check mail, i guess. see y'all tomorrow? fsvo "see" and "tomorrow" ?
<Tomj> I be around for a bit
<Tomj> probably late :-)
<bijan> Heh
<bijan> Yep
<bijan> I'm going to try for the start time
<bijan> But I doubt I'll make it
<bijan> It'll be 12am and I'll settle down for a " nap"
<Tomj> no spec is worth 3am wake up call for me!
<bijan> Well, true
<alewis> eh. agreeing to do that got me out of having to travel.
<alewis> anyway. tomorrow and tomorrow and tomorrow. good day, sweet prince[s]
<Tomj> I regret not making the effort, but I am trveled out.
<Tomj> bye
<bijan> Heh
<bijan> Oh yeah
<Tomj> it used to be fun!
<bijan> I was in japan for two weeks a week ago
<bijan> And I have to be in austria next week
<bijan> So it was a bit insane
<bijan> I remember it being fun :)
<Tomj> :-)
<Tomj> later!
<bijan> ta
Dave draws on the whiteboard:
<interface name="foo"> <operation ... pattern="uri"> <input> <output> </operation> </interface>
This sucks - full URI on pattern attribute required on every operation is too much.
Solutions include:
1) Status Quo
2) Examine contents of operation, determine default
Jonathan: This only gets you part way. No ordering.
Glen: No ordering? Really?
Jacek: XML has ordering, component model does not. Could use that.
Dave: Amy doesn't like having to "look ahead" to determine the pattern.
3) Change type from absolute URI to some shorthand "in-out", etc
Could work a variety of ways.... xml:base for just this attribute pointing to the base MEP URI, etc...
3a) use union or full URI
3b) use xml:base (where base value is defined by our spec)
4) Make pattern uri optional, roll this info into specific operation type names "<InOutOperation>", etc
Anish: So what's wrong with looking ahead? (to Amy's objections)
Dave: Any other options?
Jonathan: If the 80/20 split is in-out, default the attribute value to in-out (option 5)
Youenn: Could predefine WSDL XML entities for URIs of patterns (implies DTDs) (option 6)
Roberto: Status quo is clear, choosing between these is tricky. Stick with it.
Paul: Interesting that this is a string not a URI....
Jonathan/Dave: Like namespaces, for comparisons, etc.
Dave: More options?
Jonathan: What if the pattern URI was the namespace for a qname on the input/output?
<input messageLabel="in"> (status quo)
as opposed to
<inout:input> (namespace wraps up pattern semantics)
(this is option 7)
Roberto: Option 8 is introduce a patternDefault attribute on interface, which is an absolute URI
Jacek: Repeating the MEP when making real WSDLs was a pain in the butt. Syntactic sugar is good. Strong typing of operation sounds nice because we already do that for the <input>/<output> elements which themselves imply direction because of the element names.
Anish: Syntactic sugar is good. If we can optimize the common cases that would be really great. I like option 2 - what's the problem with looking ahead to figure out the default pattern URI?
Dave: (quotes Amy's objections involving validation and clarity)
Glen: Yup - you might have an in-out and forget the out. If we had, say, strongly typed operations, then schema validation would catch it - if you default it might just give you the wrong thing.
Jean-Jacques: I like option 4. Is it correct that this wouldn't have an impact on the component model?
(general assent)
Hugo: I like 3 except I can't see how a generic XML processor can make sense of it.
Jonathan: Don't like using base... if we can restrict just using schema (3a), that's better.
Dave: Two different URIs for the same thing - absolute one and shorthand... ?
Hugo: continues: Option 4 seems to go against the genericity of WSDL...
Youenn: Would there have to be a binding equivalent <bindingInOutOperation>?
Hugo: I like option 8, because that seems like it's in the spirit of what we've done other places.
Dave: Option 1 is my least favorite. Like 4, can live with 2, 3. Haven't thought through 8.
Anish: Least amount of changes seems like a good thing. At this point we shouldn't be changing the structure.
Umit: Adopting 3a doesn't preclude adopting 8. That would be my choice.
Jonathan: Defaulting mechanisms are challenging to remember all the rules for... 5 is very predictable. Predictable seems good.
Arthur: Amendment to 8 - make patternDefault optional and default to in-out.
Roberto: No. Would be an exception to all the other cases where we have defaulting.
Glen: Like option 4, but Youenn's question needs serious consideration.
Youenn: Like option 6.
Anish: Isn't option 6 really option 1 with some simplification to the XML?
Youenn: Yes, and compatible with everything that exists today.
Roberto: Can't we already do this?
all: Yes
[VOTE]
Arthur: 5,1,8
Hugo: 8,1,6
Dave: 4,3,5
Jacek: 4,5,3
Rebecca: 8,5,1,2
Anish: 1,6,8,5,2
Jean-Jacques: 4,5,6
Youenn: 6,5,1
Umit: 3
Paul: 5,1
Roberto: 8,1,6,5,3
Glen: 4
Jonathan: 5,1,3
Bijan: 5,4,7,1
5 wins - default to in-out, use pattern attribute otherwise
(discussion of new dependency on part 2)
RESOLVED: Accept this solution for the resolution of LC71.
Umit says "I object".
FORMAL VOTE:
Iona: Yes
Sonic: Abstain
Sun: Yes
UMD: Abstains
BT: Abstains
Canon: Yes
Microsoft: Yes
W3C: Yes
Oracle: Yes
DERI: Yes
SAP: No
BEA: Abstain
CA: Abstain
IBM: Yes
8 yes
1 no
5 abstain
<BREAK>
[Proposal from Tom]
Roberto asks to see current status of ONM text
[discussion of editorial tweaks, which will be put off until substantive issues are dealt with]
Glen: There are a number of other issues relating to this - let's do the high-order bit ones first (involving action / identifying messages rather than operations) and that should just solve Arthur's bug
[discussion of Hugo's proposal]
Roberto: The scope within which a message is unique is dependent on the context - i.e. first messages within an interface vs. first messages when a given endpoint is implementing four interfaces... hard to specify this in general, hence the best practice.
Arthur: Rip this out - it just attempts to stop people from shooting themselves in the foot, and we can't really do that.
Roberto: component designator gives you a unique value
Anish: Yes, but the best practice says (or doesn't) what you do with that - i.e. you should somehow map that to something derivable from the message on the wire
Glen: We could turn this into a more abstract statement about the fact that we should really be able to tell which message is being dealt with from the wire signature/context, and to be careful when designing and deploying services to enable this.... give examples, explain using action, etc.
[more discussion]
Anish: We should, for a given WSDL, be helping people determine the mechanism by which they are going to do this message resolution.
Umit: Why is it a bad idea to explicitly declare an action at the abstract level?
Roberto: It's not a bad idea to declare action at the binding level, but if it's meant to identify messages we've already got a designator for that, so why do it again at the abstract level?
Umit: Move this to the primer?
Anish: Intention of this is very different from primer... spec is a better place for it to be.
Jean-Jacques: Would fit well with primer, with the addition of a few examples.
[discussion of the difference between action/"intent" and the message component itself]
Hugo: intent should be at the abstract level, because the intent is independent of any mapping that you might do... independent of QNames, for instance
Jonathan: Fact is, people want to use this for dispatch, not so much for some abstract concept of "intent".
1) Move it to the primer and fix it
2) Leave it in the spec and fix it
3) Remove it
Glen: 2,1
Paul: 3,1
Umit: 1,2
Youenn: 1,2
JJM: 1,3
Roberto:3,1
Anish: 2,1
Rebecca:1,2,3
Jacek: 1,2
Hugo: 1,2
Arthur: 3,1,2
Tom: 2,1
Amy: 1,2
Tony: 2,1,3
Bijan: 2,1
Marsh: 3,1
1 wins
Objections to moving this to the primer and fixing it? No.
[discussion of how this work gets done]
[scribe begins to fade from jetlag]
ACTION: Umit to incorporate these three points into new text - 1) it's about the message, dammit, not the operation, 2) it's context-dependent, 3) for the contexts which we define as common, here are the things to be thinking about (unique GEDs, etc)
[discussion of action property in the abstract level]
Jonathan: Propose closing this with no action?
[discussion of Sanjiva's and Hugo's proposals]
Jonathan: Objections to closing 84b with "no action"?
84b is CLOSED.
Jonathan: propose to close 84c with resolution to 82
84c is CLOSED unless we hear back from David after he sees the new text.
ADJOURN FOR THE DAY