--- This message came from the IEEE 802.11 Task Group M Technical
Reflector ---
I also sympathize with the effort and think Graham's suggestion is an
improvement. However, I also believe that Hunter's point is probably
more important in that, for the most part, people can get the wording
right with little effort (i.e. whether "field is" means "value of the
field is", etc.), but generally ignore the fact that:
"This vagueness has lead to some cases of cited fields, parameters and
elements that have apparently never been transmitted (or invoked)
indicating things."
On the face of it, this would appear to lead to interoperability
issues that could potentially be very difficult to "debug". Assuming
this is correct (?), is there any way to address Hunter's point
without a massive effort?
RR
------------------------------------------------------------------------
*From:****** IEEE stds-802-11-tgm List *****
[mailto:STDS-802-11-TGM@xxxxxxxx] *On Behalf Of *Smith, Graham
*Sent:* Tuesday, May 19, 2015 6:18 AM
*To:* STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
*Subject:* Re: [STDS-802-11-TGM] REVmc comment 5308
I sympathize with the effort. Maybe a slight variation on Adrian’s
suggestion, so as to overcome the duplication of “<x> indicates”:
When <x> represents a field, subfield or scalar parameter:
·"<x> is" is used in a context that relates to the testing or setting
the value of "<x>"
·"<x> indicates" should be interpreted as though written "the value of
<x> indicates”
When <x> represents an element, subelement or structured parameter:
·"<x> indicates" should be interpreted as though written "the contents
of <x> indicate”
.
Graham
*From:****** IEEE stds-802-11-tgm List *****
[mailto:STDS-802-11-TGM@xxxxxxxx] *On Behalf Of *Marc Emmelmann
*Sent:* Tuesday, May 19, 2015 6:04 AM
*To:* STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
*Subject:* Re: [STDS-802-11-TGM] REVmc comment 5308
--- This message came from the IEEE 802.11 Task Group M Technical
Reflector ---
G'Day
I would not object though the last two guidelines on how to interpret
<x> indicates show that
if we do not "decorate" correctly, we might end up in ambiguous
interpretations.
Right now, we would have the choice to replace / interpret "<x>
indicates" with two different
phrases, i.e.: "the value of <x> indicates" vs. "the contents of <x>
indicate".
How about the following:
When "<x> *<verb>"* is used in a context that relates to the
testing or setting the value of "<x>", this usage should be
interpreted as though written "the value of <x> *<verb>*".
This convention applies when <x> represents a field, subfield or
scalar parameter.
In the end, I personally prefer to simply leave the statement at 2.53
as it is. I think it gives enough information and avoids introducing
errors when starting to cover every possible substitution.
On 19 May 2015, at 11:42, 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 ---
Dear TGmc folks,
We have a bunch of related comments requesting additional words to
"decorate" a reference to a field or structure.
We agreed in principle to avoid unnecessary decoration by creating
conventions
in 1.4. I'm looking to create "general purpose" statements to
achieve this.
Please have a look at this resolution and see if it helps:
EDITOR: 2015-05-11 23:53:27Z - at 2.53 replace "When “field is” is
used in contexts that relate to setting or testing the contents of
a field, such as “The XYZ field is set to …” and “If the XYZ field
is equal to 1”, these usages should be interpreted as referring to
the value contained in the field."
with:
When "<x> is" is used in a context that relates to the testing or
setting the value of "<x>", this usage should be interpreted as
though written "the value of <x> is". This convention applies
when <x> represents a field, subfield or scalar parameter.
When "<x> indicates" is used, this usage should be interpreted as
though written "the value of <x> indicates". This convention
applies when <x> represents a field, subfield or scalar parameter.
When "<x> indicates" is used, this usage should be interpreted as
though written "the contents of <x> indicate". This convention
applies when <x> represents an element, subelement or structured
parameter.
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404825 (office)
Tel: +1 (971) 330 6025 (mobile) ⇐ please note new number
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
-----Original Message-----
From: hunter [mailto:hunter@xxxxxxxxxxxxxx]
Sent: Tuesday, May 12, 2015 8:23 AM
To: Stephens, Adrian P
Cc: hunter
Subject: Re: REVmc comment 5308
Hi Adrian,
I understood the "set to" and "equal to" fudge when it happened
because clearly the contents of the field were involved (in fact,
usually they were specifically mentioned).
However, I'm afraid I find a problem with the "indicates" fudge,
because the related text (usually, if not always) mentions no
value, nor, in the case of elements, even what frame the field is
found in. And frequently the text does not even indicate that the
field was ever transmitted or the primitive invoked. This
vagueness has lead to some cases of cited fields, parameters and
elements that have apparently never been transmitted (or invoked)
indicating things.
If the text in each instance at least said "received field" or
"transmitted field" (and in the case of elements, what frames they
were transmitted in), I'd find the text at least somewhat
determinable. But making these changes to much of the text (to
indicate how/when/what the transmission/invocation was) will, I
fear, be harder to accomplish than would simply be the text change
to referencing the value of the field.
(This also is admittedly a fudge, because we frequently still are
left in the air about which transmission of the field or element
is being
referenced.)
Honestly, I don't know a 1.4 saying that would solve these
problems -- unless, of course, the 1.4 words say something like
"when the transmission or invocation of a field, primitive
parameter or element (and the frame that incorporates the element)
is specifically described, then using the phrase "field
indicates", "parameter indicates" or "element indicates" is an
acceptable alternative to referring explicitly to the contents of
the field, parameter or element."
Sorry, doubt that helps with what you're writing,
Thanks, anyway, for asking,
Hunter
On 5/11/2015 4:57 PM, Stephens, Adrian P wrote:
*comments*
*Selected***
*CID***
*Page***
*Clause***
*Resn Status***
*Comment***
*Proposed Change***
*Resolution***
*Owning Ad-hoc***
0
5308
738.11
8.4.2.20.6
"The Channel Number field indicates": fields don't indicate
things,
but their values do.
Replace "The Channel" with "The value of the Channel". On line 17
replace "the Operating" with "the fields of the Operating". On
line 22
replace "Randomization" with "The value of the Randomization".
EDITOR: 2015-05-11 23:53:27Z - After 2.53 "When “field is” is
used in
contexts that relate to setting or testing the contents of a
field,
such as “The XYZ field is set to …” and “If the XYZ field is
equal to
1”, these usages should be interpreted as referring to the value
contained in the field."
Append the following sentence:
When “field indicates” is used to describe the purpose of a
field, or
a condition, this usage should be interpreted as referring to the
value contained in the field."
EDITOR
Hello Hunter,
The sentiment of the group, determined at the TGmc telecom is to
resolve this and similar comments by updating 1.4 to capture the
convention and
thereby avoid touching lots of places in the standard.
The above is my first stab (which needs extension to other
scalar and
structured types). I’m not overly happy with my wording. Can
you
suggest any
improvement to it?
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404825 (office)
Tel: +1 (971) 330 6025 (mobile) çplease note new number
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
_______________________________________________________________________________
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
_______________________________________________________________________________
Note: This message is directed to and is for the use of the
above-noted addressee only, and its contents may be legally privileged
or confidential. If the reader of this message is not the intended
recipient, you are hereby notified that any distribution,
dissemination, or copy of this message is strictly prohibited. If you
have received this message in error, please delete it immediately and
notify the sender. This message is not intended to be an electronic
signature nor to constitute an agreement of any kind under applicable
law unless otherwise expressly indicated hereon.
_______________________________________________________________________________
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
_______________________________________________________________________________