W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2010

[Bug 11259] Use "MUST" consistently to express normative requirements

From: <bugzilla@jessica.w3.org>
Date: Thu, 16 Dec 2010 21:11:22 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PTL6g-0000EJ-Uw@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11259

--- Comment #4 from Eliot Graff <eliotgra@microsoft.com> 2010-12-16 21:11:22 UTC ---
(In reply to comment #3)
> Hmm. That doesn't altogether make sense to me.
> 
> If Polyglot Markup is a normative spec, then it is important that it carefully
> defines conformance.  For this sort of spec, the possibilities are:
> 
> 1. Conformance for documents
> 2. Conformance for software:
> (a) Software that produces documents
> (b) Software that consumes documents
> 
> The fact that there are no consequences for user agents means that 2(b) is not
> really meaningful here. But I think 1 and 2(a) are.
> 
> You can define 2(a) in terms of 1 (producing software is conforming if it
> produces conforming documents).
> 
> I believe the right approach is to use MUST whenever it is a constraint that
> conforming documents must obey.
> 
> Perhaps I should open a separate bug for this.

Hi James.

I am going to leave this bug as resolved. As early as last June, the Director
has indicated that the use of RFC2116 language is not required for a normative
spec of this nature, and, in fact, should be discouraged [1].

]]
In normative text, as this is a specfication of a set of documents, we prefer
the "A polyglot document is" to a "A polyglot document MUST be" style, as we
are not talking about the behaviour of software.
[[

Tim's reiterated this as recently as last month, when we talked about this at
TPAC.

Thanks for the feedback.

Eliot

[1] http://lists.w3.org/Archives/Public/public-html/2010Jun/0225.html

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 16 December 2010 21:11:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:35 UTC