See also: IRC log
<trackbot> Date: 06 August 2008
<tlr> ScribeNick: tlr
mez: hi folks, it's a small call, but still
<Mez> http://www.w3.org/2008/07/16-wsc-minutes.html
RESOLUTION: approved, to be installed in location above
<Mez> http://www.w3.org/2006/WSC/track/actions/open
<scribe> ScribeNick: ifette
<Mez> http://www.w3.org/2006/WSC/wiki/FeaturesAtRisk for candidate entry
mez: Here's the table for planed implementation details
<Mez> http://www.w3.org/TR/2008/CR-WCAG20-20080430/
mez: WCAG has an items at risk
section, we might have a similar section
... wanted to talk about our options here
<tlr> Scribe: IanFette
mez: look items at risk
section
... look at success criteria 1.4.8
... mez reads
... we have basic and advanced conformance levels
... basic is MUST, advanced is MUST + SHOULD
<Mez> http://www.w3.org/TR/wsc-ui/#conformance-levels
mez: for any MUSTs we need at least 2 implementations (period).
tlr: correct
mez: For any SHOULDs
tlr: Question as to whether it
makes sense to look at this on a feature-by-feature basis, or
also a performance level basis
... You need to have at least two implementations for each
feature. What we make out of that is up to us
... we have some leeway in how we design things
... what makes sense? Something like "We want to have 2 for
each must, 2 for each should, at least 1 that can show basic,
at least 1 that shows advanced"
... that could be one way to go
... dont know if that criteria would succeed
... We already skirt must and should already by having multiple
conformance levels
... so we should follow WCAG's lead
ifette: does advanced have a chance of being implemented?
mez: dunno
... that's the point of items at risk
<tlr> http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
tlr: look at entrance
criteria
... should be able to demonstrate two implementations
... if we come out of last call without too much change, can go
into candidate rec, and say "here are the features we might
remove"
... present document is clear that the WG must identify in
detail what features are at risk
... how do we demonstrate this in a useful way is the
question
mez: somewhere there was "should have 2 interoperable implementations"
tlr: yes
... we have a bunch of must not and should not that are
operational enough
... other point that was interesting is that they were not
deeming implementation by "not exercising" a requirement
sufficient
<tlr> ... e.g., logotypes not being implemented
mez: As tlr pointed out, being
conformant but not implementing a feature doesn't count towards
1 of the 2 implementations of the feature
... going in, I would argue philisophically that as a starting
place for each one, we really want two interop. implementations
for anything that is MUST/MUST NOT
... feel same way about SHOULDs
phb: SHOULD NOT might be
tricky
... if we have a situation where a certain browser does
something, and we would like it to do things similar to that to
make sure that they do not do something in a particular way,
we're unable to talk about that area at all
<Mez> good point
<Mez> is there a downgrade path?
<Mez> there is no MAY NOT
phb: one of the things we're trying to say is that if you do a feature, it must not screw the pooch
<Mez> but we did make some MAY negative somewhere I thought
phb: still want to be able to talk about features that people may not do because if they do them badly, it will cause security issues
tlr: to clarify, we have had at
least one case where we say UAs MAY do something blah
blah
... if that is the case the interface MUST be task
centric
... by itself it's sane
... however, if nobody implements that MAY
... would assume that we would strike it totally
... tricky
mez: would like to find a concrete example of what phil is referring to
<Mez> http://www.w3.org/2006/WSC/wiki/FeaturesAtRisk
phb: Part of this anticipates
things such as mobile web
... only just starting
... some of what we are trying to do is get ahead of the
curve
mez: example?
phb: where we talk about flash and pdf and so-on being integrated more tightly
tlr: where we talk about
conformance in the presence of plugins
... thought we solved that one
... dont think that's an example of being ahead of the
curve
mez: will play by ear
... MAYs OTOH don't know how we feel about 2 vs 1
implementation
... given that it says all features SHOULD have two, doesn't
break down to must/should/may
... but MAY is our out to say something even w/ no backing
implementation
tlr: do we have any MAYs that come without context of accompanying MUST/SHOULD
mez: petnames
tlr: petnames themselves have requirements though
tyler: all MAYs
<tlr> http://www.w3.org/TR/wsc-ui/#sec-petnames
tlr: yes, earlier point re:
trivial
... would argue that any MAY that comes with a set of criteria
like this
... actually should have some implementation support
mez: 1/2?
tyler: partially done
... will have at least 1
tlr: if conditioned on a MAY,
does that relax the criteria for the MUST/SHOULD?
... do not believe anywhere we say a browser MUST implement
TLS
ifette: happy with zero for MAYs, one would be gravy
mez: anything re: accessibility
is closer to zero
... audio logotypes etc
<PHB> got to go, traffic accident means I have to pick up kid
tlr: what is at risk is presumably the criteria about rendering of audio logotypes
phb: writing up in cab forum
tlr: suspect high risk
tyler: with altnames in
certificates, firefox provides no apis
... (question to phb)
... follow-up offline
tlr: this is totally optional,
implementations may or may not support this, but if they do
support we have comformance language
... similar to petnames
mez: you seem to believe that if there are must or shoulds that you can get around by not implementing, you would still argument for two implementations
tlr: yes
... also something around independent implementations
... if you look at "exit criteria" in wcag
<tlr> http://www.w3.org/TR/2008/CR-WCAG20-20080430/#statusnote1
tlr: there are at least for the
websites an explicit criteria that the websites should be
distinct and independently developed
... to what extent do we address this
... thing we can defend is two implementations
mez: two different versions of same browser might not be interesting
ifette: firefox + firefox extension does not count as two implementations of the same feature
tlr: yes, but if we had two
separate extensions that exercised a feature
... that would be different
... two distinct implementations of a feature
... precise meaning in presence of plugins is interesting
question
... subtle implications
mez: sounds good
... feeling good about general discussion on this topic
... anything else on this topic?
... SHOULD/MUST/MAY discuss now?
tlr: next step?
mez: next step is to fill out the
table
... map out what we need to do to get to CR entry
... for anything where we don't have a statement from two
somebodys
... we need to have a heartfelt discussion around that, flag as
at risk
... claro?
tyler: who is responsible for writing code? FF, Opera, Tyler with Petname?
mez: nobody else she knows of
tlr: staikos has wandered
off
... could be interesting to ask him for review, if he is
interested
mez: paul doing anything?
tlr: ping
NOTE: generalize into we might want to ping some of the less active WG members
mez: OK, that's it for
today
... next time on our favorite show...
... ready to talk about testing, or wait for a while?
tlr: would prefer if that
discussion included a few choice people
... rachna, maritza, serge would be good peepz
mez: could we at least talk about the non-usability testing?
tlr: sure
ifette: I may be in beijing next week
mez: adjourned