You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the expression-evaluator, the TermTransformer allows transforming literals to the EE internal types. Sometimes corners are cut and the value of the parsed literals are not thoroughly checked. For example, when parsing decimals, we don't check if the provided number actually fits the bound of the literal type.
For example, parsing "{a very big number}"^^short will just work, even though the number does not fit the bounds.
We should also think about how to handle these kinds of invalid values. Are they Non-lexical (I think so)? Or do we throw a warning? Or do nothing to avoid (minimal) overhead?
This is originally mentioned in an issue of the sparqlee repo: comunica/sparqlee#45.
The text was updated successfully, but these errors were encountered:
In the expression-evaluator, the
TermTransformer
allows transforming literals to the EE internal types. Sometimes corners are cut and the value of the parsed literals are not thoroughly checked. For example, when parsing decimals, we don't check if the provided number actually fits the bound of the literal type.For example, parsing
"{a very big number}"^^short
will just work, even though the number does not fit the bounds.We should also think about how to handle these kinds of invalid values. Are they Non-lexical (I think so)? Or do we throw a warning? Or do nothing to avoid (minimal) overhead?
This is originally mentioned in an issue of the sparqlee repo: comunica/sparqlee#45.
The text was updated successfully, but these errors were encountered: