[Chris Wilson] Next, join me in welcoming on stage Francois Daoust, W3C Media specialist, to talk about the web and the art of specification maintenance.

[François Daoust] Yeah, I'm the one with the exciting topic...

So, by now, it should be clear to everyone that the web is a core part of the information infrastructure, right?

In layman's terms, it means that everyone uses the web, everyone depends on it and, as long as it works, hardly anyone cares about how it works and how it's made.

Except us, but we're a small group.

So exactly, just like, you know, electricity, water or transport.

For infrastructures to last [...]

For infrastructures to last, they need to be resilient where resilience means the positive ability of a system to adapt itself to the consequence of unexpected events, such as a blackout!

We need the web to be resilient to celebrate W3C's 60th birthday.

I strongly encourage everyone to read about infrastructure, I recommend "How infrastructure works" by Deb Chachra, but I know some people in the room might prefer reports that are full of legalese.

So, if you are that type of person, you may enjoy the building resilience report from the OECD.

In any case, both agree on the same thing: infrastructure cannot be resilient if it is poorly maintained.

So, there's no way to avoid it.

We need to continue looking into the maintenance of the web over and over again.

The web is simple, very simple.

It's a bunch of apps running in browsers.

The browsers implement specs and the specs are the thing we develop, we produce here, and that's precisely where we can focus our maintenance efforts.

A number of processes and a set of guidelines help produce good quality specs.

Documentation makes sure that the specs are meaningful for developers, and sometimes meaningful at all.

Tests and associated efforts completed with the research help align specs with implementations and developers at large.

This all works somewhat nicely because we have tools in place, starting with authoring tools, which handle all the heavy work to create good and consistent specs.

Over the years, various supporting tools have been developed to track specs, validate and publish them, extract and annotate data from them, and overall make our specs you know more machine readable.

And to analyze things on a more or less automated basis.

Now the reason why I'm bothering you with such a crowded diagram, which on top of being crowded is actually fairly incomplete, is, first, because I think you deserve such a crowded diagram, and, second, because I thought it would be useful to show how maintenance done at the micro level helps build a consistent system at the macro level.

In practice, all of these boxes are interconnected.

I started to draw some links and, who would have thought, the crowded diagram turned into an unreadable mess.

So I stopped here, and the remaining links are left as an exercise to the audience.

You have two minutes.

These links do matter.

They matter because they create feedback loop, positive feedback loops between the different boxes in the diagram.

For example, these loops allow us to check the consistency of the web platform as a whole by detecting potential errors in specs, be them just typos, and to close the loop to help maintain the specs and to improve the overall resilience of the web.

We report these errors to spec editors.

Sometimes, that requires some elbow grease and from time to time we can fully automate the process.

So, if you've already received one of these issues, you know, one of these issues that may seem to come from nowhere, now you know where they come from.

They come from the need to improve the resilience of the web through positive feedback loops.

Speaking of resilience it's interesting to note that different bits are done by different people, different groups and different organizations.

Usually in the open as long as loose coordination happens, takes place between these people.

I don't know that we need to formalize things further, but it illustrates a key role of W3C.

That loose coordination is possible today because W3C has managed to remain a centripetal force for the web community at large over the years.

As a matter of fact, basically all the projects tools, groups I mentioned and those I forgot to mention and include in my diagram, are represented here today at TPAC.

That W3C is able to play that role is a fantastic thing.

I also believe that it is core to its mission.

Hopefully that will continue to be the case in 30 years from now.

So, many thanks to people who manage to invest time into creating positive feedback loops, and thanks to the organization who support them from time to time, perhaps unknowingly, and see you at W3C's 60th birthday.

Thank you