Dear all,
During the TAPIR workshop in the last week we identified a few points in the protocol and specification that still deserved changes. As you could see from the notifications, I already updated the protocol schema. The specification was also replaced by a new version.
Here's the list of changes:
- Correction: "envelope" parameter on search operations should be turned on by default. - Included note about the possibility of restricting the allowable domains related to the location of stylesheets that are specified through the "xslt" parameter. When the stylesheet comes from an unknown location it can be ignored with a corresponding warning being raised in the diagnostics section. - Added specific XML Schema capability for xsd:include. - Included note about the fact that a provider is not forced to guarantee the entire validity of search responses according to the XML Schema defined in the response structure, except to the extent of its own declared XML Schema capabilities. - Included recommendation for providers to raise warnings instead of errors when an unsupported XML Schema construct is found in the response structure. - Included new search parameter called "omit-ns" instructing providers to omit or not namespace delarations and the corresponding prefixes in search responses when the envelope is turned off. - Included a new attribute "required" for both concepts and variables in the output model mapping (defaults to false). When required, providers should raise an error when the concept is unmapped, or the variable is not available or the corresponding value is null. - Node paths in output model mapping were not considering namespaces. When the response structure needs to make use of different namespaces, all namespaces need to be declared in the output model element and the nodes referenced in the xpaths must include the associated namespace prefix.
I also took the liberty to make this additional change since it can impact streaming (I forgot to mention it during the workshop):
- Removed requirement that providers must automatically turn on envelopes in search responses when an error occurs.
Please, let us all know if there are any further suggestions, objections or remaing issues.
TapirLink (and probably PyWrapper) still need to be updated in the next few days.
A more detailed report about the workshop will be prepared and soon made publicly available.
New developements related to TAPIR were started (including a concept name server, a harvester and a provider test suite). One thing that was proposed during the workshop was to use this mailing list also for development discussions about any tool related to TAPIR - we assumed that everybody in this list would be interested. For now I really think we need to concentrate this kind of discussions in a single place, but if the list becomes too busy we can easily change later.
Best Regards! -- Renato