http://docs.tokenscript.org/Filter.html only examplified the most common filters, such as
A filter is used for finding tokens or data objects (such as events, attestations and secrets).
We never formally discussed this issue on what the syntax will be. My default, thoughtless thinking used to be "Just follow RFC2254", (RFC2254: The String Representation of LDAP Search Filters). The reason being that before blockchain was invented, the attestations/token were mostly stored in a directory service such as X.500 which later became LDAP and all technologies passed on to there. (Our concept of Operational Attribute is also borrowed from there.)
RFC2254 look like this:
||All tokens' locality being
||All Tokens that have locality attribute|
||All tokens that has locality start with S|
||Born in 2020-02-02|
||If attribute 'price' is less than 20832|
||(AirBnB token) located in Sydney and price is less than 20832|
||located in either Sydney or Paramatta|
But thre are shortcomings of RFC2254.
First, Polish notion being easy to parse by Smart Contracts is probably irrevlant to the users in terms of the parsing gas it can save? Bitcoin used some reverse-polish notation that is not adopted by any later blockchain I guess. RFC 2254 documented what was created in the age where
(&(locality=Sydney)(price<=20832)) wasn't considered outrages, but today's programmer were mostly born after 90s.
If we wish to encode expressions in Polish or reverse-polish notion for smart contract's parsing, then it seems to be suitable to do it inside cheque/attestation code - that is, the TokenScript file uses SQL-like expression such as
locality == Sydney && price <= 20832 and it's translated to polish notion when encoding cheque.
Second, that there are unreasonable restrictiosn such as missing
<. You can do
!(price>=20832), but you can't do
price<20832. Such restriction is already removed in αW Android/iOS.
Since we are free to invent for the ease of use of our technology, let's say RFC2254 is irrelevant, what would you do?
- Should it be more SQL like? (so
locality CONTAINS Sydneyinstead of
- Or maybe Polish notion actually is not a burden for developers and also helps the developers to not assume it the same as JS or SQL?
A cunning developer might consider deligating the filtering into a function but I think there are advantages to be language agnostic and stay in the literal level instead of implementation level, similiar to how Google treated the search expression.