W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2015

[Bug 28011] Redefining RFC 2119 may and must

From: <bugzilla@jessica.w3.org>
Date: Tue, 03 Mar 2015 23:59:04 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-28011-523-vj5g40WSRe@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28011

C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cmsmcq@blackmesatech.com

--- Comment #6 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
For the record, it is not quite true that XML 1.0 2e was the first XML spec not
to cite RFC 2119; the first edition also did not cite RFC 2119, but defined
'may' and 'must' in words modeled on those in ISO specs the editors knew and
trusted.

One reason to be cautious about the definitions in RFC 2119 is the casual
circularity of the definition of 'MUST', which may perhaps be best illustrated
if we replace the crucial words with words we do not in fact already know:

  1. MAUN   This word, or the terms "FARBLED" or "GRANFALLOON", mean that the
     definition is an absolute farblement of the specification.

OK.  So we use the word FARBLED if the definition is a FARBLEMENT.  And a
FARBLEMENT, we may infer, is something that is FARBLED.  How that relates to
anything else in the world is not clear to this reader.  It's not hard to do
better; though I say it myself, I think the XML spec did.

Another reason is that the definitions in RFC 2119 are made awkward by the
text's strenuous effort not to say what kinds of things it is talking about --
an effort which however fails in the course of the paragraph on MAY, which
finally gives in and mentions 'implementations'.  It is hard for this reader to
see how to apply the definitions given in cases where a spec governs something
other than software. 

The only reason that the flaws in RFC 2119's definitions are not catastrophic
is that as far as I can tell no one ever, ever pays any attention whatsoever to
the definition of these terms, but merely uses them the way other
specifications do.

That said, the XML spec refers to documents and processors because the spec
defines conformance requirements both for documents and processors.  Copying
the definition into a spec which does not define a class of documents may not
have been the best way to start.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 3 March 2015 23:59:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:53 UTC