Feature: Execution Comments And Warnings
A result set, whether of select, ask or construct, should be able to carry metadata pertaining to the execution of the query.
In many cases, single result set is not enough:
- Returning a partial result set if the query is interrupted for any reason, such as run time error, timeout or such.
- Returning warnings, as may pertain to the query, for example presence of filter conditions that are identically false, use of deprecated features etc.
- Returning resource utilization information.
- Returning debugging information.
So the protocol should provide a way of returning that data (and before that, indication that the client needs that data with some level of verbosity).
Possible alternatives are
- Special lines in response header (prevents the server from using chunked encoding).
- Special elements in the returned result set (depends on serialization format, does not work for CONSTRUCT/DESCRIBE)
- Comments of special sort (depends on serialization format)
No one solution is perfect but we need something.
The spec should describe data encapsulation method and it would be nice to specify the top-level structure of the data transferred, to let clients recognize types of messages, positions of errors and warnings in soruce texts of queries etc. in an interoperable way.
e.g. sample Query highlighting necessary syntax extensions, expected output, or modified/extended result format, endpoint self description mock-up syntax, etc.
Virtuoso supports partial results. When a client indicates its support of the feature in the request by providing partial result timeout value, Virtuoso may return result rows calculated within the timeout interval, ignoring data that may remain in the database but not yet retrieved. When this feature is in use, Virtuoso places custom header lines in order to indicate that the result is partial and to provide statistics re. execution time, network activity etc.
Existing Specification / Documentation
List any existing text that attempts a formal definition of this extension. This could be a draft specification, API or syntax documentation, etc.
Unfortunately, there are no compatibility issues because the feature is totally missing Extensions should be upwards compatible with the previous SPARQL spec. Although the charter does not formally bind us to this requirement, it rule should only be violated in exceptional cases. In case your extension possibly raises any compatibility issues, these should be detailed here.
Links to postponed Issues
List and possibly link to other use cases or extensions that relate to that use case. That will help us grouping them together in the end.
- Ivan Mikhailov / OpenLink
The feature is of general purpose.