Skip to content

AASQL: Unnecessary mandatory whitespace #450

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mhrimaz opened this issue May 9, 2025 · 3 comments
Open

AASQL: Unnecessary mandatory whitespace #450

mhrimaz opened this issue May 9, 2025 · 3 comments

Comments

@mhrimaz
Copy link

mhrimaz commented May 9, 2025

What happens?

<matchExpression> ::= "$match" <ws> "("
<ws> ::= ( " " | "\t" | "\r" | "\n" )+

This mean $match ( is valid but $match( is not valid. in some other places it makes sense to have whitespace mandatory (however, I don't like it).

Either change the ws definition and always make it optional or introduce optional whitespace as well. something like

<matchExpression> ::= "$match" <optWs> "("

<optWs> ::= <ws> | E

<ws> ::= ( " " | "\t" | "\r" | "\n" )+
@mhrimaz mhrimaz added the bug Something isn't working label May 9, 2025
@sebbader-sap
Copy link
Contributor

The grammar is only a logical representation, nothing more. The actual endpoints use a more formal serialisation, e.g. JSON. Therefore, the mandatory whitespace does not appear at runtime at all, and therefore I don't regard it as a bug.
Please note that enforcing the whitespaces significantly increases the readability of the "BNF-encoded" query examples, which is a value by itself.

@sebbader-sap sebbader-sap removed the bug Something isn't working label May 15, 2025
@mhrimaz
Copy link
Author

mhrimaz commented May 15, 2025

The grammar is only a logical representation, nothing more.

I disagree with you. You can use the grammar to build a parser (Using ANTLR or LARK or ...), consume the compact syntax, build a parse tree, and then transform the parse tree to the target query language. JSON serialization here is too much verbose and the grammar is already good enough.

so instead of having this query

 {
  "$condition": {
    "$match": [
      {
        "$eq": [
          { "$field": "$aas#assetInformation.globalAssetId" },
          { "$strVal": "2487a22c-fe20-44c7-acb7-9300a89bd739" }
        ]
      }
    ]
  }
}

I prefer to support the compact query

$match(
    $aas#assetInformation.globalAssetId $eq "2487a22c-fe20-44c7-acb7-9300a89bd739"
)

use a parser to build the parse tree:

Image

and then process the parse tree to generate the query:

PREFIX aas: <https://admin-shell.io/aas/3/0/>
SELECT ?aas WHERE { 
    ?aas a aas:AssetAdministrationShell .
    ?aas <https://admin-shell.io/aas/3/0/AssetAdministrationShell/assetInformation> ?assetInformation .
    ?assetInformation <https://admin-shell.io/aas/3/0/AssetInformation/globalAssetId> "2487a22c-fe20-44c7-acb7-9300a89bd739".
}

Please note that enforcing the whitespaces significantly increases the readability of the "BNF-encoded" query examples, which is a value by itself.

Yes, having an optional whitespace is necessary. This would allow people to format their queries in a readable way. but having a mandatory whitespace is also not necessary :)

So here a mandatory whitespace makes this query invalid:

$match($aas#assetInformation.globalAssetId $eq "2487a22c-fe20-44c7-acb7-9300a89bd739")

@sebbader-sap
Copy link
Contributor

I prefer to support the compact query

You are of course free to implement an endpoint for it like that (you are not the only one for sure), however, just be aware that the AAS OpenAPI Query endpoint only describes the JSON serialisation of AAS Queries. Exposing a query endpoint with the "BNF-encoded" serialisation is not covered by the V3.1 specification anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants