The adlibweb.xml file

• disabled: no record caching will take place so each time a record is requested it’s retrieved (up-to-date) from the SQL database.
• readonly (default): the first time a record is requested it’s retrieved from the SQL database and put in the record cache so that subsequent requests will use the cached version (even if the record was changed in the SQL database after being cached).
• readwrite: the first time a record is requested it’s retrieved from the SQL database and put in the record cache, but subsequent requests will check if the record was updated in the SQL database and update the cached version accordingly.

So the Axiell WebAPI can return different forms of XML, but most XML output has some characteristics in common:

• The root element is named adlibXML.
• All records are contained in a child element from the root with the name recordList.
• Each record in the result set is contained in the record list in a record element.
• The recordList element is followed by a diagnostics element, which contains meta information about the search, such as the elapsed time and the number of records that were found.
• The fields in the records are contained within each record element and have the English field name by which they are declared in the database .inf file

The most common Axiell XML (aka Adlib XML) output types are unstructured and grouped:

• unstructured = flat structure: all fields and their occurrences are immediate children of the record element. If a field has multiple occurrences, then all those occurrences are listed directly below each other.
  Of a multilingual field, only the value of the currently searched data language is returned, and it is returned directly in the field node, without language or invariancy attributes.
  Of an enumerative field, only the neutral value is returned, directly in the enumerative field node, unless you specify the presentation language with the language parameter followed by a standard language code without square brackets around it, in which case only the relevant translation is returned, directly in the enumerative field node.
• grouped = hierarchical structure: fields may be a child of the record element, or when a field group name has been defined in the data dictionary, a child of a group element with the name of the group. In this case the group element is a child of the record element. If at least one of the fields in a field group has multiple occurrences, then the entire field group is repeated as many times. Empty occurrences of fields in a field group are retrieved as well.
  Of a multilingual field, all language values are returned as value subnodes of the field node; the language code and invariancy flag per language value are returned as attributes to the value nodes.
  Of an enumerative field, both the neutral value and all available translations of the enumerative value are returned, in value subnodes underneath the enumerative field node; the presentation languages are attributes to the value nodes, and are indicated by an Axiell language number, not by their language code. The presentation language parameter does not apply to the grouped XML output type.
  The grouped XML format is also variable in some ways, especially for linked fields, dependent on the brieffields and detailfields listings here in adlibweb.xml. This is because from wwwopac.ashx version 3.6.327.0 it is possible to nest field nodes of linked fields in said listings, to retrieve data of your choice from linked records. This way you can even obtain data from records linked in the second or third degree. See the relevant topic for more information. Also note that the grouped XML as produced by adlwin.exe (running an Adlib for Windows application) always contains the nested linked field structure (although it doesn't retrieve any extra fields from linked records and does have some added linked field node attributes as well), whilst the grouped XML from the default adlibweb.xml doesn't contain the nested linked field structure; this means that XSLT stylesheets may not be readily exchangeable between adlwin.exe and wwwopac.ashx.

The structured xmltype, as could be used with wwwopac.exe, has not been implemented for searches in wwwopac.ashx, although it has been for pointer files. If you do use it with a search statement, the result will be unstructured XML, regardless of what the diagnostics may indicate. An overview of differences between the wwwopac.exe structured xmltype and the wwwopac.ashx grouped xmltype is documented here.

Set this optional variable (available from WebAPI version 3.7.13308) to true to allow the XSLT document() function and embedded scripting to be used in your XSLT stylesheet to transform the XML returned from wwwopac.ashx. (In MSXML 6.0 this feature is disabled by default.)
The XSLT document() function provides a way to retrieve other XML resources from within the XSLT stylesheet beyond the initial data provided by the input stream. Allow scripting only if you require script support in the stylesheet and if you are working in a fully trusted environment: if scripts are allowed in the main stylesheet, they will be allowed in all the included files too.

Configuration options

Possible values

Meaning

Set this variable to True to specify that when you write or update a record with the WebAPI, the adapl set as Storage procedure for the relevant database in Axiell Designer must be executed just before actual storage, just like it is executed before storage when you save a record in an adlwin.exe application. This variable is available from wwwopac.ashx version 3.6.1265.0. By default, for backwards compatibility with existing Axiell Internet Server applications, the storage procedure is not executed.
This variable can also be set in the groupConfiguration section (the shared section for multiple database configurations) and in the globalConfiguration section (the shared section for all database configurations).
A further requirement is that all fields to which the storage adapl should be able to write, have actually been defined in the data dictionary (the .inf file of the relevant database), otherwise the WebAPI will report that it has no access rights for the field.
Although all adapl binaries can be read and most common ADAPL functions have been implemented, not all functions are present yet (March 2012). This means that it is possible that on execution of a storage adapl the WebAPI can throw an exception when it encounters a function which hasn't been implemented yet. The adapl will not have been executed properly in that case, which leaves you no option than to switch the adaplEnabled variable for the relevant database off again: please contact our helpdesk if you have this problem. The goal of course, is to implement all ADAPL functions in future releases.

With the <addToQuery> setting (available from wwwopac.ashx 3.7.13332.1) you can specify a partial search statement that must always be added to queries in the current database. This way you can shield certain content on field level, to prevent certain records from being retrieved. Note that a setting with the same name and function, that predates the adlibweb.xml setting, can also be made in the globalsettings.xml file of an Axiell Internet Server web application, but the adlibweb.xml setting does not only have the advantage of having the option available at the WebAPI level so that all software calling the WebAPI can be restricted with this setting, it may also allow you to use a q= search for simple searching multiple fields at once instead of a normal search= query, which can boost the performance of searching.
So, per <databaseConfiguration> here in the adlibweb.xml you can add the <addToQuery> setting and in it specify a partial search statement: this partial search statement will be combined with the search executed by the user, via an implicit Boolean AND. Do not enter any Boolean operators at the start of the partial search statement yourself. (Note that wwwopac.ashx versions until 2013-12-19 did require you to start your partial search statement with an explicit Boolean operator (AND, AND NOT, OR).) The added partial query can be different for each database and it applies to both search= and q= queries.
Note that a partial query for the <addToQuery> setting in the globalsettings.xml file for Internet Server also uses an implicit Boolean AND operator to combine the queries and that in the globalsettings.xml file, the setting is an optional one.

<brieffields>
<field>lead_word</field>
<field>title</field>
<field>author.name</field>
<field>corporate_author</field>
<field>year_of_publication</field>
<field>digital_reference</field>
<field>copy.number</field>
<field>shelf_mark</field>
</brieffields>

For optimal performance of wwwopac.ashx it is definitely recommended to provide only the brieffields which you intend to actually use. This is because each submitted field will take up some processing time, and when you retrieve multiple records for a brief display, this will certainly add up.

From wwwopac.ashx version 3.6.327.0 it is possible to nest field nodes of linked fields, to retrieve data of your choice from linked records. This way you can even obtain data from records linked in the second or third degree. Using nesting field nodes does change the XML structure of linked fields in the required grouped XML format which wwwopac.ashx will produce. See the relevant topic for more information.

The wwwopac.exe type="richText" attribute for <field> nodes (no relation to RTF fields, by the way) is supported by wwwopac.ashx from version 3.6.13043.2. This attribute makes sure that any line breaks (\n) in field contents are replaced by HTML <br/> tags, so that the paragraph structure in field contents remains intact when presented on the website.

An optional attribute to the <field> element is includeIf. You can use this attribute to specify a condition (in the shape of a search statement) under which (an occurrence of) the relevant field must be included in the search result. Conditionally including fields in the search result this way has the advantage that specific data will never end up in the raw XML of a search result and that it doesn't need to be filtered out afterwards. An example of a single conditionally included field would be the following: <field includeIf="credit.type=Director">credit.name</field>
Click here for more information about this topic.

Use this variable to identify the actual name of the database. If a database has been subdivided into datasets, you may point to the dataset by stating it behind the database name, separated by an escaped greater-than symbol. Example: <database>document&gt;fullcatalogue</database>

Use this (optional) variable to filter all search queries submitted to wwwopac, by providing a filter query. Before execution of a search, the search statement or value submitted behind &search= will be passed on to any filter query set here. A filter query can be any value or normal search statement with the addition of the '{0}' parameter (include the quotes), to which the submitted search statement is passed on. Thus, if a <defaultQuery> has been specified, the submitted and the filter query will always be combined. So, a filter query like <defaultQuery>title = '{0}' or description = '{0}'</defaultQuery> will take any value passed on via the submitted search query and executes the resulting search. For example, the submitted query wwwopac.ashx?database=collect &search=amsterdam would result in the search statement title = 'amsterdam' or description = 'amsterdam' being executed.
Another example would be the filter query <defaultQuery>'{0}' and pointer 3</defaultQuery>. This would combine any submitted, normal search statement with and pointer 3. So wwwopac.ashx?database=collect&search=title=mill would result in title=mill and pointer 3 being executed.
If no search statement has been submitted, while a <defaultQuery> is present, then the filter query becomes the entire query (in which case the filter query should not contain the '{0}' parameter). So, a submitted query like wwwopac.ashx?database=collect (with no search statement), passed on to a filter query like <defaultQuery> all</defaultQuery> simply leads to the search statement all being executed in the collect database. If a filter query does not contain the '{0}' parameter, it will also always take precedence over whatever search statement you submit to wwwopac manually.
It may be obvious from the above that any <defaultQuery> (should you specify one), should accommodate most search statements passed on to it. If you can't be sure that the format of submitted queries is always what you want it to be, then reconsider the use of this option. However, wrong combinations resulting in incorrectly formatted search statements will simple produce an empty search result list: no errors will be reported.

<detailfields>
<field>lead_word</field>
<field>title</field>
<field>author.name</field>
<field>corporate_author</field>
<field>illustrator.name</field>
</detailfields>

<detailfields>
<field>*</field> 
</detailfields>

From wwwopac.ashx version 3.6.327.0 it is possible to nest field nodes of linked fields, to retrieve data of your choice from linked records. This way you can even obtain data from records linked in the second or third degree. Using nesting field nodes does change the XML structure of linked fields in the required grouped XML format which wwwopac.ashx will produce. See the relevant topic for more information.

The wwwopac.exe type="richText" attribute for <field> nodes (no relation to RTF fields, by the way) is supported by wwwopac.ashx from version 3.6.13043.2. This attribute makes sure that any line breaks (\n) in field contents are replaced by HTML <br/> tags, so that the paragraph structure in field contents remains intact when presented on the website.

An optional attribute to the <field> element is includeIf. You can use this attribute to specify a condition (in the shape of a search statement) under which (an occurrence of) the relevant field must be included in the search result. Conditionally including fields in the search result this way has the advantage that specific data will never end up in the raw XML of a search result and that it doesn't need to be filtered out afterwards. An example of a single conditionally included field would be the following: <field includeIf="credit.type=Director">credit.name</field>
Click here for more information about this topic.

<facetFields>
<field limit="25">creator</field>
<field limit="10">production.date.end</field>
</facetFields>

<searchFields>
<field>title</field>
<field>creator</field>
<field>object_category</field>
</searchFields>

Prior to wwwopac.ashx version 3.7.14202.1, q= searches were always implicitly truncated. Later versions offer an optional truncation="true|false" attribute for the searchFields node, allowing you to switch truncation on explicitly for all q= searches, whilst by default truncation is off (false). For example:

<searchFields truncation="true">
<field>title</field>
<field>creator</field>
<field>object_category</field>
</searchFields>

For optimal performance of wwwopac.ashx it is definitely recommended to provide only a limited number of search fields. This is because each field to search will take up some processing time, so searching many fields could lower performance.

It is also possible (from wwwopac.ashx version of October 2016) to specify multiple searchFields sections to allow for different q= searches. To distinquish between the different searchFields specifications you must add an id="<myid>" attribute in each of your searchFields elements (and replace <myid> by an appropriate name for the type of search). For example:

<searchFields id="descriptions">
<field>title</field>
<field>description</field>
</searchFields>
<searchFields id="objectnames">
<field>object_name</field>
<field>object_category</field>
</searchFields>

Configuration options

Possible values

Meaning

<folderMappingList>
<folderMapping>
 <lowerLimit>1</lowerLimit>
  <upperLimit>10000000</upperLimit>
  <folder>OurBranchImages-01\</folder>
 </folderMapping>
 <folderMapping>
  <lowerLimit>10000001</lowerLimit>
  <upperLimit>20000000</upperLimit>
  <folder>OurBranchImages-02\</folder>
 </folderMapping>
 <folderMapping>
  <lowerLimit>20000001</lowerLimit>
  <upperLimit>30000000</upperLimit>
  <folder>OurBranchImages-03\</folder>
 </folderMapping>
</folderMappingList>