Part 5 clarification on NOT operator

[jmgnc]

I have raised an issue w/ the pattern matcher library, and there is probably some clarification that we should add to the spec:
oasis-open/cti-pattern-matcher#53

[treyka]

@jmgnc Could you please suggest text for the clarification?

[jmgnc]

We accepted the clarification that I suggested in the issue. I do not know of any additional clarification, though it is clearly needed as @gtback thinks that their implementation is correct to the spec, though my reading says it is not.

I have a request out to him to work w/ me on clarifying the text, and hopefully reopening the issue so that it can be resolved. I'd prefer if most of the discussion can happen in the other issue to keep things contained to one place.

[JasonKeirstead]

Most of the debate for this is in oasis-open/cti-pattern-matcher#53 . The issue is still unresolved as we didn't actually make any of the clarification changes in that document.

My original suggestion (and it still stands)

This text:

A Comparison Operator MAY be preceded by the modifier NOT, in which case the resultant Comparison Expression is logically negated.

Should be changed to this text.

A Comparison Expression MAY be preceded by the modifier NOT, in which case the resultant Comparison Expression is logically negated.

Note the difference, it is bold. Also, the text should be moved up to the "Comparison Expression" section, since this is where it now belongs.

This text changes this from the allowed syntax (which I don't think was ever the intent)

[ a:b[*] NOT = 22 ]

.. to this

[ NOT a:b[*] = 22 ]

... thus making the syntax much more understandable, and clarifies order of operations.

This is a pseudo-breaking change in patterning, but I doubt it will affect anyone in reality because it is changing some esoteric behaviour.

[jordan2175]

We talked about this on 2019-06-05 and Jason agreed to add proposed text to the document.

[srrelitz2]

To be discussed at the 4 Oct meeting. Follow up with implementation evaluation. Errata change or normative change?

[srrelitz2]

Specification is ambiguous. Add clarity in 2.1.1 and match the grammar and code for STIX python to all say the same thing.