[tdwg-tapir] Suggested changes

Renato De Giovanni renato at cria.org.br
Wed Jan 17 13:06:54 CET 2007

Dear all,

I recently finished a new TAPIR provider implementaiton and I've been
taking notes about some issues with the protocol schema and the
specification. Most are minor things that are now unspecified or that have
some contradiction considering schema, specification and wiki notes. Some
are really errors that need to be fixed and others are suggestions to
improve the way that some things are defined now.

I'm listing all issues below suggesting an approach for each one. Most of
them I already talked to Markus and we have a similar opinion. Please feel
free to give your ideas or suggest different approaches. In case there are
no objections, I should probably change the XML Schema and the
specification by the end of this week.

Best Regards,


Issues and proposed changes to TAPIR

1) Now the schema says that indexingElement is unbounded. However, there
must be one and only one indexingElement for each output model. This is an
error and must be fixed in the schema.

2) Some time ago there was a proposal to allow renaming <value> elements
in inventory responses to ease the parsing
Apparently there was an agreement about this, but for some reason the
schema was never changed. Suggested approach: change schema and
specification accordingly. (inventory requests: concept elements will have
an optional attribute "tagName", and inventory responses will need to have
xsd:any inside <record>).

3) Currently the "basicSchemaLanguage" capability for response structures
includes "...ComplexType, simpleType, complexContent and simpleContent
only when related to local definitions". On the other hand,
"xsd:extension" and "xsd:restriction" are optional capabilities. Since
complexContent and simpleContent have to be used with either
"xsd:extension" or "xsd:restriction", this becomes a contradiction.
Suggested approach: remove complexContent and simpleContent from
basicSchemaLanguage, also trying to keep it as "basic" as possible.

4) header/source at accesspoint is a mandatory attribute that can be either
an IP or a name. For TAPIR responses this is fine, when @accesspoint
should be the service accesspoint. But for requests it becomes incovenient
to force clients to put an accesspoint there (which can potentially
contradict with the REMOTE_ADDR environment variable). Suggested approach:
make @accesspoint an optional attribute and change the specification
saying that: @accesspoint must be present in all responses indicating the
service accesspoint. On requests, @accesspoint must be present in all
<source> elements except the last <source>. In these cases, when present
it must contain the IP address. The IP of the last source must always be
taken from REMOTE_ADDR.

5) There's no way to track the original source using KVP when there are
intermediate services. Suggested approach: include an optional KVP
parameter "source_ip" (same DiGIR approach).

6) Currently, local variables are defined with their own elements, like
<dateLastUpdated/>. This makes it complicated for a service to define new
variables (need to extend the schema!) and also to identify variables when
parsing a request. Suggested approach: use the same strategy adopted by
parameters: <variable name="var_name"/> with the difference that @name
will be an extensible controlled vocabulary.

7) <mappedConcept> in capablities responses has an optional @alias.
Suggestion: add an optional @alias attribute to <schema> as well.

8) There's no indication whether response structures must contain a
targetNamespace or not. If there's no targetNamespace and the response
includes the TAPIR envelope, then custom search elements will be forced to
inherit from the TAPIR namespace. Suggested approach: change the specification
to say that response structures (schema) should always indicate a

9) The specification says that the default value for "start" (search and
inventory operations) is "1", but schema says the default is "0".
Suggested approach: use "0" (= index of the first record) and change the

10) The specification says that the default value for "limit" (search and
inventory operations) is "null" (unlimited), but schema says the default
is "1". Suggested approach: when not specified ("null") consider
unlimited. Change the schema to remove "default=1". Otherwise it would be
necessary to define a specific value to indicate "unlimited".

11) Currently, case sensitivity can be separately specified for "equals"
and "like" operators, while nothing is said about the "in" operator.
Suggested approach: have a single setting for case sensitivity related to
the three operators.

12) There's no default behaviour for "like" comparisons when there's no
wildcard in the term. Suggested approach: include * both in the beginning
and the end of the term.

13) There's nothing specificed about how to escape * in like terms.
Suggestion: use _* to escape (avoiding reserved and unsafe URL

14) Specification is not clear about what content should be included in
reponses when one or more partial parameter is specified. Suggested
approach: response content should be minimal (non-greedy) when partial is
specified. This means "include only the partial nodes and all other nodes
(below and above) that are mandatory". When partial is not specified then
reponses should be greedy (include all possible content).


More information about the tdwg-tag mailing list