Regole per la composizione della file_location rule o per la composizione di chiavi concatenate

Introduzione

Il presente documento descrive le regole per mezzo delle quali possono essere assunte parti di elementi o attributi da un'unit� informativa e con essi costituire, a seconda dei casi, regole di dislocazione dei files XML ovvero regole di composizione di chiavi articolate. In questo secondo caso � ammesso combinare solo valori di attributi appartenenti allo stesso elemento.

La tecnica adottata si � evoluta nell'arco del tempo ed i cambiamenti hanno evidenziato, nel corso del tempo, le limitazioni della sintassi inizialmente scelta. Nononstante questo, le evoluzioni non hanno ancora condotto ad una rivoluzione di questa sintassi che vedremo nel dettaglio nei paragrafi seguenti.

In realt� le due sintassi sono decisamente diverse ma hanno molteplici punti in comune, in particolare in materia di Modificatori delle regole di composizione.

Si rimanda, per ulteriore documentazione, alle schede 0011660, 0016305 e 0016577 dell'applicazione RightWay.

La regola di composizione nomi file

La regola di composizione dei nomi di files si applica nel momento in cui, dovendo configurare un nuovo archivio, si intende assegnare ad esso una distribuzione delle unit� informative in files XML distinti raggruppandole ove possibile per teme, data, classificazione o per qualsiasi altra caratteristica considerata degna di raggruppare tali dati.

E' possibile dichiarare una regola di composizione dei nomi di files che abbia valenza per tutte le tipologie di unit� informative cos� come si pu� altres� dichiarare una regola specifica per ognuna di esse. Di seguito il documento riterr� che il lettore abbia dimesticezza col formato dei files nomearchivio.conf.xml.

Nel file di configurazione, quindi, pu� essere introdotto un elemento file_location come elemento figlio dell'elemento xway_cfg che funge da radice dell'intero file. Se cos� si opera, tale regola di composizione file vale per tutte le unit� informative o, quanto meno, per quelle nelle quali non sia stata esplicitata una regola. Lo stesso elemento file_location pu� troare posto come figlio dell'elemento primary_node fungendo quindi da dichiarazione esplicita dedicata ad una tipologia di unit� informativa ed a nessun'altra.

La regola di composizione dei nomi di files, qualora omessa, sar� considerata single, come verr� meglio indicato in seguito.

La distribuzione dei files pu� avvenire sulla base di regole predefinite o sulla base di una regola definita dell'amministratore dell'archivio. Quanto detto si confuigura agendo sull'attributo mode dell'elemento file_location. I valori possibili sono:

single: Ogni unit� informativa viene dislocata in un proprio file XML distinto da ogni altro. Il file assume un nome numerico progressivo assegnato dal server e viene dislocato in una serie di directory anch'esse numerate cos� che si vengano a trovare non oltre 100 files per directory.
day: Ogni unit� informativa inserita in un dato giorno viene dislocata in un file avente come nome la data in esame, nel formato YYYYMMDD, tali files vengono distribuiti in directory denominate come l'anno ed il mese nella forma YYYYMM.
month: Ogni unit� informativa inserita in un dato mese viene dislocata in un file avente come nome il mese in esame, nel formato YYYYMM, tali files vengono distribuiti in directory denominate come l'anno nella forma YYYY.
year: Ogni unit� informativa inserita in un dato anno viene dislocata in un file avente come nome l'anno in esame, nel formato YYYY, tali files non vengono distribuiti in directory.
rule: Il contenuto di ogni unit� informativa condiziona una o pi� regole sino all'ottenimento di un nome di file valido.

Nel caso l'attributo mode assuma il valore rule si deve prendere in esame il contenuto dell'attributo rule la cui sintassi � il vero obiettivo di questa documentazione.
A prima vista una regola composta da pi� regole distinte e, per ognuna, da pi� componenti, risulta particolarmente complessa da interpretare. Per frazionarla opportunamente si devono identificare tutte le sue parti.

In primo luogo la regola complessiva pu� essere espressa da una singola regola o da una sequenza di regole. Se esistono pi� regole esse sono separate dal carattere ; il quale divide in pi� regole distinte la regola complessiva.
Le regole vengono interpretate da sinistra verso destra. Non appena una di esse � soddisfatta, ovvero tutte le componenti in essa citate sono presenti e valide nel documento in esame, la regola viene considerata valida e non si prosegue oltre. Se, per contro, ogni regola identificata risulta mancate di qualche componente, l'ultima, quindi quella pi� a destra, viene considerata comunque valida. Sar� cura di chi configura queste regole garantirsi che il nome di file che da essa deriva sia un nome sempre valido.

Ora che abbiamo chiarito come si identifica una singola regola e come esse vengano interpretate in un dato ordine, vediamo come si compone una regola e e quali caratteristiche essa debba avere per essere considerata soddisfatta.
Innanzitutto ogni regola distinta � rappresentata da una stringa composta da parti fisse e parti variabili, derivate dal contenuto del documento in esame, dette appunto componenti. Tali componenti sono di fatto composte dal valore di un elemento o attributo del documento in esame pi� eventuali altri parti fisse ma condizionate alla sua presenza.

Ogni componente � riconoscibile in quanto inizia e termina col carattere $. Al suo interno pu� quindi trovarsi una o due parti fisse condizionate (che vedremo poi negli esempi) e l'identificazione della parte del documento, elemento o attributo, iniziata e terminata a sua volta dal carattere @. A questa parte del documento possono poi essere applicati dei modificatori (Vds. Modificatori delle regole di composizione) che si trovano sempre entro i due caratteri @ ma sono separati dall'identificatore della parte del documento dal carattere |.

Se il risultato dell'acquisizione del valore dell'elemento o dell'attributo indicato e la successiva applicazione dei modificatori danno un risultato vuoto, la regola si considera non soddisfatta e si procede con l'interpretazione della regola successiva. Come detto in precedenza, questo non vale per l'ultima regola la quale, anche se il valore ottenuto risulta vuoto, dev'essere considerata soddisfacente comunque.

L'identificatore della parte di documento interessata deve prevedere un percorso XML completo (anche se � possibile, per quando sconsigliabile, indicarlo relativo) prefissato da XML,

Poich� un buon esempio vale pi� di mille parole si invita, dopo aver letto la parte sui modificatori, a consultare gli Esempi di composizione nomi files

La regola di composizione chiavi articolate

L'esigenza di poter produrre delle chiavi composite sulla base dei dati contenuti in un documento � subito stata avvertita, sin dalle primissime applicazioni. L'esperienza fatta in tale frangente, ed anche nei periodi successivi di crescita del progetto eXtraWay, ha mostrato come nella maggioranza dei casi sia particolarmente utile comporre chiavi sulla base della combinazione degli attributi di un elemento. In seguito si sono verificate casistiche in cui anche la combinazione del valore di pi� elmenti sarebbe risultata utile ma tale implementazione, per quanto prevista, non � ancora stata effettuata.

Concentriamoci quindi sulla composizione di chiavi per mezzo della combinazione degli attributi di un elemento poich� tali regole, attualmente, possono essere applicate esclusivamente alla configurazione di questi ultimi. In origine erano state concepite forme molto semplici di concatenazzione con o senza spazi che si sono rapidamente rivelate inadeguate e sono state quindi abolite lasciando il posto alla sintassi di composizione che andremo rapidamente a vedere.

Ogni regola � una composizione di una o pi� regole (sino ad un massimo stabilito che non si ritiene di dover documentare in questa sede essendo potenzialmente soggetto a variazioni che non interessano la sintassi della regola).
Ogni regola distinta � riconoscibile in quanto inizia con la seguenza...

#<nomeregola>:

...e termina quando la stringa stessa ha termine o quando si incontra una nuova regola di composizione. Dopo aver identificato il nome della regola essa si compone in modo sostanzialmente simile alla regola di composizione dei nomi di files.
In altre parole essa � composta da parti fisse (costanti) e componenti che sono rappresentate dal valore degli attributi. Le componenti sono identificabili perch� hanno inizio e fine col carattere $. Al loro interno posson essere presenti ulteriori costanti condizionate e l'indicazione del vero e proprio nome dell'attributo che ha inizio e fine col carattere @.
Sempre all'interno di questi delimitatori, separati dal nome dell'attributo per mezzo del carattere |, trovano posto i modificatori applicati al contenuto dell'attributo.

Poich� un buon esempio vale pi� di mille parole si invita, dopo aver letto la parte sui modificatori, a consultare gli Esempi di composizione chiavi articolate

Modificatori delle regole di composizione

Come annunciato nei paragrafi precedenti, ad ogni componente una nome di file o una chiave articolata, possono essere applicati dei modificatori. Solitamente un modificatore � rappresentato da un carattere che ne identifica il tipo e, di seguito, caratteri cifre e simboli il cui significato dipendono dal tipo di modificatore espresso col primo carattere. I vari modificatori, separati tra loro dal carattere virgola, vengono applicati da sinistra verso destra applicandosi sul risultato dei modificatori applicati sino a quel momento.
Dal momento che la virgola assume un significato particolare, come separatore dei diversi modificatori, se essa appare in almeno una delle regole come parametro essa dev'essere escapata preponendole il carattere \.

Per mezzo di questi modificatori si possono frammentare e ricomporre in modo piuttosto articolato i valori contenuti in elementi ed attributi a patto di conoscere, quanto meno in modo sommario, la conformazione che tali contenuti avranno.

Vediamo nel dettaglio i modificatori ricordando che anche i valori numerici vengono trattati come stringhe:

d: Indica che il valore dev'essere trattato come data. Ne consegue che, quale che sia il suo effettivo contenuto e formato, si cercher� di ricondurre il valore espresso alla forma YYYYMMDD, quindi ad una sequenza di 8 cifre prive di speratori di qualsiasi tipo. La conversione offerta dal server prevede che il formato possa essere espresso in molteplici modi, con l'anno espresso in 2 o 4 cifre e con o senza separatori di varia natura. In caso di ambiguit� si assume la data presumibilmente pi� credibile privilegiando, sempre in caso di mabiguit�, il formato europeo giorno, mese ed anno piuttosto che il formato americamo mese, giorno ed anno che non si considera normalmente utilizzato.
f: Indica che si intende formattare il valore. La lettera successiva pu� essere n per indicare formattazione numerica o s per indicare una formattazione di tipo stringa. Dopo tale lettera, obbligatoria, dev'essere presente un numero, eventualmente negativo. Tale numero rappresenta la dimensione (in valore assoluto) che il valore assumer� al termine della formattazione. Il fatto che sia positivo o negativo indica se l'operazione di allineamento avverr� a sinistra o a destra. Se il valore � minore di 0 l'allineamento (la formattazione) ha luogo a sinistra, in caso contrario, per valori maggiori di 0 esso ha luogo a destra. Formattare a sinistra vuol dire allineare il valore a sinistra ed aggiungere l'elemento di riempimento a destra, formattare a destra vuol dire spostare a desta il valore preponendo l'elemento di riempimento sino al raggiungimento della dimensione assoluta richiesta. Se il valore da formattare ha dimensione maggiore o uguale alla dimensione indicata l'operazione non ha luogo.
p: Indica che si vuole acquisire esclusivamente una parte ben precisa del valore identificato. Tale modificatore � seguito da un valore numerico, positivo o negativo, un segno '-' ed un ulteriore valore, sempre positivo. Il primo valore indica l'offset dal quale partire. Se il valore � maggiore o uguale a 0 esso rappresenta la posizione, in base 0, dalla quale considerare l'inizio del valore da acquisire partendo dalla sinistra del valore stesso. Se, per contro, il valore risulta negativo esso rappresenta la posizione intesa in offset a partire da destra, quindi di quanto arretrare per identificare il punto di partenza dal quale acquisire il valore definitivo. La seconda cifra, sempre positiva e maggiore di 0, indica quanti caratteri acquisire da quel punto. Se la dimensione indicata � superiore alla quantit� disponibile a partire dal punto d'origine identificato, verranno acquisiti solo i caratteri disponibili.
t oppure T: Procedura di tokenizzazione. Il primo carattere, che pu� essere maiuscolo o minuscolo, dev'essere seguito da un carattere l o r ad indicare se l'operazione avviene da sinistra (l = left) o da destra (r = right). Dopo il carattere che indica il punto di partenza devono essere indicati uno o pi� caratteri che indicato un elenco di simboli incontrando uno dei quali la tokenizzazione ha termine. Se in quest'elenco � presente la virgola essa va escapata preponendole il carattere \. Con il metodo descritto si pu� isolare una parte di dimensione imprecisata da un valore assumendone una parte sino ad un dato carattere e non oltre. Se il simbolo che richiede la tokenizzazione � maiuscolo, l'operazione ha senso inverso: invece di isolare una parte ben precisa e scartare il resto, la parte isolata � quella che viene scartata a favore della rimanente.
Attenzione:
Quale che sia il senso in cui si decide di far operare il tokenizzatore, il carattere incontrato e riconosciuto viene perso sempre e comunque, anche nel caso di inversione del comportamento di tokenizzazione con il simbolo 'T' maiuscolo.

A partire da:
Dalla versione 21.0.3.6 del server si introduce un nuovo comportamento. Qualora il secondo carattere, quello che detta la direzione [l|r] sia masiuscolo anzich� minuscolo, il carattere che delimita il token non viene pi� perso bens� mantenuto. Il risultato di queste impostazioni pu� quindi essere cos� riassunto:
c: Indica che si vuole compiere una valutazione condizionale. Il carattere dev'essere seguito da un'altro carattere che deve indicare se il test da compiere sar� alfanumerico (a), data (d) o numerico (n). Questo dev'essere seguiti da un ulteriore carattere ad indicare il tipo di confronto da effettuare: per valore uguale (e), minore (l) o maggiore (u). A questo punto ha inizio una formula composta da tre elementi: il primo � il valore con il quale effettuare il confronto e termina con il carattere ?, il secondo � il valore da utilizzare quando il confronto ha successo e termina con il carattere : mentre il terzo � il vaore da assumere quando il confronto fallisce. Se la seconda o la terza parte della formula � rappresentata da un asterisco esso rappresenta che il valore da assegnare � lo stesso origiariamente incontrato, quindi il valore rimane invariato.
s: Indica la richiesta di una sostituzione. Esso dev'essere seguito da 2 caratteri: il primo rappresenta il carattere da cercare nel valore ed il secondo il carattere da usare per sostituire nel valore tutte le istanze del primo in esso rilevate.
b: Indica la richiesta di eliminare gli spazi (balnks) indesiderati. Tutti gli spazi, in testa ed in coda al valore, verranno rimossi.

Gli esempi delle sezioni successive chiariranno meglio l'uso di queste sintassi.

Esempi di composizione nomi files

Di seguito alcuni esempi particolarmente ricchi.

Partiamo da un esempio proveniente dall'applicazione DocWay. La regola di composizione del nome di file che ospita i vari documenti protocollati � la seguente:

<file_location mode="rule" rule="$@XML,/doc/storia/creazione/@data|p0-4@$/$@XML,/doc/@cod_amm_aoo@/$$@XML,/doc/@bozza|caesi?bozze:@$;$@XML,/doc/rif_interni/rif/@cod_fasc|p0-4@$/$@XML,/doc/rif_interni/rif/@cod_fasc|p5-7@$/fascicoli/$@XML,/doc/rif_interni/rif/@cod_fasc|p13-99,tl.,s\/_@$/$@XML,/doc/rif_interni/rif/@cod_fasc|p0-4@$-$@XML,/doc/rif_interni/rif/@cod_fasc|p13-99,tl.,s\/_@$.$@XML,/doc/rif_interni/rif/@cod_fasc|Tl.,tl.@$;$@XML,/doc/@anno@$/$@XML,/doc/@cod_amm_aoo@$/repertori/$@XML,/doc/repertorio/@cod@$/$@XML,/doc/@cod_amm_aoo@$-$@XML,/doc/@anno@$-$@XML,/doc/repertorio/@cod@$;$@XML,/doc/@anno@$/$@XML,/doc/@cod_amm_aoo@$/documenti/$@XML,/doc/classif/@cod|s\/_@$/$@XML,/doc/@anno@$-$@XML,/doc/classif/@cod|s\/_@$" move_always="yes"/>

Vista cos� risulta particolarmente complessa ma se osseviamo meglio ci rendiamo conto che essa � la composizione di diverse regole distinte che sono...

$@XML,/doc/storia/creazione/@data|p0-4@$/$@XML,/doc/@cod_amm_aoo@/$$@XML,/doc/@bozza|caesi?bozze:@$

$@XML,/doc/rif_interni/rif/@cod_fasc|p0-4@$/$@XML,/doc/rif_interni/rif/@cod_fasc|p5-7@$/fascicoli/$@XML,/doc/rif_interni/rif/@cod_fasc|p13-99,tl.,s\/_@$/$@XML,/doc/rif_interni/rif/@cod_fasc|p0-4@$-$@XML,/doc/rif_interni/rif/@cod_fasc|p13-99,tl.,s\/_@$.$@XML,/doc/rif_interni/rif/@cod_fasc|Tl.,tl.@$

$@XML,/doc/@anno@$/$@XML,/doc/@cod_amm_aoo@$/repertori/$@XML,/doc/repertorio/@cod@$/$@XML,/doc/@cod_amm_aoo@$-$@XML,/doc/@anno@$-$@XML,/doc/repertorio/@cod@$

$@XML,/doc/@anno@$/$@XML,/doc/@cod_amm_aoo@$/documenti/$@XML,/doc/classif/@cod|s\/_@$/$@XML,/doc/@anno@$-$@XML,/doc/classif/@cod|s\/_@$

Abbiamo quindi 4 regole distinte. La seconda verr� presa in esame solo se la prima non � soddisfatta, cos� la terza se neanche la seconda viene soddisfatta ed in fine la quarta se tutte le precedenti falliscono. Vediamo ora nel dettaglio la prima regola...

$@XML,/doc/storia/creazione/@data|p0-4@$/$@XML,/doc/@cod_amm_aoo@/$$@XML,/doc/@bozza|caesi?bozze:@$

Essa si compone di tre distinte componenti ed una costante...

$@XML,/doc/storia/creazione/@data|p0-4@$
/
$@XML,/doc/@cod_amm_aoo@/$
$@XML,/doc/@bozza|caesi?bozze:@$

La prima componente identifica l'attributo data preso dall'elemento creazione. Della data in esame, intesa presumibilmente nel fomato YYYYMMDD, si prendono 4 caratteri a partire dalla posizione 0, quindi, in breve, i primi 4 caratteri. Ad essi si accoda la costante '/' e poi il valore, non modificato, dell'attributo cod_amm_aoo.
La terza componente � un test sul contenuto dell'attrubito bozza. Il test viene effettuato per uguaglianza alfanumerica. Se contiene quindi la stringa si il valore assegnato � la stringa bozze, altrimenti � una stringa vuota. La stringa vuota, se non si tratta di una bozza, comporta che la regola risulti non soddisfatta e si passi al trattamento della successiva...

$@XML,/doc/rif_interni/rif/@cod_fasc|p0-4@$/$@XML,/doc/rif_interni/rif/@cod_fasc|p5-7@$/fascicoli/$@XML,/doc/rif_interni/rif/@cod_fasc|p13-99,tl.,s\/_@$/$@XML,/doc/rif_interni/rif/@cod_fasc|p0-4@$-$@XML,/doc/rif_interni/rif/@cod_fasc|p13-99,tl.,s\/_@$.$@XML,/doc/rif_interni/rif/@cod_fasc|Tl.,tl.@$

Anche questa va frazionata in varie parti...

$@XML,/doc/rif_interni/rif/@cod_fasc|p0-4@$
/
$@XML,/doc/rif_interni/rif/@cod_fasc|p5-7@$
/fascicoli/
$@XML,/doc/rif_interni/rif/@cod_fasc|p13-99,tl.,s\/_@$
/
$@XML,/doc/rif_interni/rif/@cod_fasc|p0-4@$
-
$@XML,/doc/rif_interni/rif/@cod_fasc|p13-99,tl.,s\/_@$
.
$@XML,/doc/rif_interni/rif/@cod_fasc|Tl.,tl.@$

Questa regola � decisamente pi� complessa della precedente. Ci dice che vengono presi i primi 4 caratteri dell'attributo cod_fasc, ad essi viene accodato uno '/' e di seguito altri 7 caratteri a dopo averne saltati 5. Alla stringa ottenuta viene accodata la costante '/fascicoli/' a sua volta seguita da un'altra parte dell'attributo cod_fasc. Per isolare questa parte si satlano i primi 13 caratteri e se ne prendono 99, allo scopo di acquisire tutto il contenuto rimanente. Da essi si prende la prima parte, da sinistra, sino al primo punto. di seguito si sostituisce il carattere '/', preceduto da un escape di sicurezza, con il carattere '_'. L'attributo cod_fasc viene utilizzato ancora nelle due componenti successive in modo simile alle precedenti sempre intercalando con alcune costanti ed in fine si richiede di acquisire sempre il valore del codice fascicolo, isolare la parte iniziale sino al primo punto e scartarla, poi acquisire, della restante parte, privata comunque del punto identificato precedentemente, della restante parte, dicevamo, acquisire, sempre da sinistra, la parte sino al punto.
La dove il documento non appartenesse ad alcun fascicolo questa regola non sarebbe soddisfatta in alcun modo e sarebbe quindi necessario passare all'interpretazione della terza che mostriamo direttamente frazionata

$@XML,/doc/@anno@$
/
$@XML,/doc/@cod_amm_aoo@$
/repertori/
$@XML,/doc/repertorio/@cod@$
/
$@XML,/doc/@cod_amm_aoo@$
-
$@XML,/doc/@anno@$
-
$@XML,/doc/repertorio/@cod@$

Questa regola non presenta modificatori e si tratta quindi della mera unione dei valori degli attributi indicati. Se per� il documento non appartiene ad un repertorio si giunge in fine alla quarta regola, anch'essa gi� frazionata...

$@XML,/doc/@anno@$
/
$@XML,/doc/@cod_amm_aoo@$
/documenti/
$@XML,/doc/classif/@cod|s\/_@$
/
$@XML,/doc/@anno@$
-
$@XML,/doc/classif/@cod|s\/_@$

In questa regola si notano esclusivamente delle sostituzioni.

In tutti gli esempi portati sino ad ora le componenti da utilizzare non prevedevano al loro interno delle costanti condizionate. Prendiamo quindi l'ultima regola indicata. Le costanti espresse tra una componente e l'altra, vengono inserite nel risultato finale indipendentemente dal valore delle singole componenti, quindi, se pe esempio l'attributo cod_amm_oo risultasse non valorizzato un documento del 2005 avrebbe un file nella forma...

2005//documenti/...

ponendo una doppia barra nel nome del file. Evidentemente chi ha configurato questa regola � ragionevolmente certo che tale attributo sia sempre valorizzato ma se cos� non fosse la parte della regola rappresentata da...

...
/
$@XML,/doc/@cod_amm_aoo@$
/documenti/
...

potrebbe essere invece espressa come...

...
$/@XML,/doc/@cod_amm_aoo@$
/documenti/
...

Come si pu� notare il carattere '/' trova ora posto tra i simboli $ ma ovviamente al di fuori dei simboli @ che isolano la componente XML del documento. Ponendo delle costanti entro i simboli $ esse vengono considerate condizionate al valore della componente XML in esame. Se quindi cod_amm_aoo non risulta valorizzato (o l'applicazione si di esso dei modificatori conduce ad un valor vuoto) la costante condizionata non viene aggiunta alla regola e il nome file risulterebbe...

2005/documenti/...

Immaginiamo di avere un elemento il cui valore, non ben identificato, pu� essere ricondotto ad una data e che si voglia inserire i documenti che hanno un simile elemento in un file corrispondente al mese in esame. La regola portebbe apparire come...

$@XML,/doc/verb_date|b,d,fn8,p0-6@$

richiedendo l'eliminazione degli spazi in testa ed in coda, il trattamento di quanto rimasto come data, la formattazione a sinistra per 8 caratteri e l'acquisizione dei primi 6 che dovrebbero corrispondere all'anno ed al mese in formato YYYYMM. Non essendo certi del formato verboso, dopo il trattamento del valore come data si compie la formattazione ad 8 cifre per avere materiale sufficiente, anche a costo di avere soli zeri se non fosse stato possibile isolare una data valida.

Esempi di composizione chiavi articolate

Di seguito alcuni esempi su come comporre chivi articolate.

Vediamo un esempio di chiave articolata prodotta nell'applicazione DocWay. Essa appare come ...

  <key name="XML,/doc/rif_interni/rif" instance="yes" attr_collate="#dirittonomeuff:$@diritto@$$|^| @nome_uff@$#dirittonomepersona:$@diritto@$$|^| @nome_persona@$#dirittocodpersonacodfasc:$@diritto@$|$@cod_persona@$|$@cod_fasc@$#dirittocoduffcodfasc:$@diritto@$|$@cod_uff@$|$@cod_fasc@$#dirittocoduffscartato:$@diritto@$|$@cod_uff@$|$@scartato@$#dirittocodpersonascartato:$@diritto@$|$@cod_persona@$|$@scartato@$"/>

Gaurdando meglio la regola ci si rende conto che essa � la combinazione di pi� regole e quindi di pi� chiavi distinte. Esse sono...

#dirittonomeuff:$@diritto@$$|^| @nome_uff@$
#dirittonomepersona:$@diritto@$$|^| @nome_persona@$
#dirittocodpersonacodfasc:$@diritto@$|$@cod_persona@$|$@cod_fasc@$
#dirittocoduffcodfasc:$@diritto@$|$@cod_uff@$|$@cod_fasc@$
#dirittocoduffscartato:$@diritto@$|$@cod_uff@$|$@scartato@$
#dirittocodpersonascartato:$@diritto@$|$@cod_persona@$|$@scartato@$

Diversamente dalle regole di composizione nomi file � necessario indicare esclusivamente il nome dell'attributo in quanto la regola sottintende l'elemento al quale appartengono gli attributi indicati.

Nell'archivio civile, avremo invece...

<key name="XML,/civile" attr_collate="#asn:$@datdec|d,p0-4,fn4@$$@numdec|p-5-5,fn5@$"/>

che ci mostra la regola...

#asn:$@datdec|d,p0-4,fn4@$$@numdec|p-5-5,fn5@$"/>

Questa richiede che l'attributo datdec venga trattat come data, ne vengano acquisiti i primi 4 caratteri e siano formattati a 4 cifre (per compensare il caso che non ve ne siano abbastanza disponibili). A questo valore vengono accodati gli ultimi 5 caratteri dell'attributo numdec (5 caratteri a partire da offset -5) anch'essi formattati a 5 caratteri qualora non ve ne fossero a sufficienza. Si ottiene quindi un codice di 4+5=9 caratteri. Per contro la regola...

<key name="XML,/civile/rnc" attr_collate="#snorm:$@gen@$$ @reg@$$ @min@$$ @naz@$$ @dat@$$ @num@$$ @al@$$ @art@$$ @com@$$ @ln@$" instance="yes"/>

mostra una semplice sequenza di attributi che vengono concatenati ponendo tra essi uno spazio. Si fa notare che lo spazio si trova all'interno dei caratteri $ di delimitazione cos� da essere condizionato dall'effettiva valorizzazione dell'attributo: se l'attributo manca o ha valor vuoto non viene inserito lo spazio considerato inutile.

Regole di concatenazione composita

Per Regole di Concatenazione Composita si indica la possibilit� di creare chiavi che si compongono in modo dinamico per mezzo di attributi ed elementi sparsi un po' ovunque nell'intera unit� informativa. Questo comporta che le chiavi prodotte sono il prodotto cartesiano di tutte le combinazioni possibili delle componenti indicate.

La dichiarazione della regola composita differisce dallo stile adottato sino ad ora per le concatenazioni degli attributi di un elemento in quanto non ci sono regole da applicare ad un percorso XML corrispondente ad un elemento bens� bisogna inventare letteralmente un percorso di chiave e ad esso associare la regola che lo compone. Nel denominare tale percorso si suggerisce di fare uso del carattere '#' come primo caratere dell'ultima parte del percorso al fine di distinguere questo canale di ricerca da qualsiasi altro canale reale.

Veniamo quindi a descrivere come si dichiara una simile chiave con l'ausilio di alcuni esempi. Bisogna sapere che:
a) La sintassi con la quale si dichiara la regola � identica a quella utilizzata per le regole espresse in attr_collate ma indicando l'intero percorso XML e non semplicemente il nome dell'attributo. Valgono quindi tutti gli stessi modificatori.
b) La sintassi di cui al punto 'a' dev'essere indicata nell'attributo collate_rule di un elemento key che pu� anche essere di fantasia. In tal caso si suggerisce, per quanto non sia obbligatorio, che il nome finale del percorso che descrive la chiave sia prefissato dal carattere '#' come avviene per le altre chiavi speciali.
c) Tutti i percorsi XML citati nella regola espressa nell'attributo collate_attr devono essere dichiarati in un apposito elemento key, essi non possono essere sottintesi e possono anche essere skippati ovvero da non indicizzare in quanto a valore pierno.
d) Le chiavi prodotte non possono essere cercate in adiacenza in quanto ad esse viene associata una iword non rapportabile al documento.

Un esempio di dichiarazione di una simile chiave pu� essere il seguente...

<key name="XML,/NewsML/NewsEnvelope/#AgiNotizia" key_style="one" collate_rule="$@/NewsML/NewsItem/Identification/NewsIdentifier/NewsItemId|tl-,fn4@$"/>

...oppure, in un caso ancora pi� evidente...

<key name="XML,/NewsML/NewsEnvelope/#AgiDate" key_style="one" value_type="date" collate_rule="$@/NewsML/NewsEnvelope/DateAndTime|p0-8,d@$"/>
<key name="XML,/NewsML/NewsEnvelope/#AgiTime" key_style="one" value_type="num" collate_rule="$@/NewsML/NewsEnvelope/DateAndTime|p9-6,fn-6@$"/>
<key name="XML,/NewsML/NewsEnvelope/DateAndTime" key_style="skip"/>

...ove l'elemento DateAndTime non � richiesto come indice a se stante ma da esso si producono due distinti indici. Negli esempi portati si fa uso di un solo canale nella regola ma ne possono essere usati vari senza limitazioni come nel caso di regole applicate agli attributi di un elemento.

Autore:: Tirabassi Roberto

Date: 2008/02/05 11:45:50

Torna a Indice delle voci