22 lines
1.5 KiB
Plaintext
22 lines
1.5 KiB
Plaintext
%META:TOPICINFO{author="RenatoDeGiovanni" date="1170025019" format="1.1" version="1.28"}%
|
|
<!-- page was renamed from AdditionalSuggestedFeatures
|
|
-->
|
|
Wishlist/ideas to improve the TAPIR protocol:
|
|
|
|
* CAPABILITIES:
|
|
* Publish allowed operators in the capabilities of a concept. default will be all operators. E.g. integers in a db will not allow like operations.
|
|
|
|
* OUTPUT MODELS:
|
|
* Aggregator "functions" in output model definitions, that concatenate or sum up values if it is not a "RepNode".
|
|
* resultVariable view mappings: add a new abstract element for mapping directives of views which take values from the query result. This has the disadvantage that you need to know the result before it is sent back to the client. Thus you cannot stream the results directly, but need to cache data in memory, which is only suitable for limited result sets:
|
|
* matchedRecords: returning the number of matched records in a query.
|
|
* start: the paging start value taken from the request (see result summary).
|
|
* limit: the paging limit value taken from the request.
|
|
* next: the paging next value taken from the result summary.
|
|
* totalMatched: the total number of matched records in the database (see result summary).
|
|
* totalReturned: the total number of returned records (see result summary).
|
|
|
|
* FILTERS:
|
|
* SimpleFiltering (a.k.a. <if-defined> operator) This is something I thought of in connection with TapirLite. I put together another page to discuss it. (RogerHyam).
|
|
* Allow CustomOperators.
|