Hi can someone please explain the filter grammer for the path element.

The docs say

<path> := <name> ("->" <name>)*

but <name> is not defined.

The example

equip and siteRef->geoCity == "Chicago"

seems to suggest name should always be a ref as it needs to point to something for the geocity tag to be checked but that can't be right as geoCity is not a ref.

I am getting a little confused here.

If <name> is just <val> what does it mean if a value like <str> is specified on its own like equip is the example.

Thanks.

Hi Glenn,

So the latter part of the path definition is in parentheses with a star, so this means it's optional and that you can repeat it multiple times, the <name> can be just any tag.

You can define a fairly deep nesting for your path spec, so you can do equip, equipRef->hot, equipRef->siteRef->dis, or even longer if you wish.

Using only the selector will give you everything with that tag, but if you have a value tag, you can also check if it matches a given value, so you can get; point and dis == "somePoint", equipRef->dis == "someEquip", equipRef->siteRef->dis == "someSite", etc.

Thanks

In the example

equip and siteRef->geoCity == "Chicago"

What type is equip here ?

It doesn't match

<val> := <bool> | <ref> | <str> | <uri> | <number> | <date> | <time>

And the grammer for the filter languages says

Note that Marker, Bin, and DateTime scalars are not supported. So it can't be a Marker.

I am trying to create a parser for this language so am reusing the types from my zinc parser.

Hi Glenn,

Ik think it is useful to take a look at the relevant parts of the grammar to make sense of the sample:

equip and siteRef->geoCity == "Chicago"

This has the form:

<name> "and" <name>"->"<name> "==" <str>

You can find this by breaking down the filter query by the following steps:

equip and siteRef->geoCity == "Chicago"

<filter>     :=  <condOr>
<condOr>     :=  <condAnd> ("or" <condAnd>)*
<condAnd>    :=  <term> ("and" <term>)*

Gives: <term> "and" <term> Where the terms are equip and siteRef->geoCity == "Chicago"

equip can simply be deconstructed using the following rules

<term>       :=  <parens> | <has> | <missing> | <cmp>
<has>        :=  <path>
<path>       :=  <name>

siteRef->geoCity == "Chicago" can be deconstructed using

<term>       :=  <parens> | <has> | <missing> | <cmp>
<cmp>        :=  <path> <cmpOp> <val>
<cmpOp>      :=  "=" | "!=" | "<" | "<=" | ">" | ">="
<path>       :=  <name> ("->" <name>)*
<val>        :=  <bool> | <ref> | <str> | <uri> |
                 <number> | <date> | <time>

I think this is the best I can do for you, I hope this helps you on your way.

The <name> production should really be called <id> since its supposed to be reference the Zinc grammar:

<id>      :=  <alphaLo> (<alphaLo> | <alphaHi> | <digit> | '_')*
<alphaLo> := ('a' - 'z')
<alphaHi> := ('A' - 'Z')
<alpha>   := <alphaLo> | <alphaHi>
<digit>   := ('0' - '9')

Its essentially a variable/tag name identifier. In AST's there is usually a big difference between an identifier which is just a logical name versus a literal which is a literal data value. So it doesn't have a "type" per se.

If you are not aware there is a Java reference implementation you can look at on github. All of that project uses a common tokenizer for Filters, Zinc, and Trio called HaystackTokenizer

Thanks everyone. think I have it now. Funnily I came to the same conclusion about it being called id and ended using my id type from my zinc parsing code.

thanks for the help.