clause 15 and annex L2

Peter walked through the series of changes to address issues raised

with the ScanStructure extensions, for instance changing the term

'state-element' to 'internal-reference', and the augmentation of the

example to contain 2 instances of complex cells.

Doug moved to accept these changes, Peter seconded, we all were in favor.

clause 22 (attached pdf) - pattern fail report

Tom had some questions about the current proposal, as well as

questions that Doug asked in the ballot document for review.

Tom identified that the Xref-ID construct is better than supporting an

integer identifier here, and the LogStart and LogStop constructs look good.

However Tom's first question was asking whether LogStart and LogStop

need to support the general dotted construct of

nested-Xref-identifiers. He proposed that the constructs on LogStart

and LogStop match the dotted-construct present in FailData. The

Working Group agreed with this change.

[AI1] Tony or current spec owner change (X_REF_ID) in these statements

to (X_REF_ID(.X_REF_ID)*)

Tom's second question identified a concern about the requirement for

an X_REF_ID in the FailData - what happens if there is no Xref

statements in a pattern set? Greg identified that the current proposal

is that a default construct is used here, and after some hunting we

located the definition of that default being the Pattern name (under

section a of item (8) fail data record. Tom raised a concern that now

this name affects the namespace of the X_REF_ID strings. The group

enjoyed a discussion of the pros and cons for making this field

optional to support the case of no xref labels to use, or of supporting an

implicit behavior to define a default start-of-pattern label and

requiring the xref field to be present (the current

definition). Neither proposal was winning out, until one of Doug's

review questions DS-4 number 3 was brought into the discussion, about

allowing Xref constructs to be integers, and the ambiguity caused by

allowing this.

At the end of the discussion, the Work Group made the following resolutions:

(a) that X_REF_IDs *CANNOT* be integers. They are strings, if an

application chooses to use integers for these strings then the

application quotes the integers and all is set.

(b) that the X_REF_ID field remains required in a FailData statement.

(c) that if no X_REF_ID is available for a failure, either because the

pattern contains no Xref statements or because the failure occurs

before the first Xref statement present, then the default X_REF_ID

value specified in the FailData statement is 0 - that is, the integer

zero, unquoted. This value was choosen because (a) it doesn't conflict

with the namespace of user-specified X_REF_IDs, and (b) it's short.

[AI2] remove all indication that X_REF_ID can be integer

[AI3] change the default X_REF_ID from "pattern name" to 0.

Tom's third question was in regards to a sentence in section a of

item (8) fail data recored - that "Reference shall always be to the

last X reference encountered", which is change to previous wording

"most recent X reference" that Doug questioned under DS-4 number 4.

Both raised a common concern: what was this trying to clarify, and

aren't Xref statements unique in a context?

After some review it was identified that X_REF_IDs are not currently

identified as being unique.

The Working Group feels that the proper resolution of the issue of

ambiguity of statements is to require that each X_REF_ID string be

unique in the context it is found under; that is for all Xref

statements at the same level of nesting in a STIL block.

Remove the last sentence of section A, and change last sentence of

section to 'O'.

sect c - "label" needs to changed to "tagged with x-ref".

--------

multiple strobes per cycle -

put stmt this outside scope

put 'per strobe' instead of 'per cycle', measured data cannot be

interpreted w/o a lot of addtional context.

if multiple measures, must use dotted cycle offset.

cannot present streamed data on observes in this context...

no muliple values on observe data in this context.

start at 0.

1450.1 status for submittal to TTCS

accepted status as in agenda (above)

Meeting ended at 11:00