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

(Top-replying... I hear that this is unpopular in some circles, sorry...)

I think what you're saying is in agreement with
http://en.wikipedia.org/wiki/Normative , which looks pretty good to
me.

So we might have a W3C Note (or indeed any old document) defining a
syntax, and the note, while not a Recommendation, can still have
normative elements; "normative" is simply descriptive of the kind of
language it contains. (E.g.
http://www.w3.org/TR/2009/NOTE-owl2-manchester-syntax-20091027/ )

Unfortunately, some of us have come to use the word differently,
sometimes to mean "authoritative" or "embraced by one of our favorite
standards organizations". It's similar to the situation with the word
"metadata", which has a clear dominant meaning that is different from
how it's often used in computy-technical circles. Hard to know whether
it's too late to change usage of either word.

Clearly what we need is a normative statement on the use of the word
"normative", so that we can say "when you write your document please
use 'normative' in compliance with Z" or "this document complies with
Z in its use of the word 'normative'".  :)

There are some real issues here, however. First, the architecture
supposedly gives you a standard(?) *way* to enter into such agreements
(or to offer to do so), such as a media type or other marker. I think
that on the subject of media types you have been arguing either that
they shouldn't have this function (which makes sense since doing so
seems to be incompatible with language evolution) or that they are
ineffective at doing so (because in practice nobody is willing to be
held to such a strong interpretation). I would like to hear more of
your philosophy on this mismatch.

Less technically there is the question of multiple ways to accomplish
the same end. I am not a Python programmer but I have read it has the
design goal "there should be one-- and preferably only one --obvious
way to do it." The question is not what documents contain normative
elements, but what way does W3C recommend (in preference to others)
for doing something. W3C can't be correctly described as being a
standards organization if it recommends multiple ways to do the same
thing (without giving some criterion that would guide a decision
between them). I think that's the question people are asking, even if
they're using the wrong word to do so - what would be recommended
should two recommendations be discovered to disagree. I think this is
where your advice to write (non-normative) applicability statements
comes from.

(Note to self: find a definition of the phrase "normative reference")

Thanks for calling this out.

Jonathan

On Sat, Jun 11, 2011 at 11:52 PM, Larry Masinter <masinter@adobe.com> wrote:
> 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 Sunday, 12 June 2011 02:23:23 UTC