<?xml version="1.0" encoding="UTF-8"?>
<response xmlns="http://rs.tdwg.org/tapir/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://rs.tdwg.org/tapir/1.0    http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd">
    <header>
        <source accesspoint="http://accesspoint_url" sendtime="2005-11-11T12:23:56.023+01:00">
            <software name="TAPIR_Implementation" version="1.0"/>
        </source>
    </header>
    <capabilities>
        <operations>
            <ping/>
            <metadata/>
            <capabilities/>
            <view>
                <queryTemplates>
                    <queryTemplate location="http://url_to_searchtemplateA"/>
                    <queryTemplate location="http://url_to_searchtemplateB"/>
                    <queryTemplate location="http://url_to_inventorytemplate"/>
                </queryTemplates>
            </view>
            <inventory/>
            <search>
                <staticOutputModels>
                    <outputModel location="http://url_to_raw_outputmodelA"/>
                    <outputModel location="http://url_to_raw_outputmodelB"/>
                </staticOutputModels>
            </search>
        </operations>
        <filter>
            <encoding>
                <expression>
                    <concept/>
                    <literal_/>
                    <parameter/>
                    <variable/>
                    <arithmetic>
                        <add/>
                        <sub/>
                    </arithmetic>
                </expression>
                <booleanOperators>
                    <logical>
                        <not/>
                        <and/>
                        <or/>
                    </logical>
                    <comparative>
                        <equals/>
                        <greaterThan/>
                        <greaterThanOrEquals/>
                        <lessThan/>
                        <lessThanOrEquals/>
                        <in/>
                        <isNull/>
                        <like/>
                    </comparative>
                </booleanOperators>
            </encoding>
        </filter>
        <concepts>
            <conceptNameServers>
                <server location="http://url_to_primary_concept_server"/>
                <server location="http://url_to_secondary_concept_server"/>
            </conceptNameServers>
            <schema namespace="http://www.tdwg.org/schemas/abcd/1.2"
                location="http://www.bgbm.org/TDWG/CODATA/Schema/ABCD-1.20.xsd">
                <mappedConcept
                    id="/DataSets/DataSet/DatasetDerivations/DatasetDerivation/DateSupplied"
                    searchable="true"/>
                <mappedConcept
                    id="/DataSets/DataSet/DatasetDerivations/DatasetDerivation/Description"
                    searchable="true"/>
            </schema>
            <schema namespace="http://digir.net/schema/conceptual/darwin/extension/curatorial/1.0"
                location="http://digir.net/schema/conceptual/darwin/extension/curatorial/1.0/curatorialWithDiGIRv1.3.xsd">
                <mappedConcept id="/CatalogNumberNumeric" searchable="true" mandatory="true"/>
                <mappedConcept id="/IdentifiedBy" searchable="true"/>
            </schema>
        </concepts>

        <variables>
            <environment>
                <timestamp/>
                <lastUpdate/>
                <date/>
                <datasourceName/>
                <accessPoint/>
            </environment>
        </variables>
        
        <settings>
            <minQueryTermLength>2</minQueryTermLength>
            <maxElementRepetitions>10</maxElementRepetitions>
            <maxElementLevels>20</maxElementLevels>
            <maxResponseTags>500</maxResponseTags>
            <maxResponseSize>500</maxResponseSize>
        </settings>
        
    </capabilities>
</response>

But when the specification was being prepared and PyWrapper being updated, it has been recognized that the "view" operation and the understanding of templates and output models was confusing. So to help making the protocol clearer and more symmetric, a new capabilities proposal was made, mainly removing the view operation and allowing the different levels of provider implementation to be expressed through other capabilities elements. So a new capabilities response would now look like:

<?xml version="1.0" encoding="UTF-8"?>
<response xmlns="http://rs.tdwg.org/tapir/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://rs.tdwg.org/tapir/1.0    http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd">
    <header>
        <source accesspoint="http://accesspoint_url" sendtime="2005-11-11T12:23:56.023+01:00">
            <software name="TAPIR_Implementation" version="1.0"/>
        </source>
    </header>
    <capabilities>

      <operations>
        <ping/>
        <capabilities/>
        <metadata/>
        <inventory> (optional)
            <templates> (optional)
              ...
            </templates>
            <anyConcepts/> (optional)
        </inventory>
        <search> (optional)
            <templates> (optional)
              ...
            </templates>

            <outputModels> (optional)
              <knownOutputModels> (optional)
                ...
              </knownOutputModels>
              <anyOutputModels> (optional)
                <responseStructure>
                 ...xml schema options...
                </responseStructure>
              </anyOutputModels>
            </outputModels>
        <search/>
      </operations>

      <requests>
        <encoding>
           <kvp/> (= URL key-value pairs)
           <xml/> (optional)
        </encoding>
        <globalParameters>
           <logOnly>accepted</logOnly>
           <xslt/> (optional)
        </globalParameters>
        <filter>
            ....
        </filter>
      </requests>

      <concepts>
        ....
      </concepts>

      <variables>
        ....
      </variables>

      <settings>
        ....
      </settings>

      <custom/>
   </capabilities>
</response>

Additional constraints that go beyond the protocol schema

Inventory operation

If a provider supports the inventory operation, it must advertise either one or more inventory templates, or the capability. But this is still not a choice, because it can actually advertise both things (even supporting a provider may wish to point to useful inventory templates). So the only situation not accepted is to advertise inventory with an empty element.

Additionally, if a provider supports , it must understand filters.

Search operation

If a provider supports the search operation, it must advertise either one or more search templates, or the capability. But this is still not a choice, because it can actually advertise both things (even supporting a provider may wish to point to useful search templates). So the only situation not accepted is to advertise search with an empty