RE: [sv-ac] call to vote on 1757

Hi Lisa,,

 

Please see my comments below

 

 

1.	I think the changes to 16.5 should be removed. This text is
disable iff, not accept_on/accept_off.  And if it stays, then 1648 will
need to change its reference relative to whether or not this was
adopted.  Also, I see no reason that 1648 would not get adopted now that
we have changed it from "default disable" to "default disable iff".   

[[DB:]] 

[[DB:]] but boolean expressions occurs also in accept_on/reject_on. So
limiting them to sequences, is an error for 1757 as well. Isn't it?

 

2.	In the following sentence, the word "may" should be "shall"
(twice):  "While a disable condition of a disable iff in a property_spec
may cause an evaluation of the property_spec to be disabled, an abort
condition of accept_on in a property_expr may cause the evaluation of
the property_expr to be true."

 

[[DB:]] I see your point here. I deliberately put the "may" there,
because if the disable/abort condition occurs after the 

[[DB:]] end of the evaluation it does not change its result. I am not
sure what to do here

 

3.	The following sentence should be deleted because the example
shown below it does not show nested operators and more importantly it is
repeated again with an appropriate example a few lines down: " In
particular, when reject_on ( or accept_on) appears in nested properties,
the outermost abort condition takes precedence over inner abort
conditions."

 

[[DB:]] I fixed it

[[DB:]] 

 

4.	In 36.45, should "property expr"  be "property_expr"
(underscore separated and italics)?

[[DB:]]  I fixed it

 

5.	In the text you have that the semantics of reject_on(b) is :
not(accept_on(expression_or_dist) not(property_expr)).   But in F.2.3
you have - ( reject_on ( b ) P) =  ( not accept_on (b) not P )
I'm not sure if the additional parenthesis in the text is significant
:-)  I understand the version with parenthesis without having to go back
and study the precedence to see if it matters. 

 

[[DB:]] I think it should remain this way just to be consistent with the
rest of the subsection.

 

Thanks

 

Doron

 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.