[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] STIX Patterning - ALONG/OTHERWISE
|
We could also have a single table that captures the semantics for both Observation Expressions and Comparison Expressions:
Regards, Ivan From: Ivan Kirillov <ikirillov@mitre.org> > You now have two tables which describe `AND/OR`, which is confusing. Yeah, I think that’s one of the potential downsides to this approach. I suppose the question is whether it’s more confusing to have two tables with slightly different semantics for AND/OR or instead have different
terms for the AND/OR used between Observation Expressions (which is the previous approach with ALONGWITH/OTHERWISE). Another possibility is to have AND/OR as Observation Operators (like FOLLOWEDBY) but I think that’s also confusing because we’ll have the “same”
operators cast as different things – Observation Operators (between Observation Expressions) and Boolean Operators (between Comparison Expressions). > If we decide to go with AND, I much prefer ANDTHEN – notice one word. I’m personally OK with ANDTHEN – I agree that it seems like a reasonable companion to AND :) Regards, Ivan From: Rich Piazza <rpiazza@mitre.org> I think the new write-up makes an argument
for keeping `ALONGWITH` and `OTHERWISE`. You now have two tables which describe `AND/OR`, which is confusing. But you need two because the comparison Boolean ops are different than the observation Boolean ops, in that the former must apply to
the same observation and the latter different observations. The operators have (slightly) different semantics, and using different name makes that clear. I also don’t like the fact that we still have the FOLLOWEDBY operator – which is really an “AND w/order” operator. If we decide to go with AND, I much prefer ANDTHEN – notice one word
J.
Rich From: <cti@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org> Hi All, On today’s call we discussed the addition of a new OTHERWISE operator that functions effectively as an OR between discrete Observation Expressions. During the call, many posed the question of why we call the
AND/OR operators for Observations Expressions ALONGWITH/OTHERWISE, instead of, well, just AND and OR. Our rationale during writing the spec was that it would be easier to explain combinatorial patterns across multiple Observations using different terminology,
but in hindsight this may well cause more confusion than anything, which seemed to be the consensus on today’s call. Anyhow, I’ve gone and updated the STIX Patterning specification to use AND and OR for both Observation Expressions and Comparison Expressions. It still made sense to leave Observation Operators as a separate
class (for FOLLOWEDBY) but to use the Boolean Operators for the aforementioned entities. If anyone has a chance to review the specification and subsequently these new changes, that would be great:
https://docs.google.com/document/d/1suvd7z7YjNKWOwgko-vJ84jfGuxSYZjOQlw5leCswPY/edit#heading=h.4do73o99e2l7 Regards, Ivan |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]