- From: Jonathan Rees <jar@creativecommons.org>
- Date: Sun, 12 Jun 2011 02:22:55 +0000
- To: Larry Masinter <masinter@adobe.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
(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