607 lines
18 KiB
Plaintext
607 lines
18 KiB
Plaintext
head 1.28;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.28
|
|
date 2007.01.28.22.56.59; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next 1.27;
|
|
|
|
1.27
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.26;
|
|
|
|
1.26
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.25;
|
|
|
|
1.25
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.24;
|
|
|
|
1.24
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.23;
|
|
|
|
1.23
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.22;
|
|
|
|
1.22
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.21;
|
|
|
|
1.21
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.20;
|
|
|
|
1.20
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.19;
|
|
|
|
1.19
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.18;
|
|
|
|
1.18
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.17;
|
|
|
|
1.17
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.16;
|
|
|
|
1.16
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.15;
|
|
|
|
1.15
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.14;
|
|
|
|
1.14
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.13;
|
|
|
|
1.13
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.12;
|
|
|
|
1.12
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.11;
|
|
|
|
1.11
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.10;
|
|
|
|
1.10
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.9;
|
|
|
|
1.9
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.8;
|
|
|
|
1.8
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.7;
|
|
|
|
1.7
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.6;
|
|
|
|
1.6
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.5;
|
|
|
|
1.5
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.4;
|
|
|
|
1.4
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.3;
|
|
|
|
1.3
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.2;
|
|
|
|
1.2
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2007.01.09.00.00.00; author MoinMoin; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@Initial revision
|
|
@
|
|
|
|
|
|
1.28
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%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.
|
|
@
|
|
|
|
|
|
1.27
|
|
log
|
|
@Revision 27
|
|
@
|
|
text
|
|
@d1 21
|
|
a21 74
|
|
<!-- page was renamed from AdditionalSuggestedFeatures
|
|
-->
|
|
Ideas to improve the TAPIR protocol before its release as a TDWG standard.
|
|
Most of the ideas are incorporated into the [[http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd][latest schema]] already.
|
|
|
|
There is a general notion of having implementations of TapirLite. This implies a series of needed changes that are dealt with on the TapirLite page.
|
|
|
|
-----------------------------
|
|
|
|
---++ Included in the improved schema (s.above)
|
|
|
|
* Add a <processing> section to all request types. Better include it in the HEADER!
|
|
|
|
* Allow the inclusion of an optional XSLT URL in the response. This URL needs to be passed within the request or as GET parameters "applyStylesheet" AdditionalIdeas "includeStylesheet" in the view operation. As all request types could make use of it, it makes sense to include a new xml tag _stylesheet_ in the header. An additional flag should exist to tell the server to process the xslt - which needs to be exposed in the capabilities.
|
|
* The 'contentOnly' parameter of the view could be useful in all request types. Therefore it should be another header instruction.
|
|
|
|
<verbatim>
|
|
<header>
|
|
<applyStylesheet url="..." mimetype="text/xsl"/>
|
|
<includeStylesheet url="..." mimetype="text/xsl"/>
|
|
<silent>
|
|
</header>
|
|
</verbatim>
|
|
|
|
* Views
|
|
|
|
* Use the same view definition everywhere - inline in seaches, local views or external views for view requests
|
|
|
|
* Allow filters in views and seperately in searches. If two or more filters occur, they should be combined by a logical AND.
|
|
|
|
* Views used in the view operation should be identified by a URI instead of just a unique name. (important for TapirLite).
|
|
|
|
* Service environment variables: add new expressions for filters and view mappings that return strings but are taken from the datasource environment. All the environment expressions are optional for any implementation and should be part of the capabilities response if they are supported:
|
|
* <accessPoint>: returning the full URL of the accession point of the service
|
|
* <date>: return current ISO date
|
|
* <timestamp>: return current ISO timestamp
|
|
* <datasourceName>: return name of the datasource
|
|
|
|
* 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).
|
|
* include human doc string, title and summary/usage
|
|
---++ Further Ideas
|
|
|
|
* 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.
|
|
|
|
* log only request. A request flag indicating to log the request only and not return any data. Useful for portals working on cached data to forward the requests to the original provider for logging only.
|
|
|
|
* VIEWS:
|
|
* Aggregator "functions" in view definitions, that concatenate or sum up values if it is not a "RepNode".
|
|
* Views should not be contained in the capabilities document but only URLs and local names provided (see TapirLite)(RogerHyam).
|
|
* Views behind URIs are immutable.
|
|
* Seperate responseStructure bundle incl mapping & indexingElement from parameterizable filters, ordering? Normalize _views_.(Donald)
|
|
|
|
* INVENTORIES
|
|
* Allow parameterized GET based inventories similar to a view operation for searches.
|
|
|
|
* 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).
|
|
* make logical and basic operators mandatory for any implementation
|
|
* CustomOperators
|
|
* allow only "_local_" concepts, rather than filtering by any concept
|
|
|
|
* CAPABILITIES
|
|
* The supported operations should be defined in the capabilities response. Only Ping, Metadata and Capabilities should default to being supported all other operations should be opted into. This will mean that new operations could be added without having to change existing providers. (needed for TapirLite).
|
|
|
|
* METADATA
|
|
* add lat/long of provider, timezone
|
|
* preferred time, day, week range for _nice_ indexing. cron format?
|
|
* allow contacts to indicate if they are responsible/willing to address service technical issues and/or content issues.
|
|
* Compare with DublinCore elements.
|
|
@
|
|
|
|
|
|
1.26
|
|
log
|
|
@Revision 26
|
|
@
|
|
text
|
|
@d3 1
|
|
a3 1
|
|
The corresponding [[http://ww2.biocase.org/svn/tapir/branches/improved_schema_proposal/tapir.xsd][improved TAPIR schema]], based on the latest stable [[http://ww2.biocase.org/svn/tapir/branches/stable/schemas/tapir.xsd][PyWrapper TAPIR schema]], is also available.
|
|
@
|
|
|
|
|
|
1.25
|
|
log
|
|
@Revision 25
|
|
@
|
|
text
|
|
@d55 2
|
|
@
|
|
|
|
|
|
1.24
|
|
log
|
|
@Revision 24
|
|
@
|
|
text
|
|
@d71 2
|
|
@
|
|
|
|
|
|
1.23
|
|
log
|
|
@Revision 23
|
|
@
|
|
text
|
|
@d66 1
|
|
d68 3
|
|
a70 1
|
|
* The supported operations should be defined in the capabilities response. Only Ping, Metadata and Capabilities should default to being supported all other operations should be opted into. This will mean that new operations could be added without having to change existing providers. (needed for TapirLite).
|
|
@
|
|
|
|
|
|
1.22
|
|
log
|
|
@Revision 22
|
|
@
|
|
text
|
|
@d20 1
|
|
a20 1
|
|
<contentOnly>
|
|
@
|
|
|
|
|
|
1.21
|
|
log
|
|
@Revision 21
|
|
@
|
|
text
|
|
@d61 1
|
|
@
|
|
|
|
|
|
1.20
|
|
log
|
|
@Revision 20
|
|
@
|
|
text
|
|
@a53 2
|
|
* Support views based on inventory (DonaldHobern).
|
|
* Use URLs (not just URIs) for views to allow them to be retrieved dynamically from libraries of well-known views - this can encourage the re-use of useful views and the development of associated standard WSDL definitions, etc. (DonaldHobern) (important for TapirLite).
|
|
d56 3
|
|
a66 3
|
|
|
|
* INVENTORIES
|
|
* Allow parameterized inventories similar to a view operation for searches.
|
|
@
|
|
|
|
|
|
1.19
|
|
log
|
|
@Revision 19
|
|
@
|
|
text
|
|
@a52 2
|
|
|
|
* Include directives could be good to define views (at least when adding different filter sections to "basic" views).
|
|
@
|
|
|
|
|
|
1.18
|
|
log
|
|
@Revision 18
|
|
@
|
|
text
|
|
@a49 2
|
|
* Allow _dontRepeat_ configuration statements for local views as part of the view definition (instead of changing the structure schema). This could even be used with general URI based views. A local modification/addition to a URI based view could be saved locally.
|
|
|
|
@
|
|
|
|
|
|
1.17
|
|
log
|
|
@Revision 17
|
|
@
|
|
text
|
|
@d13 3
|
|
a15 1
|
|
* Allow the inclusion of an optional XSLT URL in the response. This URL needs to be passed within the request or as GET parameters "applyStylesheet" AdditionalIdeas "includeStylesheet" in the view operation. As all request types could make use of it, it makes sense to include a new xml tag _stylesheet_ in the header. An additional flag should exist to tell the server to process the xslt.
|
|
d20 1
|
|
a23 4
|
|
* It should also be possible to set the stylesheet parameter as an environmental variable (typically an http one). This would make it possible for TapirLite implementations to add dynamic-view-like functionality - and also do nice xhtml rendering of responses.
|
|
|
|
* The 'verbose' parameter of the view could be useful in all request types, although the default should always be True. Therefore it should be another processing instruction.
|
|
|
|
@
|
|
|
|
|
|
1.16
|
|
log
|
|
@Revision 16
|
|
@
|
|
text
|
|
@d13 1
|
|
a13 1
|
|
* Allow the inclusion of an optional XSLT URL in the response. This URL needs to be passed within the request or as a GET parameter "xsl" in the view operation. As all request types could make use of it, it makes sense to include a new xml tag _stylesheet_ in the header. An additional flag should exist to tell the server to process the xslt.
|
|
@
|
|
|
|
|
|
1.15
|
|
log
|
|
@Revision 15
|
|
@
|
|
text
|
|
@d14 6
|
|
a19 2
|
|
|
|
_<request> <header/> <processing> <stylesheet url="..." mimetype="text/xsl"/> </processing> <search/> </request>_
|
|
@
|
|
|
|
|
|
1.14
|
|
log
|
|
@Revision 14
|
|
@
|
|
text
|
|
@d11 1
|
|
a11 1
|
|
* Add a <processing> section to all request types.
|
|
d13 1
|
|
a13 1
|
|
* Allow the inclusion of an optional XSLT URL in the response. This URL needs to be passed within the request or as a GET parameter "xsl" in the view operation. As all request types could make use of it, it makes sense to include a new xml tag _stylesheet_ in a new general processing section:
|
|
@
|
|
|
|
|
|
1.13
|
|
log
|
|
@Revision 13
|
|
@
|
|
text
|
|
@d42 1
|
|
a42 1
|
|
|
|
a59 1
|
|
|
|
a60 1
|
|
|
|
d62 1
|
|
@
|
|
|
|
|
|
1.12
|
|
log
|
|
@Revision 12
|
|
@
|
|
text
|
|
@d68 3
|
|
@
|
|
|
|
|
|
1.11
|
|
log
|
|
@Revision 11
|
|
@
|
|
text
|
|
@d63 2
|
|
@
|
|
|
|
|
|
1.10
|
|
log
|
|
@Revision 10
|
|
@
|
|
text
|
|
@d7 8
|
|
a14 4
|
|
-----
|
|
---++ Included in improved schema (s.above)
|
|
* add a <processing> section to all request types.
|
|
* Allow the inclusion of an optional XSLT URL in the XML response doc. This URL needs to be passed within the request or as a GET parameter "xsl" in the view operation. As all request types could make use of it, it makes sense to include a new xml tag _stylesheet_ in a new general processing section:
|
|
d16 26
|
|
a41 18
|
|
* It should also be possible to set the stylesheet parameter in an environmental variable (typically an http one). This would make it possible for TapirLite implementations to add 'dynamic view' like functionality - also do nice xhtml rendering of responses.
|
|
* the 'verbose' parameter of the view could proof useful in all request types, although the default should always be True. Therefore it should be another processing instruction.
|
|
* views
|
|
* use the same view definition everywhere - inline in seaches, local views or external views for view requests
|
|
* Allow filters in views and seperately in searches. If two or more filters occur, they should be combined by an logical AND.
|
|
* views used in the view operation should be identified by a URI instead of just a unique name. (important for TapirLite)
|
|
* environment expressions: add new expressions for filters and view mappings that return strings but are taken from the datasource envirnoment. All the environment expressions are optionally for an implementation and are part of the capabilities if they are supported:
|
|
* <accessPoint>: returning the full URL of the accession point of the service
|
|
* <date>: return current ISO date
|
|
* <timestamp>: return current ISO timestamp
|
|
* <datasourceName>: return name of the datasource
|
|
* resultVariable view mappings: add a new abstract element for mapping directives of views which take values from the result of the query. This has the disadvantage that you need to know the result before its send back to the client. Thus you cannot stream the results directly, but need to cache the data in memory which is only suitable for limited result sets:
|
|
* <matchedRecords>: returning the number of matched records in a query
|
|
* <start>: the start value of the paging taken from the request (see result summary)
|
|
* <limit>: limit value of the paging taken from the request
|
|
* <next>: the next value of the paging 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)
|
|
d44 3
|
|
a46 1
|
|
* 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
|
|
d48 1
|
|
d50 1
|
|
d52 4
|
|
a55 3
|
|
* include directives would be good to define views (at least when adding different filter sections to "basic" views)
|
|
* Aggregator "functions" in view definitions, that concatenate or sum up values if its not a repnode.
|
|
* Support views based on inventory (DonaldHobern)
|
|
d57 2
|
|
a58 1
|
|
* Views should not be contained in the capabilities document but only URLs and local names provided (see TapirLite) (RogerHyam).
|
|
d60 3
|
|
a62 2
|
|
* 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).
|
|
d64 2
|
|
a65 1
|
|
* The supported operations should be defined in the capabilities response. Only Ping, Metadata and Capabilities should default to being supported all other operations should be opted into. This will mean that new operations could be added without having to change existing providers.(This is needed for TapirLite).
|
|
@
|
|
|
|
|
|
1.9
|
|
log
|
|
@Revision 9
|
|
@
|
|
text
|
|
@d12 1
|
|
a12 1
|
|
* It should also be possible to set the stylesheet parameter in an environmental variable (typically an http one). This would make it possible for TapirLite implementations to add 'dynamic view' like functionality - also do nice html rendering of responses.
|
|
@
|
|
|
|
|
|
1.8
|
|
log
|
|
@Revision 8
|
|
@
|
|
text
|
|
@d42 1
|
|
a42 1
|
|
* SimpleFiltering. This is something I thought of in connection with TapirLite. I put together another page to discuss it.
|
|
@
|
|
|
|
|
|
1.7
|
|
log
|
|
@Revision 7
|
|
@
|
|
text
|
|
@d44 2
|
|
@
|
|
|
|
|
|
1.6
|
|
log
|
|
@Revision 6
|
|
@
|
|
text
|
|
@d43 1
|
|
@
|
|
|
|
|
|
1.5
|
|
log
|
|
@Revision 5
|
|
@
|
|
text
|
|
@d42 1
|
|
a42 1
|
|
* SimpleFiltering. This is something I thought of in connection with TapirLite. I put together another page to discuss it.
|
|
@
|
|
|
|
|
|
1.4
|
|
log
|
|
@Revision 4
|
|
@
|
|
text
|
|
@d12 1
|
|
d17 1
|
|
a17 1
|
|
* views used in the view operation should be identified by a URI instead of just a unique name.
|
|
d39 4
|
|
a42 1
|
|
* Use URLs (not just URIs) for views to allow them to be retrieved dynamically from libraries of well-known views - this can encourage the re-use of useful views and the development of associated standard WSDL definitions, etc. (DonaldHobern)
|
|
@
|
|
|
|
|
|
1.3
|
|
log
|
|
@Revision 3
|
|
@
|
|
text
|
|
@d5 2
|
|
@
|
|
|
|
|
|
1.2
|
|
log
|
|
@Revision 2
|
|
@
|
|
text
|
|
@d35 2
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@Initial revision
|
|
@
|
|
text
|
|
@a5 8
|
|
---++ Included in implemented PyWrapper schema (s.above)
|
|
* new GET parameters accepted:
|
|
* _verbose_ parameter of the original view operation is used in all request types as an GET parameter to turn of the protocol envelope.
|
|
* _xsl_ Allow the inclusion of an optional XSLT URL in the XML response doc for all operations. This URL needs to be passed as a GET parameter "xsl" in the view operation.
|
|
|
|
* views
|
|
* allow optional ordering of indexing elements in views via qualified concepts
|
|
* remove <nodes> element in mapping section and just use the node element to contain a list of concepts etc
|
|
@
|