Specs/advice - Revision history

GPHemsley: GPHemsley moved page Advice for people writing specs to Specs/advice: Using subpages for easier navigation.

2013-11-06T14:51:42Z

GPHemsley moved page Advice for people writing specs to Specs/advice: Using subpages for easier navigation.

← Older revision	Revision as of 14:51, 6 November 2013
(No difference)

Ms2ger: added Category:Specification editing using HotCat

2013-05-09T07:04:28Z

added Category:Specification editing using HotCat

← Older revision		Revision as of 07:04, 9 May 2013
Line 11:		Line 11:
	--		--
	Ian Hickson		Ian Hickson

			[[Category:Specification editing]]

Zcorpan at 09:15, 23 May 2012

2012-05-23T09:15:10Z

← Older revision		Revision as of 09:15, 23 May 2012
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.

Hixie: 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 ...'

2011-11-09T21:18:31Z

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 ...'

New page

* 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