See also: IRC log
<scribe> scribe: TonyR
Register early and often - Glen needs a count so he can confirm the room
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?
<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