So far the data protocols describe data the tools are going to consume. Considering growing complexity of metadata (if not yet, then soon) and the nature of distributed ecosystem of generic tools it is not trivial task to achieve 100% compliance of tools with standards (such as these data protocols).
This issue is relevant mostly for tools being used by other tools, for example computational backends with some visualization front-ends or processing backends with analytical front-ends. It is less of an issue for tools that intended to be used by users directly.
It should be recommended to the tool developers of reusable tools to advertise capabilities of the tools, so the application using them can act accordingly. The app can either refuse user's request due to not-supported feature at the backend side or might use some workaround, for example using less efficient, but working alternative or some other kind of post-processing.
Example:
In Cubes we are supporting multiple aggregation backends: SQL, Google Analytics, Mixpanel, MongoDB ... and more are coming. The reporting applications built on top of Cubes provide certain reporting capabilities: charts, drill-downs, filtering, exports... However, not all backends provide all capabilities. For example, Google Analytics does not provide detailed data, therefore the front-end can't ask for /facts because it will receive an error.
It is much more convenient for users to have certain features disabled up in front, instead of allowing them to perform an action that is known to fail. For this purpose we have introduced per-cube features metadata: front-end visualizer apps can ask "what can I do with this cube?" and the response would be: "anything" for SQL backend or "just aggregate, nothing else, forget about CSV export of detailed data" for the Google Analytics.
There is much more that can be done in tools features metadata in the future.
Copied from original issue: frictionlessdata/specs#98
From @Stiivi on February 4, 2014 16:40
So far the data protocols describe data the tools are going to consume. Considering growing complexity of metadata (if not yet, then soon) and the nature of distributed ecosystem of generic tools it is not trivial task to achieve 100% compliance of tools with standards (such as these data protocols).
This issue is relevant mostly for tools being used by other tools, for example computational backends with some visualization front-ends or processing backends with analytical front-ends. It is less of an issue for tools that intended to be used by users directly.
It should be recommended to the tool developers of reusable tools to advertise capabilities of the tools, so the application using them can act accordingly. The app can either refuse user's request due to not-supported feature at the backend side or might use some workaround, for example using less efficient, but working alternative or some other kind of post-processing.
Example:
In Cubes we are supporting multiple aggregation backends: SQL, Google Analytics, Mixpanel, MongoDB ... and more are coming. The reporting applications built on top of Cubes provide certain reporting capabilities: charts, drill-downs, filtering, exports... However, not all backends provide all capabilities. For example, Google Analytics does not provide detailed data, therefore the front-end can't ask for
/factsbecause it will receive an error.It is much more convenient for users to have certain features disabled up in front, instead of allowing them to perform an action that is known to fail. For this purpose we have introduced per-cube
featuresmetadata: front-end visualizer apps can ask "what can I do with this cube?" and the response would be: "anything" for SQL backend or "just aggregate, nothing else, forget about CSV export of detailed data" for the Google Analytics.There is much more that can be done in tools features metadata in the future.
Copied from original issue: frictionlessdata/specs#98