See also: IRC log
July 11 minutes approved
July 18 + 19 minutes approved
no issues with drafts
status section okay
substantive change okay
features at risk
no more features identified at risk
<anish> how are we identifying features?
four interoperable implementations enough?
<RebeccaB> +1 on Jeff's requirement
each implementation has to support all features?
That is, all features identified on test suite
mnot: 4 implementaitons of every feature; 2 complete implementations?
<mnot> Text from Charter: A test suite intended to promote implementation of the Candidate Recommendation, and to assess interoperability between these implementations. The Working Group is expected to demonstrate four interoperable implementations during the Call for Implementations step.
<Zakim> anish, you wanted to ask about how we identify features
anish: how will we identify features? 4 interoperable implementaitons for each feature?
uyalcina: what is process with CR?
mnot: explaining process
plh: looking for complete implementations, but may make exception for optional features
<uyalcina> I presume "should" is considered to be optional for this discussion?
<anish> umit, that is a good question, i think this is the sort of thing that we need to decide when we identify features
<pauld> heard the sound of combinations exploding ..
<uyalcina> people are talking about "required" vs. "optional". I would like to clarify what that means.
various combinations of required, optional features discussed, and
and how the four implementations are mapped to the features
mnot: recommendation is per implementation, not per feature
should optional features be required to have an implmentation count as one of the four interoperable implementations?
mnot: if both mandatory and optional features are required in 4 implementations, we may want to mark some of the optional features as "at risk"
marsh: nothing wrong with
... there is a demand for profiles in the industry, as seen in the mobile phone industry
jeff: we have an obligation to ensure we have real interoperability
TRutt: optional features need to have at least some implementation; maybe only 2-3 impementations supporting them
Paco: 4 full implementations should be a given, but there should be some flexibility - so we are not gated by waiting for four full implementations of every feature
<jeffm> thank you :-)
daveo: if there is aproblem with
some optional feature, we should catch that. SOAP 1.2 had the
bar of at least 2 interoperable implementations of each
feature. We should have a higher bar.
... 4 implementations of mandatory features is needed.
anish: 4 impl. for each mandatory feature
mnot: 4 instances of implementations with all mandatory features plus ...
<Zakim> plh, you wanted to ask the Group about who is planning to provide an implementation
mnot: plus 4 implementations (not necessarily full) of optional features
plh: who is planning implementations?
answers from: IBM, BEA, Apache, Microsoft, also Oracle (not committed to full implementation)
fujitsu, hitachi also speak up
<jeffm> a more precise statement for Oracle is no data for complete impl -- just not sure what our product plans are at the moment
<Arun> Sun also said they'll have an implementation
Also, iona, sun
mnot: we are not asking for
commitments, these are directions of product plans
... what is appropriate bar for numbers of implementations? 4 full and 4 for each optional feature.
<anish> there is no such thing as 'feature' in the charter
jeff: 4 implementations of everything
mnot: 4 implementations of entire stack with all options
the requirement is not for products, but for W3C to be able to assert that there is an interoperable base, to vet the spec
plh: uncomfortable if not have 4 complete implementations of required features
<Zakim> pauld, you wanted to ask about consequences
Marsh: worried about extending schedule if we only have 3, then waiting for another one; if we can be more flexible with support for optiona features we can finish earlier
PaulD: what are consequences of not having the implementations all complete? What is the definition of a "feature" (as anish asked)?
<uyalcina> +1 to Paul. I have exactly the same concerns.
<jeffm> seems like SHOULDs are optional
<jeffm> MUSTS and MUST NOTS are mandory
<TonyR> Isn't "MUST" mandatory, "SHOULD" or "MAY" optional
<Marsh> I like a slightly higher-level concept of feature, possibly wrapping several MUSTs and SHOULDs.
<jeffm> MAYs are also obviously optional
<jeffm> sure --
mnot: we will need to define this clearly, since we have not always used RFC2119 language precisely.
<vikas> +1 to Pual
<uyalcina> Itis not simple. Take ReplyTo. Is it optional with respect to the core ? Is that a feature? Our charter talks about async. Is it required?
PaulD: we may need to have the test suite in front of us to identify or mark each one as required/optional
mnot: that would require us to NOT go to CR now.
<jeffm> i'm not trying to imply its simple -- i'm just starting with the obvious consequences of MUST/SHOULD/ etc.
<uyalcina> Agreed Jeff. However, the specs are not writted with the RFC2119 language to make the determination well.
TRutt: there is not much that is optional in this spec... The options are on the sending side. Maybe every receiver must be able3 to handle all options?
<Marsh> +1 to mostly academic
<dhull> +1 to Tom. The direct constraints are on the receiver.
<anish> we need to look for assertions beyond 2119 assertions as well -- for mandatory features
mnot: maybe based on test suite, it will determine if we can get out of CR phase (?)
<Zakim> dorchard, you wanted to point out that "to demonstrate four interoperable implementations" can easily be interpreted as 4 interopable impls of each feature.
uyal: need better definition of required/optional
dorch: charter is not clear about "full implementations"
<MSEder> Thats why I asked plh to answer that
<Arun> stepping out for a minute
jeff: the reason for setting
these quality criteria is to show that we have it right, by
getting several inplementations interoperating.
... possible compromise - we need to clarify what is in the charter, because there are various interpretations - suggest 4 full implementations of mandatory, plus:
<Arun> back now
jeff: plus 2 implmentations of each optional features (?) (missed a bit, this is 4-4-2 proposal)
Marsh: waiting for
implementations will delay the spec; some will wait to
... 2 absolutely complete plus 2 with all mandatory (4-2)
<prasad> +1 to above. IMO Optional stuff cannot exist independent of Mandatory one. Sometimes we seem to be speaking as if they are disjoint and implemented and tested independently.
Marsh: 4 with all mandatory, plus 2 of those with all required features (this is 4-2)
<anish> there are three proposals: 4-4-2, 4-4 and 4-2
jeff: agree except that charter says 4
<vikas> Do we need to agree on a use case to showcase these implementations? How do we define a features is implementable?
mnot: mlh said that 4-2 is likely to be acceptable
PaulD: still concerned about setting the bar too high, slowing things down, what is process for deleting features to get through CR?
<uyalcina> If we can identify what is optional, then you can mark them at risk, which is not easy...
<jeffm> that seems reasonable, in a weird way --
plh: if features are noted as at risk, they can be dropped during CR, but cannot get out of CR if they are not marked at risk and are dropped
<jeffm> it meets the quality bar which is my concern
<TRutt> I can live with 4/2
mnot: how do people feel about 4-2?
<bob> just drop all of the optionals now and be done with it
<Katy> I like the 4-2 proposal
jeff: 4 complete implementations of all mandatory features; two of those also implement all optional features. This is 4-2.
<Zakim> uyalcina, you wanted to ask a question.
jeff: straw poll?
uyal: if we do 4-2 should we mark features at risk?
<pauld> i'd be happy to accept Jonathan's proposal AIUI, but worry what happens if one or two optional 'features' don't hit the 2 bar
<uyalcina> I do not want to mark optional features at risk. It is solving a problem in the wrong way.
<jeffm> to respond to paul: then we've learned that they are not well specified, and they need to be fixed/dropped
<RebeccaB> I really don't like the idea of marking all of the optional features 'at risk' so they can be dropped later!!
<pauld> chad, say hi
<Marsh> chad: option 2: 4-4 proposal: 4 complete of mandatory features, + 4 implementations of each optional feature.
<TonyR> chad: option 0: status quo
<Marsh> chad: option 3: 4-2 proposal: 4 complete of mandatory features, of which 2 also implement all optional features.
<mnot> chad: option 1: 4-4-2 proposal: 4 complete of mandatory features, + 4 implementations of each optional feature, + 2 complete implementations of each optional feature
<pauld> chad, question: meaning of "4 interoperable implementations" for CR exit
<TonyR> chad: options?
<uyalcina> +1 mnot
<abbie> vote: 3
<vikas> vote: 1
<RebeccaB> vote: 3
<jeffm> vote: 1,3,2
<Marsh> vote: 2, 3
mnot: one vote per company
<mlpeel> vote: 3, 2
<Arun> vote: 3,1,2
<TonyR> vote: 3, 1, 2, 0
<prasad> vote: 2, 3
<MSEder> chad MSEder votes: 3
<uyalcina> vote: 3
<Nilo> vote: 2, 3
<TRutt> vote: 3,2
<Paco> vote: 3, 2, 1, 0
<dorchard> vote: 3,2
<pauld> vote: 2,3
<dhull> vote: 3, 2, 1
<bob> vote: none of the abov
<GlenD> vote: 3,2
<Pete> vote: 2,3,1
<MSEder> vote: 3
<uyalcina> vote: 3, 2
<pauld> chad, option none: none of the above
<pauld> vote: bob: none
<pauld> chad, count
<chad> Question: meaning of "4 interoperable implementations" for CR exit
<chad> Option 0: status quo (1)
<chad> Option 1: 4-4-2 proposal: 4 complete of mandatory features, + 4 implementations of each optional feature, + 2 complete implementations of each optional feature (2)
<chad> Option 2: 4-4 proposal: 4 complete of mandatory features, + 4 implementations of each optional feature. (5)
<chad> Option 3: 4-2 proposal: 4 complete of mandatory features, of which 2 also implement all optional features. (11)
<chad> Option none: none of the above (1)
<chad> 20 voters: abbie (0, 3) , Arun (3, 1, 2) , bob (none) , dhull (3, 2, 1) , dorchard (3, 2) , GlenD (3, 2) , jeffm (1, 3, 2) , Marsh (2, 3) , mlpeel (3, 2) , MSEder (3) , Nilo (2, 3) , Paco (3, 2, 1, 0) , pauld (2, 3) , Pete (2, 3, 1) , prasad (2, 3) , RebeccaB (3) , TonyR (3, 1, 2, 0) , TRutt (3, 2) , uyalcina (3, 2) , vikas (1)
<chad> Round 1: Count of first place rankings.
<chad> Candidate 3 is elected.
<chad> Winner is option 3 - 4-2 proposal: 4 complete of mandatory features, of which 2 also implement all optional features.
<anish> chad, details
mnot: go with 4-2 proposal
No objections to accepting this as the group concensus
mnot: lock period until end of September?
<TRutt> I like november lockin
<prasad> +1 to Nov
mnot: lock until November
... NOv. 1 as end of lock period?
... this is lower bound, not upper
no objections to Nov. 1 as lock period
<RebeccaB> +1 to Nov.1 - that's a quarter from now
mnot: estimates of earliest
... same - NOvember 1?
... we will expect to have some implementation data, enough to move forward, at that date. This is not binding (except lock period).
no objections to Nov. 1 as early implementation date
PaulD: can we keep to schedule?
mnot: clarifying dates: not go to PR before Nov. 1 (lock date); also expect to have some implementation experience at that date
<prasad> Wonder if we should set a realistic than an optimistic date? Why set a date we are liekly to slip?
no objection to these dates (Nov. 1 for both)
mnot: Does anyone object to requesting a Call For Implementations on the Core and SOAP binding documents?
No objection to going to CR.
mnot: take off first 3 weeks of
august, 1,8,15 . ??
... calls on 22 and 29 august shorter (1 hour); maybe cancel 29 august if enough done during aug 22 meeting
... cancel 1, 8, 15th
... meet august 22; need to be able to react to CR reports coming back
... may cancel august 29 meeting.
F2F meeting in Bay Area, week of Sept. 26
mnot: F2F set for November 7-8-9,
... will put up poll on web site to plan attendance for Tokyo F2F.
... full day Sept 7 and 8, morning of 9th
... continue discussion of test suite, and exactly what is a feature, identifying the features and whether they are optional or mandatory, also sender/receiver.
<scribe> ACTION: PaulD to make enumerated list of features [recorded in http://www.w3.org/2005/07/25-ws-addr-minutes.html#action01]
dhull: will look over, give early feedback
anish: SOAP 1.2 (?) spec has embedded links to testable assertions. This may be a good idea - including hyperlinks in main spec.
PaulD: Don't want to put the main spec in danger by adding these marking.. ?
dhull: tagging would not be a substantive change. It is useful, and not hard.
PaulD: Asynch scenarios
mnot: we need discussion of test
suite during August
... next meeting in 4 weeks: 22 August
good august to all