Re: [amqp] AMQP filter expressions

[Keith Wall <kwall@redhat.com>]

Hi Clemens

Thanks for the first draft.  I think it is great start.
Here are my comments:

Kind regards, Keith.

Section 2
=======

1. We should be explicit that these filter expressions defined by this
specification apply to message format 0.
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#definition-MESSAGE-FORMAT

2. I think "message metadata element" is used to mean the fields of
sections such as header/properties and the key/values of the
annotation sections.  Perhaps we should define it so.

3. I don't understand the reason to disallow filtering by delivery
annotation.   Whllst I wouldn't expect an application to define a
filter in terms of delivery annotations, I can imagine utility within
a federated network.

4. We need to define the AMQP filter names/values for the "property
filter" and the "SQL filter".
http://www.amqp.org/specification/1.0/filters

5.  Para 1.  Typo: "will either evaluate[s] to" (spurious s)

6.. Para 2.  Typo: "elements contained [within] the header" (missing word)


Section 3
=======

1. Doesn't the fact that type header has fields with defaults (e.g.
durable/priority) present a problem to this scheme?   How would I
express a header reference expression section encapsulating "durable =
true" without the section also imposing an unwanted "priority = 4"
derived from priorities default?

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-header

2. With the string expressions, there needs to be an escape syntax
defined to allow string literals that happen to match $c: form.

3. Would different _encodings_ of the same value match?  For instance,
*int* the AMQP type system defines a smallint int encoding (1 byte)
and a 4 byte int form. What if the message's annotation value carried
one form and the reference expression the other?

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#type-int

4.Would types be widened to facilitate matching? For instance, what if
the message's annotation value carries an int and the corresponding
reference expression a long?  One *could* widen the message annotation
value from int to long and then make the comparison.  I think this
goes beyond the spirit of property filter expressions.

5. Para 6 says "restricted to simple types: complex types in the
message metadata".  The AMQP core type specification (Part 1) doesn't
define a complex type (or simple type) so I am not too sure what is
restricted.   I notice Part 3, in section 3.2.5 says "simple types
only, that is, excluding map, list, and array types.". Is this what is
meant?

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#toc
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-application-properties

6. Para 6 ."A reference expression is an entry in the map" is unclear.
I think it is referring to the map underlying the annotation sections,
but it also needs to refer to the fields values from the
header/property sections.


Section 4
=======

1. In section 1, we say "leans on SQL92".    I take this to mean that
whilst this specification borrows syntax from SQL92, the specification
will be completely independent.  That is, someone implementing this
specification will be able to do so without reference to SQL-92
standard.

2. In 4.1.2, <function> is superfluous.

3. Keys of message annotations are restricted to symbols or ulong.  If
a message carries two message annotations: 123 and "123"  it is not
clear which annotation would be retrieved by a property name "m.123"

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations

4. The fact that the scope of application-properties is implied means
there is an ambiguity: h.foo property could refer to headers.foo or
application-properties.foo

[I think at this point the heavy lifting from Service Bus docs begins :) ]

5. Section 4.2 says "property names are case-insensitive".
Annotation keys (symbols) and application property keys are case
sensitive.

6. Section 4.2. "SQL implicit conversion semantics".   We will need to
enumerate the rules.   How will we encode messageIds (UUID/binary/...)
in a filter string?

7. Section 4.2.1.  "non-existent system property must raise an error".
  For property references that reference the header or properties
sections, illegal fields could be detected at link attach.  References
to annotations cannot be validated until runtime (and note to self: as
a disposition can add a message annotation, a filter that failed
against a message once may succeed later).



On Fri, Jun 1, 2018 at 2:59 PM, Clemens Vasters <clemensv@microsoft.com> wrote:
> I didn’t manage to completely get the homework done on the filter
> expressions, but I did make a good amount of progress. It’s too early to
> upload it as a draft, but here’s a link to the doc that I’m working on:
> https://1drv.ms/w/s!AgcBsXoqzTwSrd0pF0LUORZikSgmiA
>
>
>
> The SQL expression syntax is lifted from the Service Bus product docs and I
> need to do some trimming.