Phone Conference P1450.3 Working Group
Thursday, Sept 28, 2005 - 10:00-11:30 Pacific Time
Tony Taylor (chair)
Greg Maston (scribe)
http://grouper.ieee.org/groups/1450/private/1450.3-D14.pdf (july 11, 2006)
http://grouper.ieee.org/groups/1450/dot3/comments.xls (updated sep 27, 2006)
Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.
To address the IEEE issue with "informative in the body of the spec", Tony proposed two changes:
- remove "informational" on clause 1.
- move clause 5 to an annex, possibly multiple annexes to allow separate referencing of external parties on respective issues.
Both changes unanimously approved.
Discussed item #48, which we hope is handled by moving the example to the annex (hopefully eliminating any issue with it being normative)
Discussed the block merge rules for some time. To address data assembly from separate blocks, Tony proposed eliminating all implicit data collection from unnamed groups, and support of an explicit statement such as InheritSignalAttributes. Tony took an AI to consider the effects to the language of adding these Inherit* statements.
In addition, there was discussion about the capability to reference multiple blocks to define parallel sets of constraints, currently defined in the standard as an implicit OR function between multiple reference statements within one block. Proposal is to make the ORing function explicit, allowing only 1 reference statement with all referenced blocks identified with a vertical bar between each name to explicitly identify the behavior. Greg is concerned about the derivation of the decision tree defined by this construct, necessary to establish whether the rules pass or not. Also there will always be questions from consumers of this data if both paths pass, and different tools report different paths as being successful - both are right, and neither agree with each other. Greg feels the standard needs to clarify sufficiently the semantics and interpretation of the constructs such that consistent conclusions can be made.
This discussion also raised the issue of how to handle fluid constructs, which are likewise difficult to establish a value for in order to run through the rules to see what passes. Tony indicated that this type of constraint check may be another type of operation not identified in the current chart, and that it may be necessary to limit the constructs defined in order to establish an evaluateable set of constraints that can be checked against a STIL test without going down the path of resource allocation in order to rules check. (Note after meeting by Tony - Upon closer review of Figure 1, I believe that the constraint application is part of flow (1) and that we should add the term "resource constraint" to the diagram. Also, we should identify that fluid constraints and ORing conditions should not be used in this application.)
Clarified several smaller concerns.
Meeting adjourned 11:20 Pacific time
Date: Next meeting Thursday, Oct
Time: 10:00 to 11:30 Pacific time