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.