Meeting minutes
<gkellogg> preent+ Gregg_Kellogg
plh: this topic has been going around the W3C for awhile...
… goal of session is to have a discussion and potentially change the process.
… not for the upcoming process, but maybe the next year (2024)
<plh> https://
plh: slides 👆
… rules are coming from Process doc which says..
… <thing>
… process tells how to release deliverales.
… "Adequate implementation experience"
… is what needs to be demonstrated
… very open-ended.
… are there "iii"?
… several issues raised recently.
… what qualifies as an implementation? Does a JS-implementation?
<cyril> https://
plh: TTML -- one implementation was a polyfil, as part of the report.
… What about a plugin?
<cyril> https://
plh: What about an e-reader?
… "publicly available" is noted.
<martinthomson> Answers: yes, yes, ?, no, ?, no
plh: Does the license tied to the implementation matter?
… Another issue is what is "independent?"
… How much can be shared between implementations before they are considered one?
… What if we only get implementation from the spec editors? Is that OK?
<martinthomson> s/brotly/brotli
plh: (cites URL discussion from ages ago--was about fixing bugs in the common library)
… Finally "interoperable". You have producers/consumers.
… For HTML, didn't look at producers.
… Same for SVG.
… We look at some classes of consumers.
… For TTML, consumer is cloud services.
… These are not "end users", can they count as consumers?
… So many questions.
… We have also been insisting on tests.
… Charters are now saying this.
… (Can CSS please do this too?)
… Just how extensive should the testing be?
… (every combo of CSS colors)
… When updating Geolocation.. got a comment in AC review that the *entire* test suite should have been run (not just the deltas)
… Running manual tests was a chore.
… W3C works on a variety of different areas...
… Have VC, DID, Perf, Data stuff, etc.
… Have older protocols (open screen, and SOAP from before I was born)
… Often certifications about security/privacy is also not checked, because it's uncheckable?
plh: (Timing slide)
… just wanted to mention that external timing matters sometimes.
… Need to deal with TTML charter
… this session is not meant to come to resolution on TTLM FO.
… FO council will decide this.
martinthomson: Going back to original def and goals
… your questions about iii, found that I only really care about deployed (people are using it "for real")
… these are perhaps questions you might want to ask on your way to finding out about deployment
… also, integration *does* matter--in the case of WebRTC.
hober: 1) [CSS WG] word "independent" discussed a lot
… many features worked on by Adobe, etc. (CSS Regions)
… same engineers at Adobe did the implementation in different browser engines.
… at the time, CSSWG decided it *could not* count as independent because the "same minds" had produced them.
… didn't demonstrate that other minds could do it.
… 2) framing problem? interop producers/consumers, not right question.
… spec makes a normative statement. Reads on some implementation, but not others.
… in HTML, parsing norm statements are for parser impls, not for authoring conformance.
… I don't think there's one answer of how many are needed.
MarcosC: you noted that groups define what the criteria was.
… you couldn't recommend somethingn if it wasn't being used by a lot of people.
… we know that W3C specs (in name) do carry weight.
… we want those expectations to be there in the spec.
… I'm worried about an abuse in bad faith
… "interoperable" I think we have a good understanding; not everything is testable.
… was shocked to hear about some of these per-group decisions.
… we need to perhaps not be too extreme at times.
florian: reacting to martin
… we [css?] are seeing this from a different angle.
… saying "Rec" is a statement about the doc, not the tech in the world
<nigel> +1 to Florian re specification quality
florian: I care more about that the tech exists, notif it has been deployed
<Brent> +1 Florian
<hjrchung> +1 florian
florian: multiple impl. can tell you will it work across a diversity of devices.
… whether it achives market success is indpendent of the quality of the document.
… question: how do we know the spec is any good?
… WPT gives us what we need for browsers.
… not all specs are to be implemented by browsers.
<nigel> +1 that browsers are not the only platform that has to pass tests
florian: don't think we've quantified what WPT achieves for other specs? (like DID?)
… when we move to specs not meant to be done by browsers we might learn something.
… e-pub readers. Not a browsers, but a CSS user agent.
… charters might want to describe what software is meant to be a typical expected implementation might look like.
… lots of implementations that don't align with the spec's expected targets might still be meaningless.
<Zakim> dsinger, you wanted to add to independent: two implementations from the same company? two companies shipping the result of the same consultant's work? forked open source?
dsinger: More squishy edges: "independent" VTT has two implementations of the same spec!
… by different eng. teams!
… open source that has forked. How long must it be since they forked?
… may have to prove... but makes it a judgment call. (Don't like that--rather have determinism)
… Is a test suite an implementation (or not)?
<Zakim> nigel, you wanted to say the implementation question is for specification quality assurance
dsinger: 🔥🔥
nigel: process doesn't say what you have to do, just says what the director might ask.
<martinthomson> in Sir Tim we trust?
nigel: and what answers need to be given?
… We're looking at this through our 2022 lense, then when it was written a long time ago.
… we've heard a range from "I want it to be deployed" / "I want it to be readable"
<cwilso> +1 nigel
nigel: these questions are meant to provoke "if they implemented on a desert island, with a spec and a computer, could they do it?
… we need to support breadth of devices, not just browsers.
<martinthomson> is the question "could it be implemented" or "could an implementation based on this spec achieve interoperability?"
nigel: re: "iii" that's there to discover what it means. When you write a thing, you know what it meant. But another person may read it differently. It's meant for clarifying that.
<plh> [historic fact: CR was introduced in the Process at the request of the DOM Working Group]
nigel: if we could all agree what the goal is, we should write that down.
tink: An extent to which an implementation is used, should be considered.
… ARIA in HTML spec.
… implementations are co-validaitors, conformance checkers, etc.
… when looking at this, we considered how much these tool were used.
… didn't want some brand new extension with no use.
… W3C conformance validator was used.
… so should consider extent of usage.
manu: we may consider different specs require different types of testing.
<Zakim> manu, you wanted to note that we might want different classes of testing for data models vs. protocols (at least) and to note wpt for DID Methods
manu: should also look at FOs over disagreements over spec implementations.
… using DID core as example.
… WG said, this is a data model spec. So, need to find producers of the data model.
… but we got FOs saying we didn't do the appropriate testing.
… there were rules. 50 producers.
… Would be good to understand why that wasn't enough.
… haven't heard much feedback on that.
… now we've overcorrected.
… have a thing that looks much more like WPT.
… are testing at DID layer, and VC layer.
… we still don't know, when we take these to REC, if we'll get FOs on interop.
<brentz> +1 Manu
manu: would love to see this documented to avoid running into the FOs.
gsnedders_irc: +1 to nigel and dsinger's feedback
… e-readers are not the same CSS impl as a web browser.
… no one will disagree.
… what is the goal of these specs?
<martinthomson> siri: don't worry about it
gsnedders_irc: CSS box L3 spec editor makes a bunch of non-backwards compatible changes... (hypothetical)
… would that really be a replacement?
… doesn't say whether that would be a useful spec.
<Zakim> florian, you wanted to agree and build on what nigel said
gsnedders_irc: without goals you can't judge.
florian: is a polyfil appropriate?
… perhaps. If you can only implement some but not all, maybe we have a problem.
<Zakim> cwilso, you wanted to discuss deployed, real interop, "does this spec matter for people using the web"
florian: current process has "sample of questions the director will ask", but should be replaced by set of goals behind the current questions, and have the charter conversations figure out the details.
cwilso: echoing sam: what is the point of a web standard?
<nigel> +1 to Florian's point that we need to establish what we want to achieve, and CRs can say how to do that for any particular WG,
cwilso: what do we think it is?
… we need a consistent set (or one) definition.
… otherwise, we'll continue to hear FOs from Mozilla, etc., when they haven't implemented...
… without consistency we can end up in tense situations.
… My opinion: point of standard is to have interop. Not just testing, etc.
… lots of subtlety here, don't mean to gloss over it.
<Zakim> cyril, you wanted to comment on what some other SDOs do, reference software, test suite coverage
<gsnedders_irc> +1 to cwilso
<tink> +1 Cwilso
cwilso: if we call "web standard" something that's not across the web, it's a disservice.
cyril: I think it would be interesting to compare W3C to other SDOs
… not sure "is interoperable" question is true across all W3C.
… MPEG, etc., define the standard, then it is implemented.
… CAn't stop the promotion before it's implemetned becuase implementation comes later!
… in other SDOs, they talk about reference software.
… reference software is to improve quality of the spec.
… might be one of the goals of the software to resolve ambiguities.
… read the spec, then read the implementation, then you know.
… on test suites: we say its about software, but it should also be about content.
… should be sufficient to be able to produce and consume the content.
<gsnedders_irc> some of this is very much about what the meaning of "REC", and how we hold a very high bar for RECs, versus the endpoint of the standards track at other SDOs, and in many ways other SDOs aim for something closer to our CRs, no?
<martinthomson> gsnedders_irc: I think that you will find that there is a general trend toward high bars across other orgs too
plh: asked the AB what the different qualities we can expect about a standard.
… for example: IETF standards come 10 years after...
<gsnedders_irc> martinthomson: oh definitely, things are absolutely trending in this direction, but far behind where the W3C was nearly two decades ago.
plh: could decide to change to take into account adoption.
… web is more than web browsers.
<martinthomson> 10 years later is a rough approximation, most IETF work never makes it that far
<Zakim> dsinger, you wanted to comment about "CR stigma"
plh: web of data (not used by browsers) would therefore not meet the W3C group qualifications.
dsinger: There's not stigma being an RFC. But at W3C, groups do not like specs to stay at CR.
… what's the psycological push to get to Rec? Would like to address that.
… we don't want to address whether something in popular, but whether it's a well-written spec.
tink: Advocating for authors.
… I know authors would love a world with one implementation.
<martinthomson> luxury
tink: but these orgs need content that is production-ready.
<martinthomson> 1024x768... that was luxury
tink: W3C's strength on iii has allowed these companies to depend on production ready.
<Zakim> nigel, you wanted to flame browser guys for thinking that the only platform that matters is browsers.
tink: very hugely important.
nigel: browser guys! You have a loud voice, but you're not the only one in the room!
… for TTML, we have literally millions of divices with TTML renderer. Browser are the exception!
<Zakim> martinthomson, you wanted to talk about standards track at the IETF
nigel: Whatever we end up writing down, needs to be indpendent of the user agent.
martinthomson: in post standard in IETF matches CR. No one [there] cares what the RFC says...
… no one really cares?
… IETF says: Internet runs on Internet drafts.
… this final pursuit of something that is "done" needs to stop.
… the word "recommendation" has the right connotations. Didn't imply finally done.
… bar keeps rising. Better privacy, security, a11y, etc., a bit paralysing.
… Rec expectations is that it has to be done. Finshed. End.
<Zakim> cwilso, you wanted to respond to nigel's flame
cwilso: on behalf of all browser vendors: we don't think we're the only ones in the room.
… but if there's only one implementation, then it doesn't really seem like a web standard.
… if you rely on just "one" instance, and have to go.
hober: "Chris you just said exactly what I was going to say" <-- for the record!
florian: Rec doesn't mean done. Recent proces changes demonstrate this (rec revisions, updates, etc.)
… Rec means you've demonstrated certain quality bar.
… not everything needs to fit in the iii. But also needs consensus of the community.
<gsnedders_irc> But a lot of this isn't about the "finality" of REC, it's about the _perception_ of finality of REC.
florian: great spec about a terrible idea, shouldn't get to Rec.
… because it needs the consensus of the community. Is the market relevant, is it ethical? Etc.
plh: we all know rec is not done.
… but stages of rec are important.
… when something gets to rec, some assume it must be important.
… WCAG is important. Gets baked into laws.
… we have to place the bar somewhere!
pal: issue with what chris said... that's how you defined imteroperable. two implementations is one way, but NOT the only one.
<Zakim> dsinger, you wanted to suggest a way ahead
dsinger: hearing general agreement. But we're going to have to write down the hard questions.
… trying to answer them will refine what we mean.
… implementation at different companies? Etc.
… concerned that at this general level we will find that we think we agree, but in the details we won't.
… keen that we continue to make progress and drill into those questions.
plh: PLEASE HELP IN THE PROCESS CG!