On what it means for a spec to be "normative" (re HTML5 & normative language spec)

Watching the debate, I think people misunderstand the role of a "normative" document and what it means.

Specifications from W3C and IETF do not have the force of law, can't force anyone to do anything. They're not "normative" in the sense of directly establishing law.  So what does it mean for a spec to be "normative" anyway?

A "normative" specification is one which defines some "normative" requirements (e.g., using MUST, MAY, SHOULD from RFC 2119) such that someone who wants to write a contract or make an agreement can reference the specification. 

If someone wants to say "I would like to download and install a browser which implements HTML5", then the document which defines how a HTML5 browser should work is useful. It's most useful if the specification is "normative", i.e., it defines what it means to conform to the document.

Now, if someone wants to say "I would like you to produce a HTML5 web site" or "I would like to buy some software which produces valid HTML5" again, they'd like to make a reference (in their contract, agreement, product) to a specification. And it's important that the specification you reference be "normative" in the sense that it actually defines something you can conform with. A "non-normative" spec doesn't contain any conformance requirements.

I (and I believe all of the other TAG members and a lot of other people) think that there needs to be a specification which defines the HTML5 "language" without any of the clutter that is irrelevant to tools that produce HTML or irrelevant to defining what "valid HTML" is. That's what a normative language reference should be.  The spec is "normative" in that anything that claims to be compliant with the spec would meet all the MUST and MAY and SHOULD requirements.

It doesn't make sense to take a spec that has normative language in it and then say that the whole spec isn't "normative"  -- if you use normative statements (an A MUST do B) in a spec, the whole spec has normative meaning -- any A that claims to comply with the whole spec needs to meet all of the normative requirements.

A standard (whether HTML or anything else) is a recipe for interoperability. There are different roles that are addressed by the standard (in this case, Browsers, Web pages, tools that produce HTML), and the normative language for each role might be different.  There shouldn't be a problem producing documents that are specifically addressed to each of the different roles.

For example, with the question of the overall HTML spec and the 'language' reference both being 'normative', well, you could say that the language spec has priority when it is a question of language, while the main spec has priority for all of the other roles.

The question of priority while important can be made on a finer granularity, if it's necessary at all.

Larry

Received on Saturday, 11 June 2011 23:52:34 UTC