IEEE-SA Ballot results and discussion

From: <darren.galpin@infineon.com>
Date: Tue Feb 01 2011 - 00:19:07 PST

The IEEE-SA 1647 ballot results are as follows:-

Ballot Open Date: 16-Dec-201016-Dec-2010 GMT
Ballot Close Date: 31-Jan-201131-Jan-2011 GMT
Draft #: 8-3
Comments: 14
Must Be Satisfied Comments: 1

RESPONSE RATE
This ballot has met the 75% returned ballot requirement.
30 eligible people in this ballot group.
28 affirmative votes
0 negative votes with comments
0 negative votes without comments
2 abstention votes: (Lack of time: 2)
30 votes received = 100% returned
6% abstention
APPROVAL RATE
The 75% affirmation requirement is being met.

So the vote passed! Thank you to all of your hard work on this.

There were 14 comments listed, 1 being marked as "must be satisfied". However, when examining the comments listed on the website I can only find 13, and none are marked as "must be satisfied". The comments submitted were as follows:-

Date: 29-Jan-2011 3:48:25 EST
Must Be Satisfied: No
Category: Editorial
Page: 100
Subclause: 6.8.1.2
Comment: Occurences of cannot or can should be replace with shall not and shall to follow standard terminology

Date: 29-Jan-2011 3:22:59 EST
Must Be Satisfied: No
Category: Editorial
Page: 82
Subclause: 5.4.4
Comment: The following sentecne does not use proper standard terminology:
The key of a keyed list cannot be of type real.
5.5
Proposed Change: The key of a keyed list shall not be of type real.
5.5

Date: 29-Jan-2011 3:19:12 EST
Must Be Satisfied: No
Category: Editorial
Page: 80
Subclause: 5.4.1
Comment: This sentence "In any context expecting a numeric object, a real object is acceptable..."
would be better rewritten as:
"A real object may be used (or is legal) in any context except ..."

Date: 29-Jan-2011 3:11: 5 EST
Must Be Satisfied: No
Category: Technical
Page: 77
Subclause: 5.2
Comment: The section before 5.2 describes the untype pseudo type. The section 5.2 lists the untypes expressions which do not include variable of the untyped pseudo type. Why? Is this an omission?

Date: 29-Jan-2011 3: 4:55 EST
Must Be Satisfied: No
Category: Editorial
Page: 75
Subclause: 5.1.8
Comment: The text says that Multi dimensional lists (list of lists) are not supported.
I think it would be more correct to say that the Language does not define lists of lists or that a list element shall not be a list.

Date: 29-Jan-2011 2: 3:21 EST
Must Be Satisfied: No
Category: Technical
Page: 62
Subclause: 4.12.2.2
Comment: That section title is unexistent bits. However except for the first sentence, the others seems unrelated to that section.
Please move unrelated description to another section

Date: 29-Jan-2011 1:51:53 EST
Must Be Satisfied: No
Category: Technical
Page: 58
Subclause: 4.10.5
Comment: Define what type comparable means.
Should it say type compatible instead?

Date: 29-Jan-2011 1:41:38 EST
Must Be Satisfied: No
Category: Technical
Page: 50
Subclause: 4.7.2
Comment: The reference 5.5 looks incorrect it points to section titled Precision Rules for numeric operations.
Please correct

Date: 29-Jan-2011 1:33:58 EST
Must Be Satisfied: No
Category: Technical
Page: 49
Subclause: table 12
Comment: Consider adding wildcard equiality operators ==?
and !=? like in SystemVerilog, where x and z values act as wildcard.

Date: 29-Jan-2011 1:26:35 EST
Must Be Satisfied: No
Category: Technical
Page: 48
Subclause: 4.4
Comment: At the end of the section 4.4 Ranges, there is that sentence:
"If the scalar type is an enumerated type, it is ordered by the value associated with the integer value of each type item."

Either:
It seems to me that this sentence does not belong in this section and should be better moved to a section talking about enumeration types.

OR:
if the consequence of this sentence is that you can define a range consisting of enumeration constants (since those are ordered by their value not by their positionin the declaration), a second sentence should describe this. It is not really clear how to define a range of enumeration values.
Please provide an example

Please clarify this

Date: 31-Jan-2011 22:21:32 EST
Must Be Satisfied: No
Category: General
Comment: There's no mention of the revision history anywhere within the draft, not even within the Introduction ...
Proposed Change: Make mention of the revision history, at least in summary and at least within the introduction. If changes are extensive, consider listing them at an appropriate level of detail within a suitable annex.

Date: 31-Jan-2011 22:19: 5 EST
Must Be Satisfied: No
Category: General
Comment: With regret that I did not flag this sooner and with ample time for the comment to be resolved in the course of the ballot, as I was unable to find a summary of the changes in the revision draft versus the prior version of the approved standard, I found myself unable to review the document in its entirety so as to be able to provide an authoritative approve or disaprove vote - hence my abstention.
Proposed Change: Provide the balloters with a summary of the changes in the revision draft versus the prior version of the approved standard.

It should be noted that we do not have to address these for this standard in order for it to progress - perhaps Andy and Yaron would like to share their experiences on this. What do people think about the comments? In the meantime, I'm trying to find out what the must be satisfied comment is, and will get back to you when I know.

Cheers,

Darren

------------------------------------------------------------------------------------
Darren Galpin Tel: +44 117 9528741
Infineon Technologies Fax: +44 117 9528777
Infineon House Darren.Galpin@infineon.com<mailto:Darren.Galpin@infineon.com>
Great Western Court
Hunts Ground Road
Stoke Gifford
Bristol, BS34 8HP, England.
------------------------------------------------------------------------------------

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Feb 1 00:19:50 2011

This archive was generated by hypermail 2.1.8 : Tue Feb 01 2011 - 00:19:56 PST