La configurazione degli archivi consiste di due grandi aree.

• Configurazione delle Unità Informative, dei vocabolari e dei canali di ricerca
• Configurazione dei profili generali dell'archivio

In ambo i casi va tenuto in considerazione che quando una componente della configurazione può accettare valori booleani i valori ammessi sono:

Perché un archivio esista è fondamentalmente necessario che venga istruito per riconoscere quelli che saranno i suoi record, altrimenti detti Unità Informative. Questa terminologia spiega, ancor meglio del termine inglese record che pure è riconosciuto a livello internazionale, l'intenzione che il Server eXtraWay si prefigge, ovvero di trattare in maniera unitaria degli insiemi di dati omogenei elevandone il ruolo a quello di informazione.

Il progetto eXtraWay prende le mosse da un'intenzione ambiziosa, quella di saper considerare come Unità Informativa qualsiasi insieme di elementi ed attributi riconoscibili, appunto, per mezzo di un elemento che li racchiude e che viene di seguito identificato come Primary Node Container o, per brevità, pne.
In questo modo si sarebbe potuto creare un archivio sulla base di Xml esistenti con poche attività di configurazione.
Parimenti l'intenzione originaria era anche di concepire e gestire archivi in cui diverse tipologie di Unità Informative potessero essere nidificate le une nelle altre, come rientra nella natura del formato Xml prescelto per la conservazione delle informazioni. Questo comporta i fatto che un'Unità Informativa può essere considerata Padre di una o più altre Unità Informative e così via, rendendo di fatto più complessa ed articolata l'attività di manutenzione delle stesse.

La realtà dei fatti, però, dimostra che la stragrande maggioranza dei casi rientra in una casistica più circoscritta e precisa, quella in cui un archivio nasce per sopperire ad una specifica esigenza e viene quindi modellato disegnando specifiche Unità Informative senza che esse siano nidificate tra loro bensì creando legami logici, relazionali o applicativi tra di esse, legami che si svincolino, di fatto, da una struttura Xml nidificata.
Ogni archivio avrà quindi uno o più diversi tipi di Unità Informativa e per ciascuna di esse dovrà definire i dettagli per mezzo dei quali essa verrà riconosciuta, gestita sul file system e condurrà all'alimentazione di vocabolari per mezzo dei quali compiere le attività di ricerca.
Nell'esemplificazione che segue si terrà conto di questo aspetto, ovvero delle caratteristiche degli archivi standard. Le varianti, per così identificarle, riferite agli archivi realizzati con Unità Informative non disegnate appositamente ²⁾ ovvero con Unità Informative nidificate verranno trattate di volta in volta come eccezioni.

L'identificazione di un unità informativa si attua introducendo nel file di configurazione un elemento primary_node per ciascuna unità informativa desiderata. Esso deve avere i seguenti attributi³⁾.

L'aspetto che un archivio potrebbe avere sarà il seguente:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE xway_cfg SYSTEM "http://www.3di.it/extraway/xway_20020215.dtd">
<xway_cfg>
 <primary_node ud_name="doc" ud_container="list_of_doc" globalkey="full" ud_xslt="proprietario.xsl">
   ...
 </primary_node>
</xway_cfg>

L'elemento primary_node è destinato a contenere una serie di impostazioni specifiche dell'Unità Informativa indicata ed in particolare delle chiavi che in essa devono essere riconosciute. Di queste ultime parleremo in seguito, per ora soffermiamoci sugli elementi unique_rule e file_location.

L'elemento unique_rule indica la ricerca, in linguaggio eXtraWay, il cui esito indicherà se il documento in esame violi o meno un univocità, ovvero contenga valori che possono essere presenti in uno ed un documento soltanto e tale documento sia già esistente. Ovviamente questa verifica viene compiuta dal server ad ogni salvataggio che viene compiuto e ne provoca il fallimento se l'univocità non viene rispettata.
L'elemento unique_rule contiene un singolo attributo, denominato search_rule che contiene, come detto, la sintassi di ricerca richiesta. Essa può prevedere operatori booleani (quali AND e OR) per poter esprimere una condizione complessa ed eventualmente correlata a più clausole alternative o complementari. Nella sintassi non si indicherà altro che il canale sul quale compiere la ricerca in quanto ad esso verrà automaticamente accoppiato il valore estratto dal documento con operatore di uguaglianza.
Il seguente può essere un esempio rappresentativo

  <unique_rule search_rule="[XML,/doc/@nrecord] or [XML,/doc/@num_prot] or [XML,/doc/extra/raccomandata/@numero]"/>

Analogo ragionamento va fatto per la regola di posizionamento delle Unità Informative nei files XML. Lo scopo, ovviamente, è quello di dare alle Unità Informative una collocazione fisica che ricalchi l'organizzazione logica attribuita all'archivio oppure ottenere una distribuzione che non comporti files troppo piccoli o troppo grandi.
La regola di distribuzione su file system si basa su regole fisse o su una una sintassi piuttosto complessa⁶⁾ che utilizza i contenuti del documento stesso.
Gli attributi dell'elemento file_location sono:

Queste impostazioni possono essere applicate tanto alla singola primary_node quanto all'intero archivio. Ciò comporta che, se per una data primary_node non viene indicata la regola di univocità o la regola di collocazione sul disco, il server tenta di applicare la regola generale. In tal caso gli elementi descritti verranno cercati direttamente come figli dell'elemento radice xway_cfg anziché internamente alla primary_node.

In ciascuna primary node verranno indicate le chiavi che si intende riconoscere esplicitamente. Questo concetto può apparire curioso ma di fatto il server eXtraWay, una volta riconosciute tutte le Unità Informative, compirà indici su ciascuna delle parti, siano essi elementi o attributi, in essa presenti, seguendo un proprio standard: tutti i contenuti degli elementi verranno indicizzati come vocabolari multi valore quindi tokenizzati e ricercabili parola per parola, mentre tutti gli attributi verranno indicizzati come vocabolari mono valore quindi assunti per la loro interessa e ricercabili solo per il valore completo. Ovviamente, essi verranno identificati per mezzo del loro XPath.
Per dare maggior ricchezza agli indici prodotti da simili contenuti è stata realizzata una batteria di impostazioni che può essere valorizzata secondo le istruzioni che seguono.

Ogni chiave si esprime per mezzo di un elemento key che deve avere per lo meno l'attributo name che ne consenta l'identificazione. Esso esprime il percorso XML dell'elemento o dell'attributo per il quale si intende dettare una regola specifica. Il valore indicato viene normalmente prefissato dall'etichetta 'XML,' che serve a distinguere le chiavi native del documento da quelle frutto di estensione xslt alle quali viene dato prefisso 'XSL,'.
Dopo tale prefisso il percorso che viene indicato può essere assoluto o relativo⁹⁾

Il canale XSL è stato introdotto diverso tempo fa ma, di fatto, sempre utilizzato in modo marginale. Il suo scopo è molteplice.

Vediamo ora gli attributi che possono essere impostati ed il loro valore e significato.

Nella stragrande maggioranza degli archivi sono presenti valori che vengono definiti Seriali. Essi sono valori solitamente numerici (ma non per forza e non soltanto) che il server assegna ad un documento per fornire, ad esempio, un codice univoco, una chiave primaria o un valore Protocollare.

Nel paragrafo precedente si è parlato di accoppiare una chiave ad un valore seriale tramite un ID. In sostanza si indica che tale chiave deve rispettare le regole indicate in questa sezione mentre ciascuna regola può trovare applicazioni su chiavi appartenenti a Primary Nodes differenti¹⁷⁾.

Questa sezione consiste di un elemento serials che contiene uno o più elementi serial ciascuno dei quali descrive una precisa regola.
Vediamo il seguente esempio cui seguià la descrizione degli attributi.

<serials>
   <serial id="protocollo" mask="#######" prefix="yes" empty="yes"/>
   <serial id="numero_record" mask="%######"/>
</serials>

Gli attributi che si possono impostare sono:

Gli archivi eXtraWay si avvalgono sovente di Thesaurus di termini relazionati tra loro. Ciò viene particolarmente utile per il trattamento di vocabolari di termini chiusi tra i quali un operatore deve scegliere così come, in presenza di un ricco thesaurus di termini della lingua italiana opportunamente relazionati, per compiere estensioni lessicali alle selezioni effettuate.
Per ragioni storiche, negli archivi eXtraWay vengono previsti solitamente due Thesaurus, uno per i termini in relazione ed uno per quelli che venivano definiti vocabolari vincolati¹⁹⁾. Essi sono identificati rispettivamente dalle etichette ths e thv. In questa sezione si indicano quali files di thesaurus usare (se quello già presente nell'archivio ovvero uno specifico) e come compiere gli accoppiamenti.
Vediamo un esempio pratico.

   <thesaurus>
      <th_file th_filename="../common.ths" th_type="ths">
         <th_link xw_key="XML,/doc/note" th_key="arrivo"/>
         <th_link xw_key="XML,/doc/classif/@cod" th_key="classif"/>
         <th_link xw_key="XML,/doc/tipologia/@cod" th_key="interno"/>
         <th_link xw_key="XML,/doc/mezzo_trasmissione/@cod" th_key="partenza"/>
         <th_link xw_key="XML,/doc/@tipo" th_key="varie"/>
         <th_link xw_key="XML,/doc/ordine/tipologia_ordine" th_key="tipologia_ordine"/>
         <th_link xw_key="XML,/doc/ordine/servizio" th_key="servizi_ordine"/>
         <th_link xw_key="XML,/doc/ordine/contratto" th_key="contratti_ordine"/>
         <th_link xw_key="XML,/doc/ordine/licenza" th_key="licenze_ordine"/>
         <th_link xw_key="XML,/doc/ordine/altro" th_key="altro_ordine"/>
      </th_file>
   </thesaurus>
 

L'esempio chiarisce come la configurazione abbia luogo entro un elemento thesaurus. In esso possono essere presenti più elementi th_file ciascuno dei quali identifica un file²⁰⁾ ed un tipo (th_type), secondo le etichette viste precedentemente.
In fine, in tale elemento si vengono a trovare gli accoppiamenti tra i canali dell'archivio e quelli del thesaurus.
I canali dell'archivio, espressi nell'attributo xw_key dell'elemento th_link, devono essere quelli descritti nelle singole primary_node negli elementi key²¹⁾ e l'accoppiamento avviene indicando nell'attributo th_key il nome logico della chiave del thesaurus²²⁾.

La configurazione dei titoli si attua per mezzo di una complessa sintassi che deriva da quella esistente in /HighWay.
Prevede l'esistenza di una voce di profilo²³⁾ di tipo “title” il cui valore è appunto la sintassi di composizione.

Sinteticamente si può indicare tale sintassi come una sequenza di “campi” e “diciture” racchiuse tra doppi apici²⁴⁾.
Ogni campo si identifica allo stesso modo in cui si dichiarano gli XPath delle chiavi nella dichiarazione delle primary_node e possono essere seguiti da alcuni modificatori²⁵⁾.
Le diciture, invece, sono semplici stringhe racchiuse tra doppi apici. Anch'esse possono contenere dei modificatori. Vale la pena soffermarci su di essi:

Vediamo alcuni esempi.
La sintassi “(~) <campo> ”~)“ fa sì che il valore del campo sia racchiuso tra parentesi ma le stesse non appariranno se il campo non è valorizzato.
Analogamente, la sintassi può essere estesa come segue: “^ (~” <campo> ”~^) “. In questo modo gli spazi compresi tra le parentesi verranno rimossi mentre verranno mantenuti al di fuori di esse in quanto espressamente dichiarati nella dicitura stessa.

Ciò di cui abbiamo sino ad ora parlato viene sovente definito “Titolo” per ragioni più che altro storiche. La tecnologia HighWay introduceva questo concetto come forma sintetica di rappresentazione del documento selezionato quando l'esito di una selezione viene mostrato, ad esempio, in forma paginata.
Se pure questa finalità è del tutto presente anche in eXtraWay, di fatto il titolo del documento ha assunto col tempo un ruolo ben diverso. Esso, infatti, viene usato per almeno altri due scopi, ovvero la costituzione di titoli aventi una regola differente ma che comprenda solo parti presenti nel titolo di default) e l'ordinamento dei documenti per valori anch'essi dichiarati nella regola di composizione del titolo.
In pratica, quindi, quello che era il “Titolo” dei documenti è divenuta una sorta di “Cache” delle sue componenti salienti.
Va da se che concepire un titolo che sia sufficientemente completo ed esaustivo consente alle applicazioni di cambiare la regola di composizione a run time ovvero richiedere ordinamenti di diversa natura avvalendosi di prestazioni sicuramente ottimizzate.
Perché questo avvenga, però, bisogna tener conto di alcuni accorgimenti. Nel capitolo precedente si è posta l'attenzione sui modificatori delle diciture. Esse non hanno ragione d'essere se si pensa al “Titolo” come “Cache” ma non di meno sono spesso presenti e corredate dai modificatori indicati.
Bisogna prestare attenzione al fatto che il server non può utilizzare come “Cache” del documento alcuna parte che si trovi dopo l'espressione di uno dei modificatori suddetti. Ne consegue che, per sfruttare al meglio le parti che si intende riutilizzare per ordinamenti e titoli diversi, si deve avere l'accortezza di elencarli in testa alla regola di composizione del titolo.

La premessa di questo paragrafo è che il cosiddetti Search Alias non hanno alcuna funzionalità specifica per il server. Essi vengono resi disponibili a beneficio delle applicazioni che possono in tal modo non doversi preoccupare di quale sia l'effettivo XPath di una chiave.
In sostanza si tratta di compiere un accoppiamento tra il percorso XPath della chiave dichiarata negli elementi key delle primary_node con un'etichetta logica che abbia senso per l'applicazione finale.

Ciò avviene tramite un elemento hw_fields che contiene tanti elementi search_alias con 2 attributi, search_name e search_key.
L'attributo search_name rappresenta l'alias, l'etichetta logica nota ed interessante per l'applicazione finale mentre l'attribuo search_key riporta il valore di XPathcitato nell'attributo name dell'elemento key delle varie primary_node.

E' importante notare che possono esistere più alias per lo stesso percorso di chiave mentre non è vero l'opposto tranne in un caso che fa eccezione, ovvero il caso del “campo chiocciola”.
Per ragioni “storiche”, la ricerca globale viene effettuata compiendo una selezione ove il campo indicato è '@'. Questo porta il server ad avere comportamenti particolari che possono essere descritti come segue:

I profili generali sono suddivisi a loro volta in diverse aree che si riferiscono ad insiemi di funzionalità o comportamenti del server.
La sintassi con la quale viene indicata una voce di profilo è la seguente:

<profile type="..." value="..."/>

Dove:

1. Impostazioni Generali
   1. type=“codepage”. [String] Obsoleto, caduto in disuso.
2. Titoli
   1. type=“title”. [Stringa] Regola di composizione dei titoli per tutte le unità informative dell'archivio. Ad esso può affiancarsi una specifica per ogni tipologia di unità informativa ma poiché questa seconda modalità non consente di avvalersi del titolo prodotto per operazioni, ad esempio, di ordinamento, essa è scarsamente utilizzata.
   2. type=“title.mixed”. [Boolean, default=false] Indica, se impostato a “true”, che gli elementi citati nella regola di cui al punto precedente devono essere considerati in modalità “container” ovvero si deve considerare come loro il contenuto anche degli elementi in essi nidificati. Serve appunto per gestire doverosamente gli XML che hanno una conformazione mixed.
   3. type=“title.hier”. [String] Regola di composizione titolo da applicare nella visualizzazione gerarchica dei documenti. Pressoché inutilizzato.
   4. type=“title.separ”. [Char] Indica il carattere da utilizzare, in sede di generazione del titolo di un documento, per separare le diverse istanze di un elemento ripetibile che risulti presente nel titolo.
   5. type=“title.lazy”. [Boolean, default=false] Indica che i titoli dei documenti non devono essere realizzati on line ovvero all'atto di inserimento o modifica del documento, bensì essere rimandati ad un momento successivo, regolato da un servizio appartenente al Server Master. E' facoltà di tale servizio rimandare ad esempio ad un periodo notturno il calcolo di tali titoli.
   6. type=“title.delay”. [Boolean, default=true] Indica che i titoli dei documenti non devono essere realizzati on line ovvero all'atto di inserimento o modifica del documento, bensì in corrispondenza della prima operazione che ne fa richiesta. Questa modalità è il default per le versioni del server 23.0.0.0 e successive.
3. Estensione XSLT
   1. type=“cache.xslt”. [String] Nome del file, completo di percorso assoluto o da considerarsi relativo alla collocazione dell'archivio, per mezzo del quale compiere un'elaborazione del XML del documento al fine di realizzare un semilavorato, sempre XML, da utilizzarsi per particolari costituzioni di titoli, vocabolari di chiavi o per gli ordinamenti.
4. Trattamento degli allegati.
   1. type=“attach.maxperdir”. [Number, defalt=100] Nella dislocazione degli allegati in directory numerate, numero massimo di file per directory.
   2. type=“attach.substext”. [String] Elenco delle estensioni, rappresentate col punto in testa e separate da spazi, per le quali è ammessa la sostituzione degli allegati.
   3. type=“attach.aliasext”. [String] Elenco delle estensioni, rappresentate col punto in testa e separate da spazi, degli allegati il cui contenuto viene considerato testuale al pari dei files .txt.
   4. type=“attach.skipext”. [String] Elenco delle estensioni, rappresentate col punto in testa e separate da spazi, degli allegati il cui contenuto non dev'essere sottoposto ad indicizzazione.
   5. type=“attach.idhome”. [String] Directory nella quale vengono dislocati i nuovi allegati e nella quale cercare, per definizione, qualsiasi allegato.
   6. type=“attach.idhome”. [String] Directory nella quale vengono cercati tutti gli allegati che non fosse stato possibile identificare nella directory di default.
   7. type=“attach.remove”. [Boolean] Consente, se impostata a valore true, che il thread che si occupa della rimozione degli allegati non assegnati si occupi di quest'archivio.
   8. type=“attach.allowdel”. [Boolean] Indica, se impostata a valore true, che nel presente archivio gli allegati non più associati ad alcun documento verranno fisicamente rimossi dal file system.
5. Trattamento degli separatori.
   1. type=“separs.default”. [String] Consiste in un'elencazione di valori numerici corrispondenti al carattere che dev'essere impostato come separatore. Essi si aggiungono ai separatori di default²⁶⁾ Si possono indicare singoli valori separati da spazi o intervalli di valori rappresentati da due numeri uniti da un trattino ('-').
   2. type=“separs.erase”. [String] Consiste in un'elencazione di valori numerici corrispondenti al carattere che non devono essere impostati come separatori. In sostanza si contrappone al precedente profilo e serve a rendere operativi separatori definiti tra quelli di default. Si possono indicare singoli valori separati da spazi o intervalli di valori rappresentati da due numeri uniti da un trattino ('-').
6. Trattamento del correttore ortografico.
   1. type=“spellchk.rule”. [String] Regola di spell checking.
7. Trattamento del catalogo.
   1. type=“catalog.strict”. [Bool] Indica, se true, che nel costituire un catalogo verranno riconosciute solo le unità informative dichiarate nel file <nomearchivio>.conf.xml. In caso contrario, tutti gli elementi figli dell'elemento radice verranno considerati come valida Unità Informative.
8. Trattamento delle estensioni in ricerca.
   1. type=“extension.top”. [Num] Limite oltre il quale non compiere estensioni delle chiavi in modo parallelo per ragioni prestazionali.
9. Trattamento degli ordinamenti.
   1. type=“sort.defaultrule”. [String] Regola di ordinamento applicata automaticamente a tutte le ricerche.
   2. type=“sort.defaultlimit”. [Num] Numero documenti oltre il quale non effettuare l'ordinamento di default. Se non impostato l'ordinamento si compie sempre.
10. Trattamento degli documenti in editing.
    1. type=“doctail.maxsize”. [Num] Dimensione massima della coda bianca da aggiungere in salvataggio ai documenti per ridurre il rischio di spostamento in successive modifiche.
    2. type=“doctail.minsize”. [Num] Percentuale massima (rapportata alla dimensione del documento) della coda bianca da aggiungere in salvataggio ai documenti per ridurre il rischio di spostamento in successive modifiche.
    3. type=“doctail.maxperc”. [Num] Percentuale massima (rapportata alla dimensione del documento) della coda bianca da aggiungere in salvataggio ai documenti per ridurre il rischio di spostamento in successive modifiche-
    4. type=“doctail.growonsite”. [Bool] Indicazione se la crescita di un documento oltre lo spazio per lui riservato nel file XML debba avvenire sul luogo (true) o gestita tramite spostamento dello stesso(false).
11. Trattamento dei check sum dei documenti.
    1. type=“fixity.signmode”. [String] Indica l'algoritmo da utilizzare per compiere la firma dei documenti.
12. Trattamento delle impostazioni d'archivio.
    1. type=“arc.allownonportable”. [Bool] Se impostato a true indica che i files dell'archivio possono avere nomi non portabili da una piattaforma ad un'altra²⁷⁾
    2. type=“arc.bestbtnodesize”. [Num] Indica la dimensione da adottare per i nodi dei BTree. La misura è in Kb quindi 0 corrisponde alla misura di default ovvero il nodo standard di 512 bytes. Valore di default: 4.
    3. type=“arc.flushdatasteps”. [Num] Indica con quale frequenza compiere il flush effettivo dei dati per migliorare le prestazioni. Si riferisce al numero di salvataggi.
    4. type=“arc.flushidxsteps”. [Num] Indica con quale frequenza compiere il flush effettivo degli indici per migliorare le prestazioni. Si riferisce al numero di salvataggi. Se non indicato vale quanto espresso con 'arc.flushdatasteps'.
    5. type=“arc.flushdatadelay”. [Num] Indica ogni quanti minuti compiere il flush effettivo dei dati per migliorare le prestazioni.
    6. type=“arc.flushidxdelay”. [Num] Indica ogni quanti minuti compiere il flush effettivo degli indici per migliorare le prestazioni. Se non indicato vale quanto espresso con 'arc.flushdatadelay'.
    7. type=“arc.attribfreeorder”. [Bool] Se true indica di non tener conto dell'ordine degli attributi di un elemento per migliorare le performance in modifica documenti.
    8. type=“arc.repository”. [Urn] Se si utilizza un repository esterno²⁸⁾ indica quale repositori si stia usando e con quali caratteristiche.
    9. type=“arc.exclude_xreg.strong”. [String] Codice prodotto da 3D Informatica per inibire in modo forte la stesura del registro di sistema per l'archivio in esame.
    10. type=“arc.exclude_xreg.light”. [String] Codice prodotto da 3D Informatica per inibire in modo semplice la stesura del registro di sistema per l'archivio in esame.
    11. type=“arc.no_idx_cache”. [Bool] In via sperimentale, se impostato a true inibisce l'uso della cache in indicizzazione On-Line..
    12. type=“arc.lazyindex”. [Bool] Se true, e se l'archivio è stato opportunamente configurato per avere chiavi primarie e secondarie, compie On-Line l'indicizzazione delle chiavi primarie e Near-On-Line quella delle chiavi secondarie.
    13. type=“arc.lazyindex.off”. [Bool] Applica lo stesso criterio della voce arc.lazyindex.off all'indicizzazione Off-Line.
    14. type=“arc.allow_moreunique”. [Bool] Consente, nel modificare un documento, che si violi l'univocità di un altro documento oltre a trovare corrispondenza piena col documento in modifica.
    15. type=“arc.test_wellformed”. [Bool] Se impostato a false inibisce i controlli di correttezza formale dei documenti dell'archivio in fase di salvataggio. Default: false.
    16. type=“arc.test_encoding”. [Bool] Se impostato a false inibisce i controlli di correttezza dell'encoding dichiarato in fase di salvataggio. Disponibile dalla versione 22.1.3.6 del server eXtraWay. Default: true.
    17. type=“arc.locktime.long”. [Num] Tempo massimo in secondi per compiere locking e quindi accesso ad un archivio. Serve a sovrascrivere il default di 15 secondi.
13. Trattamento delle impostazioni di debug.
    1. type=“debug.chkref”. [Bool] Verifica le catene dei riferimenti delle chiavi interessate dagli inserimenti e modifiche nel momento stesso dell'operazione.
14. Trattamento delle relazioni.
    1. type=“rel.logicalid”. [XPath] Percorso XML che indentifica il valore logico da utilizzarsi ad esempio in fase di esportazione.
15. Trattamento delle selezioni probabilistiche.
    1. type=“probab.hitweight”. [Num] Indica quanta percentuale del peso complessivo dato ad un unità informativa debba essere valutata sulla base del numero di termini selezionati e non sul peso ponderato della chiave coinvolta. Sovrascrive le impostazioni del file xw.ini.
    2. type=“probab.ranksize”. [Num] Indica il numero massimo di unità informative da tornare.
    3. type=“probab.minranksize”. [Num] Indica il numero minimo di unità informative da tornare.
    4. type=“probab.minrank”. [Num] Indica la percentuale di somiglianza minima, al di sotto della quale non tornare documenti.
    5. type=“probab.similartuning”. [Num] Nella ricerca per documenti simili la scelta dei termini da utilizzare per la ricerca si basa su un determinato grado di selettività. Sopra tale soglia, ovvero se il termine è troppo poco selettivo, la parola viene scartata. Per evitare che siano scartate parole anche significative su un archivio ove i termini hanno particolare distribuzione, si può intervenire su questa voce di configurazione. Le parole accettate sono quelle che selezionano 1/<numero> documenti in archivio.
       Default 100.
16. Trattamento della ricerca.
    1. type=“search.skipiw”. [Bool] Nel compiere le selezioni si richiede di produrre, per default, catene di riferimenti inerenti i documenti selezionati in cui le iwords vengono ignorate. Causa l'inversione del default usato solitamente dal server per velocizzare le selezioni.
    2. type=“search.wildcardprefix”. [Num] La selezione può essere effettuata con l'uso di Wild Cards. L'abuso di questa modalità può condurre a selezioni eccessivamente complesse, solitamente frutto di un uso errato del sistema e quindi non realmente utili o significative.
       Per tutelarsi dagli abusi o dall'uso improprio delle Wild Cards in ricerca si può impostare questo valore che indica di quanti caratteri debba essere la radice priva di Wild Cards di una chiave perché la stessa possa considerarsi valida in questo tipo di ricerche.
    3. type=“search.similarprefix”. [Num] La selezione può essere effettuata indicando la somiglianza tra termini ovvero selezionando termini che somiglino a quello impostato perché hanno caratteri in più, in meno o semplicemente diversi.L'abuso di questa modalità può condurre a selezioni eccessivamente complesse, solitamente frutto di un uso errato del sistema e quindi non realmente utili o significative.
       Per tutelarsi dagli abusi o dall'uso inproprio delle somglianze in ricerca si può impostare questo valore che indica di quanti caratteri debba essere la radice, ovvero la parte iniziale comune a tutte le chiavi che non viene sottoposta al controllo di similitudine in modo da restringere sensibilmente il campo d'azione.
    4. type=“search.englishsint”. [Bool] Per richiedere che l'archivio operi solo con sintassi inglese per AND, OR e NOT.
17. Trattamento della ricerca fonetica.
    1. type=“phono.flags”. [String] Identificazione delle regole di default, ovvero flags, nell'estensione fonetica dei termini in ricerca.
    2. type=“phono.charlimit”. [Num] Numero massimo di caratteri di una chiave oltre il quale non procedere nella ricerca delle somiglianze fonetiche.
    3. type=“phono.rule”. [String] Etichetta che identifica, una ad una, le regole fonetiche impostate per un dato archivio. Dev'essere seguita da un numero arabo progressivo in base 1.