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 > <!-- deep-read:sections start --> ## 🧭 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 is a data point too. This is unusually checkable for a philosophy post. - **The counterexamples go unmentioned.** HTTP, TCP/IP, TLS and HTML5 are body-developed and interoperate at planetary scale. Any general claim about standards bodies has to account for them, and this post doesn't try. - **"Competitive, not just compatible" is a subtle and good point** buried mid-paragraph. Inviting a rival writing environment is a much stronger openness signal than inviting more readers, and most "open" projects only ever get the latter. - **The post never claims the rules are new** — it is explicitly an addition, and its self-description as such is accurate. ## 📚 References The post cites nothing directly — no links in the captured body beyond site chrome. Its references are allusive: RSS.chat, the W3C, the IETF, XML-RPC vs. SOAP, RSS, rssCloud, Windows/Mac OS, Lotus/Excel. Every one is named without a link. That matters for a post making historical claims. A reader who wants to check "we didn't need an alternative to rssCloud" has to already know what the alternative was (PubSubHubbub/WebSub) and go find the history themselves, and the post does not name it. The 2017 parent page, by contrast, links its primary sources generously — so this is a regression in citation practice relative to the document it extends, not a house style. Worth pairing from outside the post: the WebSub W3C Recommendation, RFC 3117 (Rose) and Thomson's robustness-principle drafts, and any body-produced standard with strong interop — the last of which is the missing control case. ## 🗣️ Paraphrase **The TL;DR.** What developers need is enough examples, a validator, and decent docs that value explaining over mathematical elegance. The assumption is that developers can read and think, and where there is doubt, the examples are what to look to. **The process.** The RSS.chat project was not taken to a standards body like the W3C or the IETF. Winer develops the software first, makes sure he is happy with it, then opens it up for other developers to try — either building something compatible, like a reader, or something competitive, like a writing environment. Hopefully no major problems surface, but if they do there is still time to address them. **The critique.** Most standards that come out of standards bodies aren't developed by implementors or with implementors in mind. They avoid trying to solve any specific problem, focusing instead on the elegance and flexibility of the format, which makes interop much less likely. **The historical pattern.** He saw the difference several times as web standards were growing up. The ones taken over by the W3C ended up missing the point; they could still be used, but often did anti-interop things in their design — though if they got popular, we would build on them anyway. XML-RPC versus SOAP is his example: 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, since RSS was growing like a weed. We didn't need an alternative to rssCloud, but we got one anyway. **The explanation.** It is as if they forgot that the internet and web were not built by big corporations, who were busy fighting over Windows versus Mac OS and Lotus versus Excel. The internet was built mostly by individuals at universities and caught the tech industry by surprise, so it is no wonder the formats they built were anti-internet. **The close.** The point is that what they are building is minimalist yet still does a lot of great things — without long mathematical-sounding definitions, but with plenty of examples and a validator, the tools developers actually need to create interop. ## 📰 Newsletter **What a spec actually owes a developer: examples, a validator, and prose** Dave Winer added a 2026 note to his long-running [Rules for standards-makers](https://this.how/standards/), and the useful part is one sentence: developers need enough examples, a validator, and docs that value explaining over mathematical elegance. That's a checklist, which is more than most standards philosophy gives you. And the validator is the item worth stealing — it's the only one that makes conformance checkable without the spec's author in the room. A spec with examples and no validator is an argument; a spec with a validator is a contract. He's describing [RSS.chat](http://scripting.com/2026/08/04/124651.html), which he pointedly did not take to the W3C or IETF. His sequence: build it, be happy with it, then open it up — and notably, invite people to build something *competitive*, not just compatible. A rival writing environment tests your format far harder than a second reader does. The surrounding argument is a quarter-century-old grievance about standards bodies producing formats by non-implementors optimized for elegance instead of interop. Some of that has aged well — the XML-RPC-versus-SOAP verdict came in a long time ago, and it wasn't SOAP. But it's stated as a general law with no counterexamples entertained, and the obvious ones are load-bearing: HTTP, TLS and HTML5 all came through bodies and interoperate fine. Read it as a deliverables list and it's excellent. Read it as history and bring a second source. If you're running feeds anywhere near RSS.chat, this is the philosophy your format is being built under — worth knowing what its author thinks he owes you. ## ✅ Action Items **Courtney — personal (direct relevance):** - **Check what RSS.chat actually ships against this list.** Her RSS Chat Routing plugin depends on the format; the post promises examples and a validator. Does the validator exist and is it public? That is a five-minute check with real consequences for her plugin's robustness, and it tests Winer's own claim against his own project. - Her upstream issue #6 on the routing plugin is the natural place to raise anything the validator surfaces. - The "competitive, not just compatible" idea is worth taking seriously for her own plugins — has anyone built against Post Kinds' surfaces in a way that isn't just consuming them? **Core / Core AI:** "Examples + validator + explanatory docs" is a usable acceptance bar for any new schema, including the Abilities API — a schema without a validator pushes conformance cost onto every implementer. **Documentation:** "Value explaining over mathematical elegance" and "when in doubt look to the examples" are directly usable, and the second is a real editorial policy decision — it makes examples normative rather than illustrative. **Plugins / Themes:** A validator is the cheapest interop investment a format owner can make; relevant anywhere plugin metadata formats are being defined. **FAIR:** Most relevant team here. A federated repository is exactly the case where "shipped a validator" determines whether independent implementations converge or drift. **Openverse / Meta / Tide:** Applicable where shared schemas exist; the validator argument generalizes. **Training:** The three-item list is a clean teaching artifact on what makes a spec usable. **Community / Marketing / Support / Polyglots / Photos / TV / Mobile / Playground / CLI / Hosting / Core Performance / Accessibility / Core Program Team:** Not applicable to this source — no surface of theirs is touched. **The WPOCC:** Not applicable to this source. ## 🧪 Hypotheses 1. **Formats shipping a validator at launch achieve more independent implementations** than formats that don't, controlling for age and popularity. Directly testable and the post's strongest implicit claim. 2. **RSS.chat will or won't attract an independent implementation within 24 months.** A live, falsifiable test of the no-standards-body method, and one Courtney is positioned to observe. 3. **Body-produced standards are not uniformly worse at interop.** HTTP, TLS, HTML5 are the counterexamples; the testable refinement is that *committee-designed formats with no reference implementation* underperform, which is a narrower and more defensible claim than the one made. 4. **Example-first specs produce faster time-to-first-working-implementation** than prose-and-schema specs. Measurable with real developers on comparable formats. 5. **Inviting competitive implementations predicts format longevity** better than inviting compatible ones. ## 📊 Methodology **None offered, and the post is doing more empirical work than the 2017 page.** The parent document mostly asserted principles; this one asserts a *pattern* about an entire class of institutions ("most standards that come out of the standards bodies"), which is an empirical claim with a truth value. The evidence supplied is three examples, all disputes the author participated in, all recounted from his side, and none linked. There is no attempt at a control case — a body-produced standard that interoperates well — even though several obvious ones exist and one of them (HTTP) is the transport for everything being discussed. The honest characterization: this is a practitioner's pattern-recognition claim from a very large sample of personal experience, which is genuinely valuable, presented in the grammar of a general finding, which it has not earned. The three-deliverable list, by contrast, needs no methodology — it is a recommendation, and it stands or falls on whether following it helps. ## ❓ Questions 1. Does RSS.chat's validator exist and is it publicly usable today? The post promises "there will be" — present or future tense matters for anyone building against it now. 2. How does he account for HTTP, TLS and HTML5 — body-produced and interoperable at scale? Are they exceptions, or is the claim actually about a narrower category than "standards bodies"? 3. What was the rssCloud alternative, and is the "we didn't need it" verdict shared by anyone who wasn't on his side of it? 4. What counts as "enough" examples? The word is doing a lot of work in a checklist that is otherwise pleasingly concrete. 5. Does "if they get popular we will build on them anyway" concede that adoption, not design quality, is the real arbiter — and if so, what is left of the design critique? 6. How does a validator interact with Postel's accept-half? A strict validator is an argument against liberal acceptance, and the 2017 page cited only the send-half. ## 🔮 Future Research - **Track RSS.chat's implementation count over time.** The cleanest available natural experiment on the no-standards-body method, and Courtney is already downstream of it. - **Validator presence as a predictor of interop.** Build the comparison the post gestures at: formats with and without launch-day validators, measured by independent implementations and by divergence in behavior at five years. - **The counterexample set.** A serious version of this argument has to explain body-produced successes. Whether the distinguishing variable is "implementors in the room" or "reference implementation shipped" is the interesting open question, and it is answerable. - **Postel's accept-half versus the validator.** These two ideas are in direct tension and both are endorsed within this pair of documents. Working out where each applies would be an original contribution. ## 💡 Implications **For practice.** The three-item deliverable list is immediately adoptable and cheap to check. Anyone defining a format for others to implement should ask whether they have shipped all three, and the validator is usually the missing one. **For policy.** The post is an argument that governance venue determines design quality. If that is true even partially, it bears on where format work should happen in ecosystems like WordPress — in a committee, or in a working implementation that others are invited to copy. The honest reading is that the post asserts this rather than demonstrating it. **For security.** A validator is a security artifact as much as an interop one — it is where malformed input gets rejected rather than tolerated. The post doesn't frame it that way, and that framing is worth adding. **For education.** "When in doubt look to the examples" is a strong editorial stance with a real cost: it makes examples normative, so a wrong example becomes a wrong spec. Worth adopting deliberately rather than by default. **For funding and sustainability.** Examples, a validator and good docs are all maintenance labor, and none of it is the format itself. This is the same unfunded-labor gap that shows up throughout the vault — the spec is the cheap part. ## 🧠 Learning Styles Assessment - **Visual** — Not served. No images, diagrams, or structure beyond bullets. A single before/after or a diagram of the ship-then-open sequence would carry the argument better than the paragraphs do. - **Aural** — Not served. Text only, no audio version. - **Verbal (read/write)** — Well served and clearly the native mode. Conversational, first person, short paragraphs, a stated TL;DR at the top. - **Kinesthetic** — Weakly served. There is an implicit action (go check your format against the three items) but nothing to do on the page, and no worked example. - **Logical** — Moderately served. The TL;DR states the conclusion up front and the reasoning follows, but the central pattern claim is asserted rather than derived, so a logical reader can follow the structure and still not be able to evaluate the argument. - **Social** — Weakly served. No comments on the post; feedback runs through the Scripting News GitHub issues named on the parent page, not here. - **Solitary** — Well served. Short, self-contained, readable in three minutes. - **Naturalistic** — Not applicable to this source. **Reading level:** roughly grade 9–10 prose — plain, conversational, contractions, short sentences. Comprehension demands are far higher: the reader needs to know what RPC, syndication, rssCloud and a validator are, and needs the 1990s–2000s standards history to evaluate any of the claims. A junior developer will understand the TL;DR completely and be unable to assess the rest. ## 📊 Accessibility Assessment Assessed against WCAG 2.2 AA, treating the published post as the artifact: 1. **1.1.1 Non-text Content (A).** Minimal exposure — the captured body is text; no meaningful images to require alternatives. 2. **1.3.1 Info and Relationships (A).** Content is a bulleted list with `#` permalink anchors per item, consistent with Winer's outliner publishing. Whether list semantics reach assistive technology depends on the emitted markup, which the text capture cannot confirm. 3. **1.4.3 Contrast (Minimum) (AA).** Not assessable from a text capture. Scripting News is a long-standing plain layout; that is an assumption, not a measurement. 4. **2.4.4 Link Purpose (In Context) (A).** The same defect as the parent page: per-item bare `#` permalinks give a screen-reader link list a run of indistinguishable entries. 5. **2.4.6 Headings and Labels (AA).** The post has no internal headings — it is a flat bullet list under a dated permalink. At ~500 words that is tolerable; it would not be at length. 6. **3.1.1 Language of Page (A).** Presumed English; not verifiable from the capture. 7. **4.1.2 Name, Role, Value (A).** Depends on emitted markup, as with 1.3.1. **Overall:** low-risk because it is short plain text, with one carried-over defect (bare `#` link text) and the same rendering unknowns as its parent. Nothing here is assessable to a conclusion from the capture alone — which is itself the point of [[3. Resources/Permanent Notes/Detecting a Property Is Not Evaluating Whether It Serves Anyone]]. ## 🌍 DEIB Assessment - **Cultural breadth.** Narrow. The history is entirely American tech industry — Windows/Mac, Lotus/Excel, W3C, IETF — and "the internet was built mostly by individuals at universities" elides the substantial non-US contribution, including CERN, where the web itself was built. That omission is notable in a post whose whole argument rests on who built the internet. - **Inclusive language.** Plain and unproblematic. No exclusionary idiom. - **Neurodiversity support.** Good by structure rather than intent: a TL;DR first, then short discrete bullets, each independently addressable. Conclusion-first writing is friendly to readers who need to know where a piece is going before investing in it. - **Representation.** Minimal. No individuals are named at all — the actors are institutions ("they," "the W3C," "big corporations") and an implied "we." The absence of named opponents means nobody criticized here can be looked up or heard from. - **Psychological safety.** Fine for the reader; the tone is inclusive toward developers ("we assume developers can read and think" is a compliment, and a design premise). Less so for the unnamed people at standards bodies, who are characterized as having missed the point and forgotten who built the internet, with no route of reply on the page. ## ✅ Logical Validity **Strong reasoning:** - **Conclusion stated first and kept concrete.** The TL;DR is three checkable deliverables, and the post never inflates them into something grander. - **A real concession, load-bearing and voluntarily given** — "if they get popular we will build on them anyway" admits that his own adoption test can favor the designs he criticizes. That is the most intellectually honest sentence in the piece. - **The process description is falsifiable.** Build, be satisfied, open it, leave time to fix — you can check whether RSS.chat was actually run that way. **Fallacies and weak points:** - **Hasty generalization** — "most standards that come out of the standards bodies aren't developed by implementors or with them in mind." A universal claim about a large, heterogeneous class, supported by three self-selected cases. *Fix:* narrow to the defensible version (formats specified without a reference implementation tend not to interoperate), which the evidence actually supports. - **Suppressed evidence** — no body-produced success is mentioned. HTTP, TLS, and HTML5 are conspicuous by absence in a post about whether bodies can produce interoperable standards. *Fix:* address the strongest counterexample directly; the argument would survive in narrowed form and be far more persuasive. - **Genetic fallacy** — the "anti-internet" passage locates the flaw in *who* produced the formats (corporations blindsided by the internet) rather than in the designs themselves. Origin is offered as sufficient explanation for defect. *Fix:* keep the design critique, which stands on its own, and drop the institutional-origin inference or evidence it. - **Appeal to motive, inherited from the parent document** — the SOAP-as-deliberate-obstruction reading recurs by allusion. Same defect as in the 2017 page: unfalsifiable as stated. - **Survivorship bias** — the formats cited as vindicating the method are the ones that survived; formats built this way that died are not counted. **Tone of voice:** Conversational, confident, unbothered. Writes as someone with nothing left to prove and no expectation of persuading the other side — warm toward developers, dismissive toward institutions. The register is a personal blog's, and the claims are a research paper's, which is precisely the mismatch a reader has to manage. ## 🛡️ DARVO Analysis **Not applicable in the strict sense** — there is no accusation against the author being answered, so the DARVO pattern has nothing to attach to. Each element, checked: - **Deny** — absent. Nothing is denied; the post concedes a significant point against its own position. - **Attack** — present as ordinary polemic, not as deflection. Standards bodies are criticized on the merits of their output; the criticism is not deployed to escape a charge. - **Reverse Victim and Offender** — faintly present in the framing, and worth naming for the same reason as in the parent document. Independent developers (the author's side) are positioned as the party wronged by institutional standards-making, in conflicts where the author was an energetic combatant and, by several accounts, not the only aggrieved party. This is one-sided narration rather than DARVO, but it is the passage where a reader should most want a second source. **Net:** partisan, not defensive. The absence of any named opponent is the thing to notice — it makes the account unanswerable within the text. ## 🎯 Conclusion **Bottom line.** A short addendum whose durable contribution is one sentence: developers need enough examples, a validator, and docs that explain rather than impress. That completes the parent document's "ship a toolkit" rule with a checkable list, and the validator is the item that turns interop from an exhortation into something enforceable. The remaining 400 words are a well-worn critique of standards bodies, stated as a general law, evidenced by three fights the author was in, with the obvious counterexamples unaddressed. **Next steps.** 1. Check whether RSS.chat's validator actually exists and is public — the post's own claim, testable today, and directly relevant to Courtney's routing plugin. 2. Read against the Postel page: a strict validator and liberal acceptance point in opposite directions, and this pair of documents endorses both without noticing. 3. Watch RSS.chat's independent-implementation count as a live test of the method. 4. Apply the three-item bar to any format work in her own projects — the validator is almost always the missing piece. ## 🧱 Refactor Appendix ### Literature Split Pad **Proposed Literature Note:** `How to Create a Standard, 2026 Addition (Winer)` - Bib capsule: Winer, Dave. "How to create a standard, 2026 addition." Scripting News, 4 August 2026. Addendum to "Rules for standards-makers" (2017–). - Adler Q1 — what a format owner owes implementors, and why he thinks standards bodies fail to deliver it. - Adler Q2 — three deliverables (examples, validator, explanatory docs); a ship-then-open process illustrated by RSS.chat; a three-charge indictment of body-produced standards; a historical explanation grounded in who built the internet. - Key arguments (≤3): (1) examples + validator + prose docs are what interop actually requires; (2) build first and standardize what works, inviting competitive as well as compatible implementations; (3) formats designed by non-implementors optimize for elegance and lose interop. #### Claim atoms (H3 candidates) ### A validator is what makes conformance checkable without the author > [!quote] ID:rw_01m1pmt6k6sftvk6th46tp47we > 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. Where: the opening TL;DR. Why it matters: the validator is the only one of the three that removes the spec author from the conformance loop, which is what lets interop scale past the people who were in the room. <!-- atomicity: 1 idea ✓ --> ### Inviting competitive implementations tests a format harder than inviting compatible ones > [!quote] ID:rw_01m1pmt6k6sftvk6th46tp47we > 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). Where: the process paragraph. Why it matters: a rival on the write path exercises the parts of a format a second consumer never touches, so it is a stronger openness signal and a stronger correctness test. <!-- atomicity: 1 idea ✓ --> ### Designing for elegance rather than a specific problem costs interop > [!quote] ID:rw_01m1pmt6k6sftvk6th46tp47we > They avoid trying to solve any specific problem, rather focusing on the elegance and flexibility of the format. This makes interop much less likely. Where: the standards-body critique. Why it matters: names a concrete, checkable design failure mode — generality without a driving use case — independent of the institutional claim wrapped around it. <!-- atomicity: 1 idea ✓ --> #### Permanent Note candidates 1. **"A Validator Removes the Spec Author From the Conformance Loop"** — atom 1's sharpest form. Strong candidate; genuinely uncaptured as far as the security/verification cluster goes, and it links naturally to [[3. Resources/Permanent Notes/Automation Is Only Safe Unattended Once Done Is Machine-Testable]] and [[3. Resources/Permanent Notes/Encoding What Good Looks Like Is What Makes Agent Verification Trustworthy]] — the same idea in a different domain. 2. **"A Competing Implementation Tests a Format Better Than a Cooperating One"** — atom 2. Novel and useful; check against existing verification notes before creating. 3. **"Generality Without a Driving Use Case Is Where Interop Is Lost"** — atom 3. Check against [[3. Resources/Permanent Notes/A Tool Earns Trust by Staying Small Enough to Be True]] and primitive-first design notes; may be covered. **Recommendation:** candidate 1 is the strongest and links across domains rather than only within standards work — that cross-domain reach is the resonance test. Hold 2 and 3 for the same pass. ### Fleeting Queue - Does RSS.chat's validator exist yet? Check before building further against the format. - The validator vs. Postel's accept-half is a real unresolved tension across this document pair — likely the most original thing in the whole cluster. - HTTP/TLS/HTML5 as the missing control case for every "standards bodies fail" argument. - "We assume developers can read and think" — a design premise worth stealing for documentation voice. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/How to Create a Standard, 2026 Addition.md|How to Create a Standard, 2026 Addition by Dave Winer]] ## Highlights - - 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) ([View Highlight](https://read.readwise.io/read/01m1pp87s55ceh8xj4sdfyz9j1)) - Note: The whole durable contribution of the post in one sentence. The validator is the load-bearing item: it's the only one of the three that removes the spec author from the conformance loop, which is what lets interop scale past the people who were in the room. - Tags: atom/zettel/z1, atom/literature/h1 - - 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) ([View Highlight](https://read.readwise.io/read/01m1pp8fnwz98wzest8agwfjjm)) - Note: "Compatible OR competitive" is the subtle part. Inviting a rival writing environment exercises the write path — a much stronger interop test than a second reader, and a stronger openness signal. Directly relevant to the RSS Chat Routing plugin. - Tags: atom/literature/h1