Review: Element Matching Syntax

[ax3l]

Hi @DavidSagan,

I took a look at the element matching syntax draft. Small initial ideas to improve it:

Index

The last paragraph mentions:

Lattice elements can also be referred to by the index in which they appear in a branch with the first element having index one, etc. Branches do not get an index since the PALS standard does not mandate that the branches of a lattice be stored in an array (it could, for example, be a linked list).

But does not list the syntax for this. Let's add it, similar to the other examples. Did you have Branch[N] or or Branch:N or similar in mind?

The zero- or one-based indexing we should probably vote on.

Limit the bounds of regex

There is a bit of ambiguity when regex start/stop. Did you intent to make >> (and/or #N) be separators that regex do not cross?

For example: In B1>>Qaf.*, where does the regex start? Right now, the parser must know that B1 is a literal branch name but Qaf.* is a regex. Is B1 also regex-matched? What about B.*>>Qaf.*?

Combining: Operator Precedence

Related to the above:

Example: Is B1>>Qaf.*#3 valid? If so, is it:

• "the 3rd match of Qaf.* within B1" or
• "the 3rd element named Qaf.* globally, but only if it's in B1"?

A possible way to solve both is to define a filter & token precedence or add regex delimiters explicitly.

Nesting

Nesting depth: Can one chain >> for deeper nesting? Ring>>Cell01>>Quad.*?

Escaping of Special Characters

How do we match an element literally named Sd#3 or A>>B? We'll need escaping rules for all special characters in PCRE2 and >> and # and : (#119) or explicitly disallow such names/characters in the PALS standard.

What to Filter on: Only Names?

Are element name the only thing people want to filter on? In APIs, I generally allow to filter by any attribute (start:stop element, position, kind, any other attribute).

#119 adds filtering by kind using the :: syntax.

Formal Syntax

In openPMD, some people use ABNF as specified by RFC 5234.
openPMD/openPMD-standard#264