fnml:ReturnMap

[samiscoding]

I noticed that in defining the fnml:ReturnMap and fnml:Input we're following a double standard. We're defining the fnml:Input based on both abstract definition in FnO (i.e., parameter) and the practical level (i.e., the reference to the value in the real data source), while, in the case of fnml:ReturnMap we only define based on the abstract level (i.e., we're not allowing the definition of the return value in the real data source). Maybe I'm missing something, otherwise, I think we need to modify the definition of fnml:ReturnMap. Lert me know if you want me to pull request with the modification :)

[bjdmeest]

Hmmm, I don't think I fully understand, because I don't understand why you would want to define the return value in the real data source. If you can define the return value in the real data source, you don't need a function anymore, or what am I missing? Maybe a pull request makes sense to understand the full context?

[samiscoding]

Allowing users to define the name of the output (a field in any type of data source) could increase the reusability of the output without calling the function repeatedly, but I see your points that since the output is connected to the execution, this may not be useful. Unless we can use it when it comes to applying Fields. I guess we can open this issue later once we proceed with Fields if necessary :)