How to Create a Standard, 2026 Addition  🔗 **Source:** [How to Create a Standard, 2026 Addition](http://scripting.com/2026/08/04/124651.html) > [!note]+ Document Notes > --- > tags: [standards, interop, rss-chat, w3c, ietf, standards-bodies, protocol-design, dave-winer, validators, developer-experience, open-web] > title: How to create a standard, 2026 addition > author: Dave Winer > source: "Scripting News" > reference: http://scripting.com/2026/08/04/124651.html > date created: 2026-09-04 11:20 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > [!warning] Provenance and scope > > **This is an addendum, not a standalone piece.** ~500 words, published 4 August 2026, and linked the same day from the "Updates" section of [[3. Resources/Readwise/Articles/Rules for Standards-Makers|Rules for standards-makers]]. Read the two together; this post assumes the earlier rules. > > **Direct relevance to Courtney's own work:** the project being described is **RSS.chat**, which is the upstream of her RSS Chat Routing plugin (on staging + live since 2026-08-22). This post is the standards philosophy behind a format she already ships against. > > **Self-interest, again unstated:** Winer created RSS, XML-RPC, rssCloud and OPML. Every comparison in this post is an episode he was party to, and he won each retelling. > # 🏷️ Title: How to create a standard, 2026 addition > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#️-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > - [🧱 Refactor Appendix](#-refactor-appendix) > - [🧰 Template Library](#-template-library) > ### 🔗 References (in-page) > - Source: http://scripting.com/2026/08/04/124651.html > - Parent document: https://this.how/standards/ > - Related: XML-RPC (http://xmlrpc.com/), RSS 2.0 (https://cyber.harvard.edu/rss/rss.html), rssCloud > ## 📝 Summary > **What this adds.** A concrete deliverables list the 2017 rules never specified. Developers need three things to achieve interop: **enough examples, a validator, and docs that value explaining over mathematical elegance.** Everything else is optional. > **The process claim.** RSS.chat was deliberately not taken to the W3C or the IETF. Winer's sequence: build the software, get satisfied with it, then open it to other developers to build either something compatible (a reader) or something competitive (a writing environment) — with time still available to fix problems that surface. > **The indictment of standards bodies.** Three charges, stated as pattern rather than as evidence: body-produced standards aren't developed by implementors or with implementors in mind; they avoid solving any specific problem in favor of elegance and flexibility; and this makes interop *less* likely rather than more. He adds that W3C-adopted web standards "often did anti-interop things in their design," while conceding that popular ones get built on anyway. > **The historical explanation.** The internet was built mostly by individuals at universities while the tech industry was occupied with Windows vs. Mac OS and Lotus vs. Excel. The internet caught the industry by surprise, so the formats that industry subsequently produced were, in his phrase, anti-internet. > **Bottom line.** The three-deliverable list is the genuinely useful, transferable contribution and it is stated in one sentence. The surrounding argument is a restatement of a twenty-five-year-old grievance, offered as pattern with no evidence a reader could check, by the party who lost those particular fights and is describing them as the party who was right. > ## 📖 Main Content > **"Enough examples, a validator, and decent docs" is the whole post.** Strip the polemic and this is a deliverables checklist, and it is a good one because each item is falsifiable — you either shipped a validator or you didn't. It also completes the 2017 rules in a specific way: "ship a toolkit" told you to write reference code, and this tells you what else has to be in the box. The validator is the most interesting addition, because it is the one item that makes conformance checkable *without* the spec author being in the room. That is a genuine mechanism for interop, not a preference. > **"We assume developers can read and think."** The design premise underneath the docs claim. A spec that valorizes mathematical elegance is optimizing for a reader who does not exist; a spec with examples optimizes for the reader who does. This is the same argument as the 2017 "specs in plain English" rule, sharpened by the ordering instruction: when in doubt, the examples are authoritative. > **Ship-then-open, rather than specify-then-build.** The RSS.chat sequencing is the 2017 priority chain (users > software > formats) applied to a live project, and it is stated more concretely here: build, be happy with it, open it, and keep a window open to fix what other implementors find. The important and easily-missed detail is that he invites *competitive* implementations, not only compatible ones — a competing writing environment is a stronger interop test than a second reader, because it exercises the write path. > **The standards-body indictment is the weakest part, and it is most of the words.** Three empirical claims — not implementor-developed, problem-avoidant, elegance-optimizing — are each plausible, each stated as universal ("most standards that come out of the standards bodies"), and none supported with an instance a reader could examine. The supporting examples are the same three from 2017: XML-RPC vs. SOAP, RSS vs. an alternative syndication format, rssCloud vs. its alternative. All three are disputes Winer was in. That does not make him wrong — his side of the XML-RPC/SOAP argument has largely been vindicated by adoption — but a pattern claim supported entirely by one's own wins is a weak form of evidence, and the post presents it as settled. > **"Anti-internet" is the load-bearing rhetorical move.** The historical framing does real work: it converts a disagreement about design methodology into a claim about institutional origin and therefore motive. If the formats industry produced were anti-internet *because* industry was blindsided by the internet, then the design flaws aren't mistakes to be argued about, they're a predictable consequence of who was in the room. It is a compelling story. It is also unfalsifiable as stated, and it does not account for the standards bodies' own successes — HTTP, TLS, and HTML5 all went through bodies and all interoperate. > **The self-aware caveat that saves it.** Winer concedes that body-produced standards, whatever their design flaws, "could still be used" and that "if they get popular we will build on them anyway." That is an honest admission that his own adoption criterion — does it get used — sometimes favors the thing he's criticizing. > ### 🗒️ Notes > - **This is the practitioner answer to a question the 2017 page left open.** The rules said "ship a toolkit"; this says examples + validator + prose docs. Anyone applying Winer's philosophy now has a checklist. > - **The validator is doing more work than its one mention suggests.** It is the only item that converts "be conservative in what you send" from an exhortation into something enforceable at the implementor's desk — which connects it directly to the Postel material in the sibling doc, and to the half of Postel the 2017 page omitted. > - **RSS.chat is a live test of the whole philosophy**, and Courtney has skin in it via her routing plugin. If RSS.chat achieves independent implementations without a standards body, that is one real data point for the method; if it stalls at one implementer, that - + * TL;DR: What developers need. Enough examples, a validator, and decent docs that value explaining over mathematical elegance. We assume developers can read and think, and if there's doubt look to the examples for guidance. [#](http://scripting.com/2026/08/04/124651.html#a124710) * It's worth noting we did not take the RSS.chat project to a standards body like the W3C or the IETF. I develop the software first, make sure I'm happy with it, then open it up for other developers to try out, either building something compatible (a reader) or competitive (a writing environment). Hopefully we won't find major problems, but if we do, there's still time to address them. [#](http://scripting.com/2026/08/04/124651.html#a123846) * I find that most standards that come out of the standards bodies aren't developed by implementors or with them in mind. They avoid trying to solve any specific problem, rather focusing on the elegance and flexibility of the format. This makes interop much less likely. [#](http://scripting.com/2026/08/04/124651.html#a124933) * I saw the differences several times as the web standards were growing up. The ones that were taken over by the W3C ended up missing the point. They could still be used, but they often did *anti-interop* things in their design. But if they get popular we will build on them anyway. A great example was XML-RPC vs SOAP. We didn't need another way to do RPC on the web, we already had a good one. We didn't need another syndication format, RSS was growing like a weed. We didn't need an alterative to rssCloud, but we got one anyway. [#](http://scripting.com/2026/08/04/124651.html#a125014) * It's as if they forgot that the internet and web were not build by big corporations, who were busy fighting over Windows vs Mac OS. Lotus vs Excel. The internet was built mostly by individuals at universities. The internet caught the tech industry by surprise. So it's no wonder the formats they built were *anti-internet.* Long story, the point is we're building stuff is mimimalist yet still does a lot of great things. And there won't be a lot of long mathematical sounding definitions, but there will be plenty of examples and a validator, the tools developers need to create interop. [#](http://scripting.com/2026/08/04/124651.html#a125114) © copyright 1994-2026 Dave Winer. Last update: Tuesday August 4, 2026; 9:10 AM EDT. You know those obnoxious sites that pop up dialogs when they think you're about to leave, asking you to subscribe to their email newsletter? Well that won't do for Scripting News readers who are a discerning lot, very loyal, but that wouldn't last long if I did rude stuff like that. So here I am at the bottom of the page *quietly* encouraging you to [sign up for the nightly email](http://scripting.com/email/). It's got everything from the previous day on Scripting, plus the contents of the linkblog and who knows what else we'll get in there. People really love it. I wish I had done it sooner. And every email has an unsub link so if you want to get out, you can, easily -- no questions asked, and no follow-ups. Go ahead and do it, you won't be sorry! :-) Just passin' thru, How to Create a Standard, 2026 Addition, Dave Winer, 01m1pmt6k6sftvk6th46tp47we.