Re: [STDS-802-11-TGM] FW: Use of "should" in an informative annex
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Brain is hurting from reading Hunter's ravings...sorry, constructive reasoning, below.
From all that I have seen I still see no real argument against using 'should' in informative annexes - the only rule we need is 'thou shalt not use "shall"' At the same time I find nothing wrong with calling an Annex "recommended practices" and using "it is recommended that' in the text. This, to me, seems to be an ideal subject for an Annex. In addition, recommended practices can then certainly be taken as 'do it this way' in any related test procedures. If this is the case, I may well be persuaded to then possibly upgrade the text to mandatory action, but that is not totally necessary.
Graham
-----Original Message-----
From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of hunter
Sent: Friday, March 14, 2014 2:12 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] FW: Use of "should" in an informative annex
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Following up on Mark's point about modals: there are many modal preference terms. While there may not be a synonym that covers more than one of the meanings of "should", there are many other ways to express preference: 'ought', 'is preferred', 'has a preference for', 'is recommended', 'supposed to', 'needs to', 'have to', 'is right', 'is wrong', 'is obligated', 'is the goal', 'is agreed', 'is found in this authoritative book', 'my market dominant company does', 'is stated in IEEE Std 802.11-1997', .... Even 'is in most implementations' has a preferential aspect.
But permit me to step back a pace: is the 802.11 goal to make the IEEE Style Manual discouragement of "shall", "should", "may" in informative text a purely syntactical restriction? That is, is the goal that the only restriction is on the use of the exact words "shall", "should", "may" (and their direct derivatives "shall not", "shouldn't", "may not",
etc.) in informative material?
If that goal is agreed, then we can easily agree never to use "should"
in informative material, but allow any of the other modal (which is a semantic, not syntactical, concept) terms. Given that restriction, why would we need to determine a specific alternate to "should"? Let the author of the informative text choose whatever other expression of preference he/she/it prefers (whatever the author claims to be needed, preferred, recommended, morally obligated).
A syntactical rule is easiest to enforce ("never use that word in this environment"), so what is wrong with such a rule?
If a syntactical rule is the goal, then why not simply include the "shall not use 'shall', 'should' or 'may' in informative material" rule in the IEEE 802.11 Style Guide?
The Style Guide already includes many other restrictions that we
(P802.11) impose on top of those in the Style Manual; is there a problem with adding one more?
Per Adrian's point about testing: a test can only evaluate 'is'/'is not'. A complete test suite (one that tests all of the 'may's as well as the 'shall's) will have to test all of the 'should's as if they were 'may's. The problem comes with partial test suites -- one supposes that there is greater likelihood that a partial test suite will test the 'should's than the 'may's, but I wouldn't bet on it.
On 3/14/2014 06:57, Ed Reuss wrote:
> --- This message came from the IEEE 802.11 Task Group M Technical
> Reflector --- Yes, the satire behind the thread did not escape me, but
> it did give me the opportunity to climb up on my soapbox about a sore
> point of mine with several letter ballot documents that I've reviewed
> over the last few years. (Another pet peeve is the abuse of passive
> voice, strangling a sentence to within 2.54 mm of its life).
>
> A friend of mine on the SMPTE Standards Committee has a list of about
> a dozen of the most common mistakes found in standards documents that
> violate the ISO directive mentioned earlier. I will try to find it and
> forward it to this audience.
>
> -- Ed Reuss
>
> On Mar 14, 2014, at 2:41 AM, "Stephens, Adrian P"
> <Adrian.P.Stephens@xxxxxxxxx <mailto:Adrian.P.Stephens@xxxxxxxxx>> wrote:
>
>> --- This message came from the IEEE 802.11 Task Group M Technical
>> Reflector ---
>>
>> Interesting reference.
>>
>> <humour note=”for those that didn’t realize I’m not being entirely
>> serious below”>
>>
>> We might consider “dare to” for “should not” and “had better” for
>> “should”.
>>
>> </humour>
>>
>> Best Regards,
>>
>> Adrian P STEPHENS
>>
>> Tel: +44 (1793) 404825 (office)
>> Tel: +44 (7920) 084 900 (mobile, UK)
>>
>> Tel: +1 (408) 2397485 (mobile, USA)
>>
>> ----------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>>
>> *From:****** IEEE stds-802-11-tgm List *****
>> [mailto:STDS-802-11-TGM@xxxxxxxx] *On Behalf Of *Mark Rison
>> *Sent:* 14 March 2014 09:11
>> *To:* STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
>> <mailto:STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
>> *Subject:* Re: [STDS-802-11-TGM] FW: Use of "should" in an
>> informative annex
>>
>> --- This message came from the IEEE 802.11 Task Group M Technical
>> Reflector ---
>>
>> > there are no synonyms for “should”.
>>
>> "ought to"?
>>
>> English has a rich set of
>> http://en.wikipedia.org/wiki/English_modal_verbs
>> <http://en.wikipedia.org/wiki/English_modal_verbs>
>>
>> , so we had better find one!
>>
>> Mark
>>
>> --
>>
>> Mark RISON, Standards Architect, WLAN English/Esperanto/Français
>>
>> Samsung Cambridge Solution Centre Tel: +44 1223 434600
>>
>> Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
>>
>> ROYAUME UNI WWW: http://www.samsung.com/uk
>>
>> *From:****** IEEE stds-802-11-tgm List *****
>> [mailto:STDS-802-11-TGM@xxxxxxxx] *On Behalf Of *Stephens, Adrian P
>> *Sent:* 14 March 2014 07:07
>> *To:* STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
>> <mailto:STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
>> *Subject:* Re: [STDS-802-11-TGM] FW: Use of "should" in an
>> informative annex
>>
>> --- This message came from the IEEE 802.11 Task Group M Technical
>> Reflector ---
>>
>> Hello Ed,
>>
>> I hear what you’re saying. I’m separately asking the IEEE-SA
>> editors to clarify this in the style guide.
>>
>> We may discover that there is a different position once the issue has
>> been considered by the group
>>
>> of folks who review this document.
>>
>> Thinking aloud here, does “should” encompass “may” or not?
>>
>> If “should” gives a recommendation to do something that is already
>> permitted.
>>
>> (A STA may do x. If y happens, the STA should do x.), then you
>> could argue that you already have
>>
>> to encompass in your testing a STA doing x and not doing x.
>>
>> But if (A STA should do x) is the only mention of the ability of a
>> STA to do x, you could argue that this
>>
>> is a “superset of may”, and has a test case caused by the “should”.
>>
>> In this sense we might distinguish normative and informative
>> “shoulds”. If folks agree with this logic,
>>
>> then we really need two verbs to distinguish them. synonym.com
>> <http://synonym.com> claims there are no synonyms for
>>
>> “should”.
>>
>> Best Regards,
>>
>> Adrian P STEPHENS
>>
>> Tel: +44 (1793) 404825 (office)
>> Tel: +44 (7920) 084 900 (mobile, UK)
>>
>> Tel: +1 (408) 2397485 (mobile, USA)
>>
>> ----------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>>
>> *From:****** IEEE stds-802-11-tgm List *****
>> [mailto:STDS-802-11-TGM@xxxxxxxx] *On Behalf Of *Edward Reuss
>> *Sent:* 13 March 2014 17:31
>> *To:* STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
>> <mailto:STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
>> *Subject:* Re: [STDS-802-11-TGM] FW: Use of "should" in an
>> informative annex
>>
>> --- This message came from the IEEE 802.11 Task Group M Technical
>> Reflector ---
>>
>> Further to Mr. Hunter's point,
>>
>> > the IEEE Style Manual (2012) rule is "Interspersed normative and
>> informative text is not allowed."
>>
>> This requirement does not use conformance language "shall", "shall
>> not", "should", "should not", "may", "may not", "must", or "must
>> not". Instead, it uses "is not". This means that technically, as per
>> the ISO/IEC Directives, Part 2, "Rules for the structure and drafting
>> of International Standards", this clause in the IEEE Style Manual is
>> informative, and therefore not a normative requirement for an IEEE
>> international standards document. ;-)
>>
>> Seriously though, we have to be very careful with this because
>> someone has to turn the output of our work into a validation test
>> procedure, whether in the Wi-Fi Alliance or internally within a
>> vendor company. The distinction of normative text versus informative
>> text is critical to this purpose.
>>
>> If an informative annex needs to make a recommendation, then it's not
>> really informative. An implementor can ignore all informative parts
>> of the standard and still implement a solution that normatively
>> complies to the standard. If the authors wish to encourage a
>> particular method for implementing a feature, for interoperability or
>> performance reasons, then that needs to be stated normatively.
>>
>> In practical terms, this means the entire annex probably needs to be
>> made normative, or at least broken into sub-parts most of which can
>> be informative, but those parts that specify the recommended
>> procedure be marked as normative. (More work for the editors, to
>> which I apologize, but the Wi-Fi Alliance will thank you in the end).
>>
>> I hope I don't sound like I'm trying to "teach my own grandmother how
>> to suck an egg", but I see too many drafts come to letter ballot that
>> do not observe these requirements. I try to comment on them, but
>> there are often too many to cite in letter ballot comments within the
>> allocated time.
>>
>> -- Ed Reuss
>>
>> On Thu, Mar 13, 2014 at 5:18 AM, hunter <hunter@xxxxxxxxxxxxxx
>> <mailto:hunter@xxxxxxxxxxxxxx>> wrote:
>>
>> --- This message came from the IEEE 802.11 Task Group M Technical
>> Reflector ---
>>
>> Hi Adrian,
>>
>> 'Should' entails 'may', so 'may' must also be allowable in an
>> informative annex.
>>
>> And, 'may' entails "it is not the case that it shall not", so
>> 'shall' is equally permissible (though perhaps some accompanying
>> negatives may be required).
>>
>> Consequently there is no IEEE Standards Association reason to
>> avoid any normative term in an informative annex.
>>
>> Since the IEEE Style Manual (2012) rule is "Interspersed
>> normative and informative text is not allowed.", then the
>> official permission of normative terms in an informative annex
>> means that in such an annex the normative terms do not constitute
>> normative text. Normative terms may be used in an informative
>> annex, because they can't be normative text.
>>
>> Peachy; got it.
>>
>> Thanks for finding this out,
>>
>> Hunter
>>
>> By the way, in the American version of Latin derivatives the term
>> "volte-face" (pronounced "volt-face", singularly apropos in an
>> electrical engineering standard) uses a hyphen.
>>
>>
>> On 3/13/2014 00:12, Stephens, Adrian P wrote:
>>
>> --- This message came from the IEEE 802.11 Task Group M
>> Technical Reflector ---
>>
>> Please see below…
>>
>> This relates to CID 2401 reviewed yesterday.
>>
>> Michelle does not support my position. So, I shall do a volte
>> face.
>>
>> We should, IMHO, resolve this comment by changing the
>> heading, as “recommended practice” has a
>>
>> special meaning in IEEE-SA parlance. We might consider
>> replacing “it is recommended that” with “should”
>>
>> and use the active voice, e.g. “It is recommended that pigs
>> fly” becomes “Pigs should fly”.
>>
>> Best Regards,
>>
>> Adrian P STEPHENS
>>
>> Tel: +44 (1793) 404825 <tel:%2B44%20%281793%29%20404825> (office)
>> Tel: +44 (7920) 084 900 <tel:%2B44%20%287920%29%20084%20900>
>> (mobile, UK)
>>
>> Tel: +1 (408) 2397485 <tel:%2B1%20%28408%29%202397485>
>> (mobile, USA)
>>
>> ----------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ
>> VAT No: 860 2173 47
>>
>> *From:*Michelle Turner [mailto:m.d.turner@xxxxxxxx
>> <mailto:m.d.turner@xxxxxxxx>]
>> *Sent:* 12 March 2014 18:08
>> *To:* Stephens, Adrian P
>> *Cc:* Kim Breitfelder
>> *Subject:* Re: Use of "should" in an informative annex
>>
>> Hi Adrian
>>
>> It's fine to have "should" in an informative annex. I would,
>> however, not use the words "Recommended Practice" in the
>> heading as that is a document type. Rather, I recommend (ha!)
>> something like, "Recommendation for implementation of..." We
>> can discuss more next week. See you in Beijing :-)
>>
>> On Wed, Mar 12, 2014 at 11:41 AM, Stephens, Adrian P
>> <Adrian.P.Stephens@xxxxxxxxx
>> <mailto:Adrian.P.Stephens@xxxxxxxxx>
>> <mailto:Adrian.P.Stephens@xxxxxxxxx
>> <mailto:Adrian.P.Stephens@xxxxxxxxx>>> wrote:
>>
>> Hello Michelle,
>>
>> Can you help me with a question – potentially reaching
>> out to your
>> fellow editors for a consensus.
>>
>> In 802.11, we have an informative annex that contains
>> “should”
>> statements (and “recommended practice” in the heading).
>>
>> Is this valid?
>>
>> One viewpoint is that anything that affects an
>> implementation is
>> normative, because that is the whole
>>
>> purpose of a standard. So this is an inconsistency.
>>
>> Another viewpoint is that a “should” doesn’t require
>> anything,
>> because it’s not a “shall” – whether
>>
>> the manufacturer follow it or not is up to them.
>>
>> What is your position?
>>
>> Best Regards,
>>
>> Adrian P STEPHENS
>>
>> Tel: +44 (1793) 404825 <tel:%2B44%20%281793%29%20404825>
>> <tel:%2B44%20%281793%29%20404825> (office)
>> Tel: +44 (7920) 084 900
>> <tel:%2B44%20%287920%29%20084%20900>
>> <tel:%2B44%20%287920%29%20084%20900>
>> (mobile, UK)
>>
>> Tel: +1 (408) 2397485 <tel:%2B1%20%28408%29%202397485>
>> <tel:%2B1%20%28408%29%202397485> (mobile, USA)
>>
>> ----------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ
>> VAT No: 860 2173 47
>>
>>
>>
>> --
>>
>> Michelle Turner
>> Managing Editor, Technical Community Content Publishing
>>
>> IEEE Standards Association
>> e-mail: m.d.turner@xxxxxxxx <mailto:m.d.turner@xxxxxxxx>
>> <mailto:m.d.turner@xxxxxxxx <mailto:m.d.turner@xxxxxxxx>>
>> PH: +1 732 562 3825 <tel:%2B1%20732%20562%203825>; FAX: +1
>> 732 562 1571 <tel:%2B1%20732%20562%201571>
>>
>>
>> _____________________________________________________________________
>> __________
>>
>>
>> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT
>> send your request to this CLOSED reflector. We use this
>> valuable tool to communicate on the issues at hand.
>>
>> SELF SERVICE OPTION: Point your Browser to -
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM
>> and then amend your subscription on the form provided. If you
>> require removal from the reflector press the LEAVE button.
>>
>> Further information can be found at:
>> http://www.ieee802.org/11/Email_Subscribe.html
>>
>> _____________________________________________________________________
>> __________
>>
>>
>>
>> _____________________________________________________________________
>> __________
>>
>> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send
>> your request to this
>> CLOSED reflector. We use this valuable tool to communicate on the
>> issues at hand.
>>
>> SELF SERVICE OPTION:
>> Point your Browser to -
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and
>> then amend your subscription on the form provided. If you
>> require removal from the reflector
>> press the LEAVE button.
>>
>> Further information can be found at:
>> http://www.ieee802.org/11/Email_Subscribe.html
>> <http://www.ieee802.org/11/Email_Subscribe.html>
>>
>> _____________________________________________________________________
>> __________
>>
>> _____________________________________________________________________
>> __________
>>
>>
>> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send
>> your request to this CLOSED reflector. We use this valuable tool to
>> communicate on the issues at hand.
>>
>> SELF SERVICE OPTION: Point your Browser to -
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then
>> amend your subscription on the form provided. If you require removal
>> from the reflector press the LEAVE button.
>>
>> Further information can be found at:
>> http://www.ieee802.org/11/Email_Subscribe.html
>> <http://www.ieee802.org/11/Email_Subscribe.html>
>> _____________________________________________________________________
>> __________
>>
>> _____________________________________________________________________
>> __________
>>
>>
>> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send
>> your request to this CLOSED reflector. We use this valuable tool to
>> communicate on the issues at hand.
>>
>> SELF SERVICE OPTION: Point your Browser to -
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then
>> amend your subscription on the form provided. If you require removal
>> from the reflector press the LEAVE button.
>>
>> Further information can be found at:
>> http://www.ieee802.org/11/Email_Subscribe.html
>> <http://www.ieee802.org/11/Email_Subscribe.html>
>> _____________________________________________________________________
>> __________
>>
>> _____________________________________________________________________
>> __________
>>
>>
>> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send
>> your request to this CLOSED reflector. We use this valuable tool to
>> communicate on the issues at hand.
>>
>> SELF SERVICE OPTION: Point your Browser to -
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then
>> amend your subscription on the form provided. If you require removal
>> from the reflector press the LEAVE button.
>>
>> Further information can be found at:
>> http://www.ieee802.org/11/Email_Subscribe.html
>> <http://www.ieee802.org/11/Email_Subscribe.html>
>> _____________________________________________________________________
>> __________
>>
>> _____________________________________________________________________
>> __________
>>
>>
>> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send
>> your request to this CLOSED reflector. We use this valuable tool to
>> communicate on the issues at hand.
>>
>> SELF SERVICE OPTION: Point your Browser to -
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then
>> amend your subscription on the form provided. If you require removal
>> from the reflector press the LEAVE button.
>>
>> Further information can be found at:
>> http://www.ieee802.org/11/Email_Subscribe.html
>> _____________________________________________________________________
>> __________
>>
>>
> ______________________________________________________________________
> _________
>
>
> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your
> request to this CLOSED reflector. We use this valuable tool to
> communicate on the issues at hand.
>
> SELF SERVICE OPTION: Point your Browser to -
> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then
> amend your subscription on the form provided. If you require removal
> from the reflector press the LEAVE button.
>
> Further information can be found at:
> http://www.ieee802.org/11/Email_Subscribe.html
> ______________________________________________________________________
> _________
>
>
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email Security System.
_____________________________________________________________________
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email Security System.
_____________________________________________________________________
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________