Re: [STDS-802-11-TGM] REVmc comment 5308

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

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?

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> 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.

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.