Groups - AMQP Filter Expressions - comments against WD3

[Keith Wall <kwall@redhat.com>]

Hi Clemens,

My feedback against your last working draft 3.   Thanks for the work,
I think it is taking shape.
Kind regards, Keith


Comments against Working Draft 3 - 10 September 2018.

Footer refers to the wrong document version (WD1)

2.1 Overview, para 3.  "and [the] might carry encrypted data."

4.1 I don't see how the reference field values scheme works for
headers and properties sections. The problem is their list nature
coupled with the fact they carry fields that are not nullable
according to their type.   For instance I want a filter on priority=2
alone, but I cannot express this without also specifying durable value
boolean which appears before it in the list.

4.2.1 What is the behaviour of filter that is an empty list?  Say I
define a filter delivery-annotations-filter and leave the map empty.
Would it match a message without a delivery-annotations section?  My
expectation is yes, but I think this needs to be clear.

4.3 The body of a message allows one or more amqp-sequence values.  In
the case where the message being filtered carries more than one
amqp-sequence values, it is not clear to me how the
amqp-sequence-filter works.

Are the amqp-sequence-filter applied positionally against the filtered
messages? Or does every amqp-sequence-filter defined in the group have
to match every amqp-sequence on the message being considered.  Both
ideas seem weird to me.  It makes me wonder if amqp-sequence filtering
is actually useful.

6  How must an implementation handle a sql-filter that cannot be
parsed? (immediately detach the link? use particular link error?).

Does the specification need to talk about runtime filter evaluation
errors? I For instance given a filter DATE(a.date) > NOW()  how should
an implementation behave on encountering a message where the value of
a.date it not parsable as a date because it is the wrong format or not
of the expected type.    2.1 already states "Filter expressions MUST
evaluate to a Boolean âtrueâ or âfalseâ result. ", so I think this
already provides the answer.  An implementation could choose to log a
warning etc to help developer, but I think this need not concern the
spec.

There is another corner case about about filters that whilst
syntactically valid refer to fields (of header or properties) that
don't exist. I don't think the spec needs to talk about this.  An
implementation could chose to detect/log/ it if so wished.

6.2 EBNF was standardised by ISO-14977.   Is this the standard the
EBNF in the spec means to comply with?

I'd prefer the EBNF in a single block rather than interspersed amongst
the text.  If makes it easy to feed into tools as a single copy/paste
(parser generators, EBNF validators) and for me at least better allows
the spotting of errors.

6.2.2.3 Second bullet, missing exclamation.  The â[!]=â operator
evaluates to âtrueâ if the left and the right operand expressions are
not of equal value.

6.2.3.2 Typo.  There is no[t] default escape character.

6.2.3.1  Clarify the behaviour of NULL when fields or sections are
missing from the message.  For instance "a.color IS NULL" when either
application properties exists but does not carry a color entry in the
map, or application properties is absent from the message being
filtered.  I would expect the filter to yield TRUE for both.   I
notice the JMS 2.0 spec uses words "3.8.1.1  If a property that does
not exist in a message is referenced, its value is NULL.". I think we
need something similar.

6.2.4.1.2 Define arithmetic promotion and define how overflow is to be
handled.

6.2.4.3 syntax rule "function_name" defines UTC, but the later
sections do not define this function. Conversely NOW is defined in the
later sections but missed in the syntax rule.

6.2.4.4  As my comment against 4.3, the body of a message allows one
or more amqp-sequence values, so the meaning of a section reference.

6.2.4.4 Section 2.1 excluded the data payload section but the syntax
rule "section" allows it to be referenced.