A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Specs/advice: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(Created page with ' * Bureaucracy is opt-in. You don't have to do any of the bureaucracy involved in the W3C process if you don't want to, regardless of what other people will say. (e.g. Hixie, as ...')
 
m (GPHemsley moved page Advice for people writing specs to Specs/advice: Using subpages for easier navigation.)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
* Bureaucracy is opt-in. You don't have to do any of the bureaucracy involved in the W3C process if you don't want to, regardless of what other people will say. (e.g. Hixie, as editor of the HTML spec and others at the W3C, does not do any of the non-productive bureaucracy of going through the TR process.)
* Bureaucracy is opt-in. You don't have to do any of the bureaucracy involved in the W3C process if you don't want to, regardless of what other people will say. (e.g. Hixie, as editor of the HTML spec and others at the W3C, does not do any of the non-productive bureaucracy of going through the TR process.)


Line 6: Line 5:
* Think of specifications as being software. The programming language is English, and the compilers are engineers (and the compile times are high, the compiler tends to have its own opinions about what you are programming, and it talks back to you, but that's just a detail).
* Think of specifications as being software. The programming language is English, and the compilers are engineers (and the compile times are high, the compiler tends to have its own opinions about what you are programming, and it talks back to you, but that's just a detail).


* Just like with real software, you have to have clear statements. Think of "MUST" as the equivalent of an imperative statement in code. Think of defining terms as being like defining constants or functions in code. Think of *everything else* as being like comments. This means that if you don't have a "MUST" statement somewhere requiring something, then it's not required! It also means that if you have _two_ "MUST" statements requiring the same thing, it's like requiring it twice. See also http://ln.hixie.ch/?start=1140242962&count=1
* Just like with real software, you have to have clear statements. Think of "must" as the equivalent of an imperative statement in code. Think of defining terms as being like defining constants or functions in code. Think of *everything else* as being like comments. This means that if you don't have a "must" statement somewhere requiring something, then it's not required! It also means that if you have _two_ "must" statements requiring the same thing, it's like requiring it twice. See also http://ln.hixie.ch/?start=1140242962&count=1


* The specification has to match reality. If there are multiple implementations that do something and the spec says something else, the spec is wrong.
* The specification has to match reality. If there are multiple implementations that do something and the spec says something else, the spec is wrong.
Line 12: Line 11:
--  
--  
Ian Hickson
Ian Hickson
[[Category:Specification editing]]

Latest revision as of 14:51, 6 November 2013

  • Bureaucracy is opt-in. You don't have to do any of the bureaucracy involved in the W3C process if you don't want to, regardless of what other people will say. (e.g. Hixie, as editor of the HTML spec and others at the W3C, does not do any of the non-productive bureaucracy of going through the TR process.)
  • The only thing that truly matters is getting documentation that defines what implementations are to do in order for multiple independent vendors to reach interoperability without having to reverse-engineer each other.
  • Think of specifications as being software. The programming language is English, and the compilers are engineers (and the compile times are high, the compiler tends to have its own opinions about what you are programming, and it talks back to you, but that's just a detail).
  • Just like with real software, you have to have clear statements. Think of "must" as the equivalent of an imperative statement in code. Think of defining terms as being like defining constants or functions in code. Think of *everything else* as being like comments. This means that if you don't have a "must" statement somewhere requiring something, then it's not required! It also means that if you have _two_ "must" statements requiring the same thing, it's like requiring it twice. See also http://ln.hixie.ch/?start=1140242962&count=1
  • The specification has to match reality. If there are multiple implementations that do something and the spec says something else, the spec is wrong.

-- Ian Hickson