Re: Open-Ended Question: What should SDOs focus their time and energy on?

>
> 2. Shrink the gap between specification and implementation

Computer Science profs have long taught that requirements, specifications,
code, tests, etc. should all be semantically equivalent. Ideally,
specifications produced by SDOs would be executable, even if written in
prose. Given today's LLMs' capabilities, converting specifications to code
is achievable. Today, you can point an LLM to an RFC or other standard and
ask it to generate a conforming implementation. Certainly, the code may not
match the quality of hand-crafted code, but if the spec is well written, it
will at least produce a functioning and conforming implementation. Today,
it is reasonable to insist that "The Spec IS the Code."

So, while some SDOs may require "N independent, interworking [human]
implementations" before final approval, perhaps we should write a new rule
requiring at least one LLM-generated implementation after each spec edit.
This implementation would serve as proof that the spec can be converted to
a technically "correct" reference implementation, even if that
implementation isn't necessarily useful. (i.e. for a "useful" server one
must implement much "general" capability not defined in normal
specifications, such as rate-limiting, state management, configuration
interfaces, etc.)

bob wyman

On Sat, Apr 18, 2026 at 9:11 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> Full prompt:
> What should Standards Development Organizations like W3C, DIF, TOIP, and
> IETF focus on to best optimize the use of their and their community
> members' time and energy?
>
> Key finding:
> "The core tension: SDOs are optimized for human-to-human knowledge
> transfer — specs written in prose, debated in meetings, ratified through
> consensus. That model is increasingly mismatched to how software actually
> gets built in 2026."
>
> Full story: https://claude.ai/share/5fa8df4d-c4b9-4d8e-9ed0-b7e7174a444d
>
> Michael
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
>

Received on Sunday, 19 April 2026 17:48:30 UTC