Noticed on the examples and demos that oracle types are not the same as Sophia types:
contracts: int oracles: num
contracts: string oracles: str
Could this be normalized, for both cases?
If used in a contract (i.e. in Sophia) the types are Sophia types otherwise they are just strings. There is nothing named num or str that is probably something old and outdated?!
I mean the types used in the oracles query and response formats:
Like here:
https://github.com/aeternity/aepp-sdk-js/blob/11c82f7be1e9ca4ed54ff92f23b0bdf877a8b975/test/integration/oracle.js#L37
and here:
https://github.com/aeternity/aepp-sdk-python/blob/e20db0a98f18c8022fff06d1fe938b499ed2ecff/tests/test_oracle.py#L37
as you see they are not normalized against sophia types.
These are Oracles that aren’t handled in contracts as far as I can see. Then the query and response formats are just strings - so you can write whatever descriptive things you’d like. They have no semantic meaning.
Well, i got confused on those lines.
Since oracles are meant to be interoperable between parties, and contracts.
You don’t think it’s better to normalize types in the input and the output signatures?
Or that will limit the oracles capabilities?
If you look at the oracle register transaction it has a field abi_version this encode how the Oracle is intended to be used. 0 means an oracle that is to be consumed outside of contracts, here the query and response format is just a string it could say “the temperature in degrees celcius” (or “str” or “num” or “blafoo”) or something arbitrary, if abi instead is 1 (or 3) it is an oracle that is intended to be consumed by an AEVM (or FATE) contract respectively - in this case the contract that does register the oracle will contain the query and response type - and they will automatically be encoded properly. So, no, there is nothing that needs “normalizing”.