W3C

WS Description telcon

30 Jun 2005

See also: IRC log

Attendees

Present:
Rebecca Bergersen, IONA Technologies
Allen Brookes, Rogue Wave Software
Roberto Chinnici, Sun Microsystems
Glen Daniels, Sonic Software
Paul Downey, British Telecommunications
Youenn Fablet, Canon
Hugo Haas, W3C
Anish Karmarkar, Oracle
Jacek Kopecky, DERI Innsbruck at the Leopold-Franzens-Universitšt Innsbruck, Austria
Amelia Lewis, TIBCO
Kevin Canyang Liu, SAP
Dale Moberg, Cyclone Commerce
Jean-Jacques Moreau, Canon
David Orchard, BEA Systems
Bijan Parsia, University of Maryland MIND Lab
Tony Rogers, Computer Associates
Arthur Ryman, IBM
Umit Yalcinalp, SAP
Regrets
Tom Jordahl, Macromedia
Sanjiva Weerawarana, Invited Expert
Chair
JMarsh
Scribe
TonyR

Contents


 

 

<scribe> scribe: TonyR

Action Items

Upcoming face-to-face

Register early and often - Glen needs a count so he can confirm the room

Publication Details

We'll be voting on the documents at the next meeting - be ready to vote to move them to Last Call

umit: also uncomfortable

<GlenD> I like it (Java as an example)

marsh: maybe we don't need an example?

<Roberto> For the benefit of the minutes, let me say that my discomfort is not with using the Java language as an example, but with the fact that the proposed constructs (wjava:class, wjava:import) do not match those in the language specification. Consequently, their semantics are unclear.

jacek: not going to lie down in the road on this - it was just a hyptohetical example

marsh: so do we add it? Or not?

<uyalcina> +1 to roberto

marsh: let's publish without the example (no objections)

kevin: any objections to the primer restructuring?

LC124

<scribe> chair: only big difference relates to possibility of server generating unknown items as well as accepting them

marsh: willing to relinquish proposal in favour of DaveO's, but was thinking of tooling

DaveO: was thinking of the same thing, but came to a different conclusion
... if using tooling, probably entire WSDL would be generated by one tool - therefore all endpoints would have same capabilities
... seems very unlikely to use different tools for different endpoints
... well, even if done, there's a workaround through using different WSDL files

marsh: can accept that

roberto: "unexpected" is confusing - prefer "unknown"

<dorchard> jonathan, make sense to change unexpected to unknown?

roberto: there are good use cases for having it on both types and end points

marsh: nasty to compose if on both - which would be preferable
... imagined it as a "quality of service" item, hence endpoint

daveO: imagined it as part of the contract - part of the definition - hence at the interface or type level

roberto: both seem "right"

glen: agree

marsh: do we reconcile the proposals by allowing on both? What is the rule for composition?

omnes: discussion of what the composition rule could be

<dorchard> IU #1: Marsh proposal : default is on, set to off in endpoint

<dorchard> IU #2: Orchard prop: default is on, set to off in types

<dorchard> IU #3: combo prop: def is on, set to off in types and endpoints

<dorchard> IU #4: combo prop: def is on, set to off in types and endpoints but endpoint can't set to ON.

<pauld> chad, question LC124 proposals for composition

<pauld> chad, question: LC124 proposals for composition

<pauld> chad, option 1: Marsh proposal : default is on, set to off in endpoint

<pauld> chad, option 2: Orchard prop: default is on, set to off in types

<pauld> chad, option 3: combo prop: def is on, set to off in types and endpoints

<dorchard> IU#3: last one wins...

<dorchard> paul, make sure the #3 calls out that the endpoint can set to on over-riding the types setting it to off.

<pauld> chad, option 4: combo prop: def is on, set to off in types and endpoints but endpoint can't set to ON.

<pauld> chad, option 3: combo prop: def is on, set to off in types and endpoints (last one wins)

<pauld> chad, options

<dorchard> we'll get to the queue once these two have bashed at it for a bit.

<GlenD> however I at least would like to point out something that would perhaps stop the bashing

<dorchard> ok

<pauld> chad: 2, 4

<dorchard> roberto & umit in favour of #4

<pauld> Chair: Jonathan, DaveO

<pauld> chad, option 5: combo prop: def is on, set to off in types and bindings (last one wins)

arthur: major change if this is defaulted to ON

glen: yes, object to ON by default

<GlenD> So Paul, you like this as on by default, then?

<pauld> yes

<pauld> that's what i understood we'd agreed on last week's call

<pauld> chad, option 5: combo prop: def is on, set to off in types and bindings (last one wins)

<GlenD> paul - hm... OK, I guess my problem with it involves describing existing services - we'd need to switch the option OFF for every one of those since they weren't built with this assumption... but I guess maybe that's not so bad.

<charlton> bijan, i think this has already been discussed

<bijan> Oh, ok

daveO: override at binding and/or endpoint
... interface should be consistent across all bindings - therefore not change
... at the binding

umit: agree with arthur, but bear in mind that capabilities when WSDL 2.0 arrives will be different
... data binding tools are changing, will be different in a year's time

<pauld> existing services would work OK, as we learned at the workshop Microsoft and most other tools work this way already. Notably in my experience Axis 1.x is one of the few binding tools which barfs on extra input

arthur: will need to review this before accepting

<charlton> :-)

arthur: view the interface as an abstract definition of the message

<GlenD> paul - hmm, maybe we should change that in Axis 1.2.2.....

arthur: see the binding as a materialisation of the abstract

paul: looking to forbid toolkits which aren't flexible enough to handle the ignoreUnknowns

<alewis> chad, list options

arthur: keen to be sure people understand the impact of defaulting to ON - this is NOT an extension then

<JacekK> vote: 4

<bijan> vote: abstain

arthur: not happy with this different attitude to validation

daveO: PSVI gives more than just "valid" / "invalid"

umit: why not make this a predefined extension, not include directly in the spec?
... this is beyond today's well-defined semantics, so should be an extension

daveO: perhaps we need two polls: first whether the default is on or off, then details

umit: yes - decide whether this is an extension or part of spec

arthur: agree with paul, people need to able to version schema. But we do need to be able to define validity

<dorchard> I think we are hearing the same points expressed over and over...

paul: but what tools do is not validation

arthur: people do want to be able to specify constraints (eg: content size)

marsh: but different sizes is not being considered as acceptable under Ignore Unknown

<Zakim> alewis, you wanted to object to david's characterization of schema

amy: object to characterisation of PSVI
... defaulting this to ON is very different - big change

marsh: Schema working group do not see validation as boolean

<dorchard> straw poll time?

<pauld> the strict validation case is allowed for currently. my 99% use-case is for open content and that isn't possible at the moment

marsh: validation is not a boolean value function

<charlton> i agree with jonathan's assessment

<pauld> schema WG members liked the LC124 proposals precisely because it raised awareness of the PSVI

roberto: validation is important, but many tools today are "lax" - there will be plenty of tooling by the time WSDL 2.0 is final

marsh: straw poll: is this core, or an extension?

<pauld> chad, question: is this core or an extension

<dorchard> Isn't the staw poll: is ignoreUnknowns the default or not?

<pauld> chad, new poll

<chad> new poll

<pauld> chad, question: is this core or an extension

<Marsh> chad: option 1: in the core

<Marsh> chad: option 2: extension

<Marsh> chad: option 0: status quo (no facility)

<alewis> vote: 2, 1

<Arthur> vote: 2, 0

chad: 2, 1, 0

<dmoberg> chad 2

<Allen> vote: 1, 2

<bijan> vote: 2, 1, 0

<dorchard> vote: 1

<pauld> chad: 1, 2

<RebeccaB> vote: 2,0

<youenn> vote: 1,2

<dmoberg> chad: 2

<jjm> vote: 1, 2

<bijan> vote: 1, 2, 0

<pauld> chad: 1

<Roberto> chad: 1, 2

<GlenD> vote: 2,1,0

<charlton> chad: 1, 2

<hugo> vote: 1, 2

<pauld> chad: 1, 2

<JacekK> vote: 1

<anish> vote: 3

<Marsh> chad, count

<chad> Question: is this core or an extension

<chad> Option 0: status quo (no facility) (0)

<chad> Option 1: in the core (10)

<chad> Option 2: extension (6)

<chad> 16 voters: alewis (2, 1) , Allen (1, 2) , Arthur (2, 0) , bijan (1, 2, 0) , charlton (1, 2) , dmoberg (2) , dorchard (1) , GlenD (2, 1, 0) , hugo (1, 2) , JacekK (1) , jjm (1, 2) , pauld (1, 2) , RebeccaB (2, 0) , Roberto (1, 2) , TonyR (2, 1, 0) , youenn (1, 2)

<chad> Round 1: Count of first place rankings.

<chad> Candidate 1 is elected.

<chad> Winner is option 1 - in the core

<pauld> chad, new poll

<chad> new poll

<pauld> chad, option 1: Marsh proposal : default is on, set to off in endpoint

<pauld> chad, option 2: Orchard prop: default is on, set to off in types

<pauld> chad, option 3: combo prop: def is on, set to off in types and endpoints (last one wins)

<pauld> chad, option 4: combo prop: def is on, set to off in types and endpoints but endpoint can't set to ON.

<pauld> chad, option 5: combo prop: def is on, set to off in types and bindings (last one wins)

<pauld> chad, option 1: Marsh proposal : set on endpoint

<pauld> chad, option 2: Orchard prop: set on the types

<Marsh> chad: chad, option 3: combo prop, set on types and endpoints

<Marsh> chad: chad, option 5: set on types and bindings

<Marsh> chad, drop option 4

<Marsh> chad, list options

<Marsh> chad, option 3: combo prop, set on types and endpoints

<Marsh> chad, option 5: set on types and bindings

<Marsh> chad, list options

<alewis> chad, option 4: can set in endpoint only if unset in types

<Marsh> chad: Question: which of these options would you prefer to see in the next version of the proposal

<hugo> vote: 3, 4, 2, 5, 1

<bijan> Becasue we don't get multiple answers, right?

<dorchard> 4,3,2

<Roberto> chad: 4, 3, 1, 5

<dorchard> vote: 4,3,2

<uyalcina> chad: 2, 4, 1

<dmoberg> chad: 4, 5

<JacekK> vote: 3

<Allen> vote: 4, 3

chad: 3, 4, 5, 2, 1, 0

<youenn> vote: 2,3,4

chad: 3, 4, 5, 2, 1

<Marsh> vote: 1, 5, 4

<Arthur> vote: 5, 2, 4, 3

<dmoberg> bye

<jjm> vote: 2, 3, 4

<charlton> chad: vote 2, 4, 1

<alewis> vote: 4, 3

<RebeccaB> vote: 5,3,2,1

<charlton> chad: 2, 4, 1

<GlenD> vote: 3,4,5,1

<bijan> vote: 3, 5, 2, 1

<pauld> chad: abstain

<alewis> chad, show details

<Marsh> chad, count

<chad> Question: which of these options would you prefer to see in the next version of the proposal

<chad> Option 1: Marsh proposal : set on endpoint (1)

<chad> Option 2: Orchard prop: set on the types (4)

<chad> Option 3: combo prop, set on types and endpoints (5)

<chad> Option 4: can set in endpoint only if unset in types (5)

<chad> Option 5: set on types and bindings (2)

<chad> 18 voters: alewis (4, 3) , Allen (4, 3) , Arthur (5, 2, 4, 3) , bijan (3, 5, 2, 1) , charlton (2, 4, 1) , dmoberg (4, 5) , dorchard (4, 3, 2) , GlenD (3, 4, 5, 1) , hugo (3, 4, 2, 5, 1) , JacekK (3) , jjm (2, 3, 4) , Marsh (1, 5, 4) , pauld () , RebeccaB (5, 3, 2, 1) , Roberto (4, 3, 1, 5) , TonyR (3, 4, 5, 2, 1) , uyalcina (2, 4, 1) , youenn (2, 3, 4)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Eliminating candidate 1.

<chad> Round 3: Eliminating candidate 5.

<chad> Round 4: Eliminating candidate 2.

<chad> Candidate 4 is elected.

<chad> Winner is option 4 - can set in endpoint only if unset in types

<alewis> chad, show details

<scribe> ACTION: DaveO to write up a new proposal for LC124 for LC124 [recorded in http://www.w3.org/2005/06/30-ws-desc-minutes.html#action01]

<pauld> I abstained becasue I can't imagine why you'd want to turn it off

Summary of Action Items

[NEW] ACTION: DaveO to write up a new proposal for LC124 for LC124 [recorded in http://www.w3.org/2005/06/30-ws-desc-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/06/30 16:47:06 $