Phone Conference P1450.3 Working Group

Thursday, Oct 12, 2005 -  10:00-11:30 Pacific Time




Attendees:

Tony Taylor (chair)

Greg Maston (scribe)

Dave Galagher

Jose Santiago
 

Docs:

 

    http://grouper.ieee.org/groups/1450/private/1450.3-D15.pdf (oct 10, 2006)

    http://grouper.ieee.org/groups/1450/dot3/comments.xls (oct 10, 2006)

 

Agenda:

 
1. naming and referencing of blocks
... the awkwardness of referencing global blocks and the use of the double colon ... especially when used to access global/unnamed blocks. See the code snippet in clause 11 - PatternAttfibutes  (in the pdf that I sent out as an attachment on Friday).
 
My latest thinking is that we should ONLY allow referencing named blocks and that any named blocks in a global TRC get included into the same name space as the current TRC block. This completely removes the need for the ugly double colon.
2. how do the global blocks get used
A related issue is how do the global blocks get used. And also, how does a named Module block get used. Well ... these are the entry points into the TRC interpretation process. A user would select an environment-name and a TRC-name. The process would then have to look for a global/unnamed SignalAttributes block and all (named) Module blocks. These to be processed as "OR" conditions for all the resources (instruments) in the tester. I need to review the document to see if this is described adequately.
3. AND, OR vs. rules in clause 11 - i.e., our latest change on referencing pat-attr-blocks
 
4. All the Yellow and Blue comments in the spread sheet
 

Discussion:

 

Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.

pg 15 sections describing ANDing and ORing of blocks are obsolete given new construct organization. Strike out sections (c) and (d) on this page.

pg 17 discussed referencing unnamed blocks and ugly syntax associated with it. Greg proposed that unnamed (global) blocks be eliminated, requiring a name on all blocks that can be referenced. Tony proposed that named blocks defined in an unnamed TRC block should be globally accessible – that the namespace of each block-type include the blocks defined under the global TRC block, allowing access to these blocks when no name on the TRC block is present.

Discussed the requirement for a Module block under the TRC. Proposal is that the TRC block shall have two forms: one when a Module or multiple Module blocks are present, and the other without the Module block. When Module blocks are present, all other blocks that are referenced in the Module shall have names, and any unnamed block in this context cannot be accessed. When there are no Module blocks in a TRC block, then all other blocks shall NOT have names (Greg’s proposal to eliminate unnamed blocks appropriately modified). This configuration (sans Module) is used for constraint-checking, and the constraint process shall use the unnamed blocks to start rules-checking directly.

Regular expression reference: Greg took an AI to see if he could find any library environment to support this facility.

Meeting adjourned 11:30 Pacific time

 


Next meeting

Date: Next meeting - impromptu at ITC (see Tony at STC booth if you want to participate)

Next phone meeting - nov 9, 10:00 to 11:30 pacific time

 


Action Items:

- Greg - to investigate reg-expr library

- Tony - to continue updating D15