Skip to topic | Skip to bottom
Home

Tesi
Tesi.CapitoloContributoTeoricor1.13 - 22 Jan 2007 - 17:54 - GuidoBillitopic end

Start of topic | Skip to actions

Capitolo 3: Contributo teorico

Sommario

discorso su documenti legacy, perchè abbiamo certi tipi di vincoli sul content model mioto ecc...

DA DIRE:

  • un elemento un tipo
  • metadati solo tramite attributi

I pattern

DISCORSO GENERALE SUI PATTERN

In questo capitolo saranno presentati presentati i Pattern, le loro caratteristiche e sarà effettuata una analisi della loro capacità espressiva rispetto alle strutture definibili mediante i tradizionali linguaggi di schema.

I pattern sono schemi che impongono dei vincoli sulla struttura dei documenti.

L'obiettivo dei vincoli e' fornire alle istanze una struttura che rendesse evidente la semantica delle varie parti permettendo quindi raggiungere una convergenza tra schemi e istanze.

Lo studio dei pattern pero', in particolare il pattern TABELLA e il pattern CONTESTO ADDITIVO, ha posto il problema se alcuni di questi vincoli potessero essere infranti (vincoli deboli) quando si fanno interagire piu' pattern (per esempio un contesto additivo che aggiunge un record ad una tabella).

L'obiettivo di questa analisi e' determinare quali siano i vincoli caratteristici dei pattern (forti) e quali possano essere infranti (deboli) magari durante l'uso combinato dei pattern e se alcuni di questi possano proprio essere eliminati

Verranno ora analizzati singolarmente i vari pattern. Ognuno di essi verrà presentato indicando il suo significato astratto, la sua definizione e i vincoli che impone al contenuto. Queste considerazioni serviranno per l'analisi del contesto additivo e della sua interazione con gli altri pattern.

Marker

Descrizione

Il pattern marker serve a rappresentare tutti quegli elementi la cui presenza è di per se sufficiente a rappresentare un certo significato. I possibili usi di questo pattern sono molteplici: può essere usato come semplice marcatore posizionale all'interno di un blocco di testo oppure fornire un puntatore da/verso un altro punto del documento fornendo così un meccanismo di indirezione.

Definizione

Vengono identificati come marker tutti gli elementi privi di content model.

Definizione mediante DTD:

    <!ELEMENT maker EMPTY>

Definizione mediante Xml-Schema:

    <xs:element name="marker">
        <xs:complexType/>
    </xs:element>

Definizione mediante Relax-NG DA FARE

Analisi delle caratteristiche

Il vincolo cararatteristico del pattern è l'assenza di content model, fatta eccezione per gli attributi che sono comunque ammessi.

Questo vincolo può essere considerato un vincolo piuttosto forte, in quanto riflette la semantica stessa del pattern: l'informazione è la presenza dell'elemento in se.

Se si sentisse la necessita' di strutturare ulteriormente l'elemento, fornendogli un content model composto da testo o sotto elementi, vorrebbe dire che la sua presenza non e' sufficiente a rappresentare l'informazione. In questo caso probabilmente quello di cui si ha bisogno è una struttura più complessa come un atomo o un record.

Risulta quindi evidente come la violazione del vincolo risulta sostanzialmente in un cambiamento di pattern utilizzato.

Atomo

Descrizione

Il pattern atomo serve a rappresentare una informazione atomica non ulteriormente strutturabile, come ad esempio numeri e quantità scalari, nomi e così via.

Definizione

Vengono identificati come atomi tutti gli elementi il cui content model ammette solo testo.

Esempio di definizione mediante DTD:

    <!ELEMENT atomo (#PCDATA) >

Esempio di definizione mediante Xml-Schema:

    <xs:element name="marker" type="xs:string" />

Esempio di definizione mediante sintassi Relax-NG: DA FARE

(In realtà è valida una qualunque dichiarazione il cui content model preveda solo testo)

Analisi delle caratteristiche

La presenza di solo testo è il vincolo che rispecchia la peculiarità del pattern, e caratterizza l'informazione contenuta nell'elemento. Indica che i dati contenuti nell'elemento sono direttamente utilizzabili e non sono ulteriormente strutturati.

Se si sentisse la necessità di strutturare ulteriormente il contenuto, permettendo la presenza di sotto-elementi mescolati al testo, vorrebbe dire che in realtà l'informazione è probabilmente meglio rappresentabile da un content model misto.

Anche in questo caso la violazione del vincolo della presenza di solo testo implica un cambiamento di pattern.

Record

Descrizione

Un record rappresenta una collezione di valori non ripetibili, raggruppati per formare una unica entità logica. Matematicamente parlando il pattern record è assimilabile al concetto di insieme.

Definizione

Sono record tutti gli elementi il cui content model ammette solo elementi, non ripetibili.

Esempio di definizione tramite DTD-SGML:

        <!ELEMENT record (C1? & C2? & C3?)>
        <!ELEMENT C1 ... >
        <!ELEMENT C2 ... >
        <!ELEMENT C3 ... >

Esempio di definizione mediante sintassi DTD-XML:

    <!ELEMENT atomo (X,Y,Z) >

    <!ELEMENT atomo (X? | Y? | Z?) >
    <!ELEMENT atomo (X, Y, Z, (A | B | C)) >

Esempio di definizione mediante sintassi Xml-Schema / Schema-Path:

    <xs:element name="record">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="x"/>
                <xs:element name="y"/>
                <xs:element name="z"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

Esempio di definizione mediante sintassi Relax-NG: DA FARE

Analisi delle caratteristiche

I vincoli che caratterizzano il pattern sono l'assenza di testo mescolato ai sotto elementi e la ripetibilità massima pari a 1 di questi ultimi.

Il vincolo della mancanza di testo direttamente inserito nel record è sicuramente un vincolo forte. Semanticamente infatti il record e' solo un contenitore che raggruppa altri dati. Se ci fosse bisogno del testo mescolato ai dati (e non memorizzato tramite un campo aggiuntivo solo per il testo) vorrebbe dire che esisterebbero delle informazioni che non sono uno sotto dato, ma che sono bensi' collegate al gruppo nel suo complesso. In questo caso si esce dalla semantica del record. E' probabile che quello di cui si ha bisogno sia una struttura più flessibile come un content model misto.

La ripetibilita' massima uguale a 1 risulta essere un vincolo altrettanto forte. Il concetto di insieme prevede infatti che esista un solo elemento che gode di certe propietà. Se si fa venire meno questo vincolo il pattern record perde di significato.

Se ci fosse bisogno di raccogliere elementi ripetibili e non ripetibili alternati tra loro, verrebbe da chiedersi se quello che si sta rappresentando sia effettivamente equiparabile ad un insieme. In questo caso probabilmente quello che si sta cercando di mappare è una struttura più complessa oppure un elenco non ben definito nelle sue componenti.

Anche in questi casi risulta quindi evidente che la violazione di vincoli e quindi la rottura della semantica del pattern porta all'uso di un altro pattern quindi ad una struttura semanticamente diversa.

Altri vincoli

Il pattern record non richiede che l'ordine degli elementi sia rilevante. L'ordine infatti non appartiene al concetto di insieme.

La violazione dei vincoli (oltre ad un cambiamento effettivo di pattern, ossia cambiamento in content model misto o tabella) contraddice la semantica stessa del pattern

Caratteristiche:

  • ordine sotto elementi irrilevante
  • opzionalita' dei sotto elementi

Tabella

Descrizione

Una tabella rappresenta un elenco di elementi omogenei tra loro. Questa struttura si presta naturalmetne a rappresentare tutte quelle strutture stratte composte da un insieme di elmenti ripetibili. Una agenda, un listino prezzi, un catalogo aritocli sporitivi ecc.

Definizione

Sono tabelle tutti gli elementi il cui content model prevede una ripetizione di elementi "omogenei" tra loro.

Esempio di definizione mediante DTD:

    <!ELEMENT tabella (A|B|C)+ >
    <!ELEMENT tabella (X|Y|Z)* >

Esempio di definizione mediante Xml-Schema:

    <xs:element name="tabella">
        <xs:complexType>
            <xs:choice maxOccurs="unbounded">
                <xs:element name="x"/>
                <xs:element name="y"/>
                <xs:element name="z"/>
            </xs:choice>
        </xs:complexType>
    </xs:element>   

Esempio di definizione mediante sintassi Relax-NG: DA FARE

La definizione di omogeneità degli elementi è legata al tipo di tabella.

Sicuramente l'omogeneità riguarda prima di tutto il tipo di pattern degli elementi della tabella stessa. Quindi sono ammesse tabelle di marker, tabelle di atomi, tabelle di record, tabelle di tabelle e tabelle di blocchi.

A questo punto, dove gli elemetni sono tutti dello stesso pattern, l'omogeneità è definita secondo la nozione di estensione di tipo di Xml-Schema.

Analisi delle caratteristiche

I vincoli forti che caratterizzano il pattern sono l'assenza di testo, la ripetibilità degli elementi, e l'omogeneità degli elementi.

Per quanto riguarda l'assenza del testo valgono le considerazioni fatte per il pattern record. La ripetibilità è giustificata dal fatto che semanticamente la tabella è un elenco. Un elemento che contiene vari sotto elementi che non si ripetono non può essere considerato un "elenco", è un insieme.

L'omogeneità è un vincolo che cerca di conferire agli elementi dell'elenco stesso una similarità a livello semantico.

Quando si cerca di creare un elenco di elementi disomogenei viene infatti automatico pensare se non sia meglio raggruppare gli elementi in modo differente, magari usando elenchi differensiati.

Basi pensare al cast di un film: seppure tutti i membri del cast ad alto livello facciano parte del cast, nel dettaglio non ha senso mescolare attori ed operatori tecnici nello stesso elenco.

Le ragioni per avere un elenco di elementi disomogenei potrebbero essere la semplicità dello schema.

Questo però sottoindende uno scarso interesse a distinguere effettivamente gli elementi e un maggiore interesse agli elementi in se e non al loro tipo o la loro appartenenza ad un gruppo.

In una rubrica personale di un telefonino si è più interessati ad avere a disposizione i numeri di telefono piuttosto che a sapere se il contatto e' un amico o un parente. Gli elementi sono "contatti" generici. Ma ecco che caduta la necessità di distinguere ci si è ricondotti ad un unico tipo di elemento dell'elenco: il contatto generico.

E infatti l'approccio base dei telefonini è un unica rubrica in cui gli utenti esperti possono impostare dei gruppi per abilitare altre funzionalità complesse.

Contenitore

Descrizione

Un contenitore rappresenta un elenco di elementi disomogenei tra loro. Questa struttura permette di rappresentare quelle collezioni di oggetti in cui gli elementi non sono assimilabili. Per esempio una pagina di testo può essere vista come un collezione di paragrafi, tabelle, elenchi. In questo caso risulta evidente che un blocco di testo che rappresenta un paragrafo non può essere considerato "omogeneo" ad una tabella o ad un elenco puntato. Strutturalmente parlando sono cose diverse.

Definizione

Sono contenitori tutti gli elementi il cui content model prevede una ripetizione di elementi non omogenei tra loro.

Esempio di definizione mediante DTD:

    <!ELEMENT contenitore (A | B | C)* >
    <!ELEMENT A  EMPTY >
    <!ELEMENT B  (#PCDATA) >
    <!ELEMENT C  (...) >

Esempio di definizione mediante Xml-Schema: DA FARE

Esempio di definizione mediante sintassi Relax-NG: DA FARE

Analisi delle caratteristiche

I vincoli sul content model che caratterizzano il pattern contenitore sono l'assenza di testo mescolato agli elementi, la ripetibilità e la disomogeneità degli elementi. Per quanto riguarda l'assenza di testo e la ripetibilità valcono le considerazioni fatte per il pattern tabella.

Il vincolo sulla disomogeneità invece FINIRE

Blocco/Inline

Descrizione

Il pattern blocco e gli elementi inline permettono di modellare strutture in cui compaiono arbitrariamente testo ed elementi. Tipicamente questo accade per documenti testuali in cui è possibile attribuire un preciso significato a porzioni di testo.

Definizione

Sono blocchi tutti gli elementi che ammettono content model misto con elementi inline, atomi e marker, in modo non ricorsivo. Gli elementi inlnie sono elementi che hanno content model misto omogeneo a quello del blocco che li contiene.

Esempio di definizione mediante DTD:

   <!ENTITY % X       "(#PCDATA|E1|E2...|En|A1|A2|...|An|M1|M2|...|Mn)*" >
   <!ELEMENT  blocco  %X; >
   <!ELEMENT  E1      %X; >
   <!ELEMENT  E2      %X; >
   ...
   <!ELEMENT  En      %X; >
   <!ELEMENT  A1      (#PCDATA) >
   <!ELEMENT  A2      (#PCDATA) >
   ...
   <!ELEMENT  An      (#PCDATA) >
   <!ELEMENT  M1      EMPTY >
   <!ELEMENT  M2      EMPTY >
   ...
   <!ELEMENT  Mn      EMPTY >

Esempio di definizione mediante Xml-Schema: DA FARE

Esempio di definizione mediante RelaxNG?: DA FARE

Analisi dei vincoli

Questo è l'unico pattern che prevede il content model misto. Il content model misto risulta quindi essere la caratteristica del blocco e degli elementi inline. In pratica una volta che il documento entra in un contesto dove è presente un content model misto non è più possibile uscirne.

Il vincolo che gli elementi inline abbiano lo stesso content model del blocco è sicuramente un vincolo molto restrittivo. Tuttavia tale vincolo previene dall'usare un blocco come un generico contenitore di testo e quasiasi altro tipo di elemento.

Questo vincolo obbliga necessariamente ad utilizzare altri pattern per gestire casi particolari come ad esempio l'uso di elementi inline non auto inclusivi.

    <!ENTITY % X "(#PCDATA|E1|...|En) *" >
    <!ELEMENT P  %X; >
    <!ELEMENT E1 %X; -(E1)>
    ...
    <!ELEMENT En %X; -(En)>

Il caso più semplice di content model misto (ossia testo alternato a semplici atomi), e il contet model misto puro (senza marker o atomi), invece risultano banalmente dei sotto casi del pattern stesso.

    <!ENTITY % X "(#PCDATA | A | B) *" >
    <!ELEMENT P %X; >
    <!ELEMENT A #PCDATA >
    <!ELEMENT B #PCDATA >

    <!ENTITY % X "(#PCDATA | A | B) *" >
    <!ELEMENT P %X; >
    <!ELEMENT A %X; >
    <!ELEMENT B %X; >

Questo vincolo pero' rende necessario l'uso del contesto additivo e sotrattivo per poter inserire in un content model misto elementi non propriamente testuali.

Per esempio non e' possibile inserire un marker (per esempio immagine HTML), un record (OBJECT html), o una tabella in un content model misto visto che e' evidente che i content model non sarebbero omogenei a quelli degli elementi inline.

Contesto sotrattivo

Descrizione

Alle volte, che nella definizione ricorsiva di un elemento, bisogna impedire che in una determinata parte del sottoalbero la presenza ricorsiva dell'elemento stesso venga proibita. Per esempio non ha senso senso permettere ad un elemento inline <I> che ricorrere al suo interno, visto che vorrebbe dire definire uno stile corsrivo ad una porzione di testo che è già in corsivo. Il contesto sotrattivo serve appunto a definire questi casi.

Definizione

trovare una definizione

Esempio di definizione mediante DTD Sgml:

    <!ELEMENT elemento (... content model ...) -A >
    <!ELEMENT A ... >

Analisi delle caratteristiche

Il contesto sotrattivo non ha vincoli di utilizzo. Può essere applicato ad un qualunque punto del documento senza eccezioni. In caso venga applicato ad un sottoalbero dove è attivo un contesto additivo, il contesto sotrattivo ha la precedenza.

Contesto additivo

Descrizione

Al contrario del contesto additivo, il contesto sotrattivo permette la presenza di un elemento in una qualunque punto di un sotto albero, salvo alcune eccezioni. Questo pattern può essere comodo nel caso in cui si voglia permettere la presenza di un elemento in un documento senza obbligarlo a rispettare una determinata posizione.

Definizione

Definizione: un elemento puo' comparire in un qualunque punto di una sotto parte del documento.

Un elemento puo comparire in un qualunque punto del sottoalbero. Limitazioni alla sua ripetizione sono consentite (DTD-- permette di farlo) .

(La radice del sotto albero verra' chiamato elemento anche 'contenitore')

Esempio di definizione mediante DTD Sgml:

    <!ELEMENT X (A,B,C)  +D >
    <!ELEMENT A (X,Y,Z)     >
    <!ELEMENT B (K,L)+      >
    <!ELEMENT C (T,S)*      >
    <!ELEMENT D #PCADATA    >        

Analisi dei vincoli

Il contesto additivo e' l'unico pattern che combinandosi con gli altri permette di alterare la struttura originaria di un pattern. L'analisi fatta fino a questo momento sui vincoli dei pattern suggerisce che bisogna prestare attenzione all'uso che si fa del contesto additivo.

Un uso indiscriminato potrebbe infatti alterare la struttura (e quindi la semantica) degli elementi. Bisogna quindi analizzare i casi in cui sia effettivamente lecita l'inclusione di un elemento in un altro. Siccome il contesto additivo agisce su un intero sotto albero qui di seguito verrano presentati tutti i casi in cui è lecito o meno che il contesto additivo abbia effetto.

Inserimento di un elemento ad un marker

Il marker prevede l'assenza di content model. Semanticamente serve semplicemente a marcare del contenuto e non per contenere altri elementi. Inserendo un elemento al suo interno si viola il vincolo sulla sua struttura che ne caratterizza la semantica, trasformandolo in un record e quindi cambiando la semantica dell'elemento originale.

Per queste ragioni il contesto additivo non deve avere effetto sui marker.

Inserimento di un elemento in un atomo

Inserimento di un marker dentro un atomo

Un atomo semanticamente rappresenta un valore atomico, non divisibile ne ulteriormente strutturabile.

Anche senza conoscere il significato del marker in questione sorge subito evidente che non avrebbe molto senso inseire un marcatore in mezzo ad un numero. Per definizione infatti e' la presenza del marcatore l'informazione. Risulta quindi strano pensare che un marcatore possa aver senso inserito in mezzo ad un valore atomico.

Ammettiamo comunque che il marcatore sia inserito prima o dopo il valore dell'atomo.

In questo caso risulterebbe che si cerca di fornire all'atomo un significato aggiuntivo rispetto a quello che lui stesso rappresenta. Il che contraddice l'atomicita' stessa dell'informazione contenuta in un atomo. A meno che la presenza del marker non serva a fornire informazioni sull'atomo in quanto elemento XML e non a modificare il valore dell'atomo.

Questa pero' risulta essere una meta informazione. I pattern non sono invece fatti per codificare meta informazioni.

La violazione di un vincolo forte quindi tramite il contesto additivo suggerirebbe l'utilizzo di un pattern diverso.

Conclusione: Il marker all'interno di un atomo tramite un contesto additivo non dovrebbe avere effetto.

Inserimento di un atomo dentro un atomo

Il caso e' analogo alla presenza di un marker dentro un atomo. Con l'aggravante che l'atomo interno contiene a sua volta del contenuto. Ammettere la presenza di un atomo dentro un altro atomo provoca la creazione di un vero e proprio content model misto molto semplice.

Questo rende inconsistente l'assunzione di atomicita' dell'informazione contenuta nell'atomo piu' esterno.

Conclusione: Un atomo all'interno di un atomo tramite un contesto additivo non dovrebbe avere effetto.

Inserimento di un record dentro un atomo
Inserimento di una tabella/contenitore dentro un atomo
Inserimento di una blocco dentro un atomo

Inserimento di un elemento in un record

Inserimento di un marker dentro un record

PREMESSA:

Il marker ha solo il compito di markare del testo quindi, se ad elementi con lo stesso nome ma in punti diversi corrispondono gli stessi elementi (in xml-schema elementi con lo stesso nome possono aver significati diversi), la sua presenza come campo di un record in un caso e come marker in un altro punto e' illogica.

A meno che non si voglia usare il marker per "marcare" gli elementi quando serve e non il loro contenuto (codifica di una meta informazione). Al posto di usare il contentesto additivo che non rende esplicita la relazione tra il marker e l'elemento che lo contiene si potrebbe riforumlare lo schema prevedendo un sotto elemento apposito.

Lo stesso effetto si potrebbe ottenere usando un alttributo 'flag' in tutti gli elementi in cui il maker potrebbe comparire. Rimarebbero solo fuori gli eventuali attributi del marker, ma il problema e' risolvibile usando vari attributi che hanno un determinato prefisso che li accomuna.

- o - o -

Ammettiamo comunque che abbia effetto. I casi sono:

* Il record e' la radice (dove comapre +MARKER): il maker puo' comparire quindi sia come campo del record sia all'interno di eventuali blocchi di testo che magari sono campi del record stesso. In questo caso vale il discorso fatto nella premessa. * Il record e' all'interno del sotto albero: i casi sono: o Il record e' interessato alla presenza del maker: qua si sta di nuovo entranto nel caso della premessa. o Il record non e' interessato: il contesto additivo non dovrebbe avere effetto.

Conclusione: permettere ad un marker di comparire in un record come campo tramite un contesto additivo non viola un vincolo forte del pattern, ma risulta piuttosto illogico. Ancora piu' illogico se il record contiene campi testuali dove puo' comparire il maker. Non si capirebbe piu' se il maker e' legato al contenuto (nel testo) o e' legato ad un elemento (come campo di un record).

Inserimento di un atomo dentro un record

Il record prevede gia' la presenza di ulteriori elementi nel suo content model. Non e' quindi una violazione di un vincolo forte. Tuttavia non e' detto che abbia sempre senso che il contesto additivo abbia effetto.

Analizziamo i vari casi:

* il record e' la radice (ossia e' dove compare +ATOMO): o se si vuole aggiungere l'atomo solo alla radice: si fa prima a definirlo come campo evitando l'effetto in cascata o se si vuole aggiungere l'atomo in un qualunque punto del sotto albero: per il RECORD radice la presenza dell'atomo corrisponde ad un campo aggiuntivo. Sorge pero' il problema della sua presenza anche in altri elementi. Lo stesso elemento ATOMO potrebbe essere aggiunto ad un content model misto. In questo modo verrebbe permesso di utilizzare lo stesso elemento semanticamente in modo diversi: come campo di un record e come contenuto "macarto" se l'atomo compare in mezzo ad un content model misto. * il record e' in mezzo al sotto albero: o se il record e' interessato all'atomo: in pratica nel sotto albero ci potrebbero essere piu' record che potenzialmente potrebbero ritrovarsi l'atomo come campo. Si puo' ottenere lo stesso risultato specificandolo come campo direttamente utilizzando un nome diverso per i record di quel sotto albero. ALtrimenti si ricade nel problema di un atomo usato come campo o come marcatore. o se il record non e' interessato: il contesto additivo non ha senso che abbia effetto sul record interno (effetto collaterale della cascata).

Conclusione: L'aggiunta di un campo ad un record non ne viola la struttura (quindi non viola un vincolo forte).

Tuttavia l'utilizzo puo' comportare delle incomprensioni semantiche se nel record compaiono altri pattern come un content model misto. L'atomo aggiunto potrebbe in alcuni casi essere usato come campo in altri casi come marcatore... lo stesso elemento usato per due scopi diversi in punti diversi.

Inserimento di un record dentro un record
Inserimento di una tabella/contenitore dentro un record
Inserimento di una blocco dentro un record

Inserimento di un elemento in una tabella

Inserimento di un marker dentro una tabella

Valgono considerazioni analoghe a quelle fatte per il pattern RECORD. In oltre c'e' l'aggravante che inserendo un marken in mezzo ad elementi strutturati viene meno il vincolo debole che la tabella debba essere una ripetizione di elementi omogenei.

Se anche i record della tabella fossero dei marker a loro volta, e magari pure omogenei rispetto a quello che si cerca di aggiungere, visto che la tabella non scende ulteriormente in profondita' avrebbe molto piu' senso specificare il marker direttamente nel content model della tabella. Senza usare quindi il contesto additivo.

Conclusione: non ha senso

Inserimento di un atomo dentro una tabella

Valgono considerazioni analoghe a quelle fatte per il caso ATOMO dentro RECORD. Inoltre il pattern TABELLA prevede che tutti i suoi elementi siano omogenei.

Conclusione: se l'elemento incluso e' omogeneo a quello degli altri elementi previsisti dalla tabella l'addizione e' accettabile. Tuttavia si rincorre sempre nei problemi legati alla presenza dello stesso elementi in sotto elementi. Quindi probabilmente andrebbe impedito.

Inserimento di un record dentro una tabella
Inserimento di una tabella/contenitore dentro una tabella
Inserimento di una blocco dentro una tabella

Inserimento di un elemento in un contenitore

Inserimento di un marker dentro un contenitore
Inserimento di un atomo dentro un contenitore
Inserimento di un record dentro un contenitore
Inserimento di una tabella/contenitore dentro un contenitore
Inserimento di una blocco dentro un contenitore

Inserimento di un elemento in un blocco

Inserimento di un marker dentro un blocco

La presenza di un marker dentro ad un blocco non viola il vincolo caratteristico del pattern (presenza di testo mescolato ad elementi).

Per quanto riguarda il vincolo di omogeneita' si puo' dire che al lato pratico in realta' l'omogeneita' viene alterata solo in parte. Ossia solo per quanto riguarda il content model del maker. Infatti tutti i content model degli elementi inline, all'interno di quello specifico blocco, vengono contaminati allo stesso modo:

E' equivalente a:

Inoltre come gia' detto il contesto additivo e' l'unico modo con il quale e' possibile aggiungere elementi che violino l'omogeneita'. E' un meccanismo per fornire una eccezione.

Conclusione: SI, la sua presenza e' accettabile, se non indispensabile in certi casi.

Inserimento di un atomo dentro un blocco

Valgono considerazioni analoghe a quelle fatte per il caso MARKER dentro BLOCCO.

In piu' e' facile vedere che un atomo aggiunto tramite un contesto additivo corrisponde ad un content model misto che prevede anche un elemento corrispondente a quell'atomo su quale sono state imposte alcune restrizioni.

E' equivalente a:

Quindi al lato pratico l'uso del contesto additivo invece dell'equivalente soluzione sotrattiva e' solo una questione di semplicita' nella definizione dello schema.

Inserimento di un record dentro un blocco
Inserimento di una tabella/contenitore dentro un blocco
Inserimento di una blocco dentro un blocco

Inserimento di un elemento in un elemento inline

Inserimento di un marker dentro un elemento inline

Rispetto al caso MARKER dentro BLOCCO valgono quasi le stesse considerazioni.

La differenza e' che andando ad aggiungere un maker solo ad un ben determinato elemento inline l'omogeneita' risulta effettivamente alterata al lato pratico (anche se come gia' detto l'omogeneita' puo' essere vista come un vincolo "debole").

Tuttavia, come gia' detto, il contesto additivo e' l'unico modo con il quale e' possibile aggiungere elementi che violino l'omogeneita'. E' un meccanismo per fornire una eccezione.

Conclusione: SI, la sua presenza e' accettabile, se non indispensabile in certi casi.

Inserimento di un atomo dentro un elemento inline

Il caso dell'uso di un contesto additivo ristretto ad uno degli elementi inline di un blocco e' piu' delicato in quanto e' evidente che non e' possibile trovare una versine equivalente che non utilizzo il contesto additivo.

Questo content model infatti:

---> attenzione P non puo' contenere direttamente ATOMO ---> attenzione B non puo' contenere direttamente ATOMO ---> attenzione C non puo' contenere direttamente ATOMO

Non e' possibile renderlo tramite un contesto sotrattivo:

---> ERRORE questo impedisce di avere ATOMO in tutto il blocco ---> ERRORE questo impedisce di avere x x x x x

Tuttavia come negli altri casi, l'aggiunta di un atomo non viola un vincolo forte, ma solo il vincolo di omogeneita' del content model.

Conclusione: SI, la sua presenza e' accettabile, se non indispensabile in certi casi.

Inserimento di un record dentro un elemento inline
Inserimento di una tabella/contenitore dentro un elemento inline
Inserimento di una blocco dentro un elemento inline

Rispetto al caso MARKER dentro BLOCCO valgono quasi le stesse considerazioni.

La differenza e' che andando ad aggiungere un maker solo ad un ben determinato elemento inline l'omogeneita' risulta effettivamente alterata al lato pratico (anche se come gia' detto l'omogeneita' puo' essere vista come un vincolo "debole").

Tuttavia, come gia' detto, il contesto additivo e' l'unico modo con il quale e' possibile aggiungere elementi che violino l'omogeneita'. E' un meccanismo per fornire una eccezione.

Conclusione: SI, la sua presenza e' accettabile, se non indispensabile in certi casi.

Considerazioni finali sui pattern

Prima di procedere nell'analisi dei pattern rispetto agli altri linguaggi di schema, è necessario chiarire in base a quali principi l'analisi verrà fatta.

E' infatti evidente che i documenti strutturabili mediante i patter sono necessariamente un sottoinsieme di quelli definibili mediante i linguaggi di schema tradizionali. Strumenti comeDTD o Xml-Schema infatti forniscono la possibilità di definire content molto generici.

Completezza

- completezza: un insieme di costrutti (che suppongo sia il tuo caso) è
  completo rispetto ad un insieme di documenti che vuole descrivere se
  ogni documento dell'insieme è descrivibile usando soltanto i costrutti
  ivi contenuti

In generale non esiste una definizione univoca di "completezza". A seconda del contesto di riferimento questo termine assume significati diversi. Quello che noi vogliamo analizzare è la "completezza" in un certo insieme di strutture componibili, i Pattern.

In questo contesto possiamo dare una ragionevolmente definzione di completezza: l'insieme dei pattern è completo rispetto all'insieme di documenti che si vogliono descrivere, se ogni struttura di documento (inteso come le informazioni che contiene) è esprimibile usando soltanto tali pattern.

In poche parole e' possibile trovare un documento strutturato secondo i Pattern che sia "equivalente" a quello originale.

Siccome è evidente che i pattern non permettono di rappresentare ogni possibile tipo di content model, ma solo un sottoinsieme, in questa definizione ammettiamo la possibilità di effettuare alcune operazioni, in particolare la rimozione di vincoli e l'aggiunta di wrapper. DA scrivere da qualche parte cosa è un wrapper

La rimozione di vincoli e l'aggiunta di wrapper non e' detto che sia necessaria, alcune strutture infatti sono mappabili direttamente dai pattern (marker, atomi, alcuni content model misti per esempio), tuttavia in caso di content model complessi, puo' capitare che un content model non sia direttamente mappato. In questi casi occorre effettuare una ristrutturazione che individui una struttura "equivalente" a quella originale.

La scelta dei vincoli da eliminare, o i wrapper da aggiungere, dipende necessariamente dalla semantica che si suppone che abbia un determinato content model.

Completezza rispetto ai linguaggi di schema

I documenti esistenti, e il loro contenuto, sono definiti mediante strutture definibili tramite la sintassi prevista dai normali linguaggi di schema (DTD, Xml-Schema, RelaxNG? ecc).

In genere tramite la sintassi vengono controllati aspetti base come l'opzionalità e la ripetibilità, fino alla definizione di vincoli più soffisticati.

Risulta quindi evidente che per testare la completezza dei pattern è necessario vedere se per ogni possibile struttura definibile mediante i linguaggi di schema sia possibile trovarne una equivalente strutturata mediante i pattern.

Per questa ragione si prenderanno diversi linguaggi di schema (DTD, Xml-Schema, Schema-Path, Dtd++, RelaxNG?) e si cercherà di vedere se per ogni strutture definibile tramite le loro sintassi è possibile trovarne una equivalente strutturata mediante i pattern.

Rapporto tra strutture sintattiche e i Pattern

A tale proposito è bene precisare che, anche se un linguaggio di schema non ha una sintassi che è mappata direttamente un pattern, può capitare che in realtà l'insieme delle istanze possibili sia effettivamente rappresentabile da un pattern.

Per questa ragione, ai fini dell'analisi, una struttura sintattica è rappresentabile mediante i pattern se le istanze che produce sono riconducibili ai pattern.

Minimalita'

Minimalità dell'insieme dei pattern

(termine usato per dimostrare che un qualcosa di "misurabile" è il meglio che puoi ottenere, 
ovvero che non c'è un altro qualcosa che gli è "equivalente" che abbia una misura minore della sua)

- minimalità: il tuo insieme di costrutti è minimale (immagino però
  preservando la completezza) se non puoi togliere nessun costrutto
  mantenendo la completezza

Minimalità delle modifiche allo schema

aggiungere wrapper ovunque puo' essere un cazzata... ma dipende dalle versioni pratiche di un pattern

Minimalità dell'insieme dei documenti validi rispetto alla versione non pattern

quando usiamo i pattern togliamo dei vincoli...

  • questo come si riflette?
  • l'espansione come viene vista a livello pratico?

Correttezza

(termine tipicamente utilizzato che un qualcosa rispetta una specifica data precedentemente)
- correttezza: qua non è chiaro ... dipende rispetto a cosa volete essere corretti, mi dai qualche info in più?

Nel nostro caso quale sarebbe la specifica? Corretto rispetto a cosa?

Devo pronunciarmi, per esempio considerando l'interpretazione fatta da DTD--, che sia corretto assumere che un elemento con solo testo sia un atomo? E che quindi l'informazione sia atomica? e via dicendo? In questo senso giustificare la semantica che diamo agli elementi una volta che sono strutturati mediante i pattern?

Devo pronunciarmi sulla correttezza di una ristrutturazione per adattare un elemento esistente ai pattern?

  • e' corretto togliere vincoli in tutti i casi?
  • e' corretto aggiungere wrapper in tutti i casi?

O forse correttezza rigaurda la bonta' espressiva dei pattern?

  • ad esempio nessuno vieta in un atomo di mettere una lista di nomi separata da virgole. L'informazione non e' piu' atomica. E' corretto dire che un atomo rappresenta una informazione atomica?
  • nessuno vieta di usare solo contenitori rispetto ad una strutturazione piu' omogenea usando le tabelle.

Completezza rispetto a DTD-XML

Il primo linguaggio di schema sui cui verrà effettuata l'analisi è DTD nella sua versione per XML.

Questo linguaggio supporta la definzione di entità, ma questo aspetto è irrilevante ai fini della nostra analisi. Le entità funzionano solo come delle "macro" di comodo per effettuare la sostituzione di testo a tempo di validazione o parsing del documento.

Per quanto riguarda gli altri costrutti sintattici bisogna dimostrare che questi producono elementi che seguono le specifiche dei pattern oppure possono essere ricondotti ad essi mediante ristrutturazioni.

Definizione di attributi

Esempio di DTD:

      <!ATTLIST element-name 
                attribute-name attribute-type default-value
                ...
      >

Allo stato attuale comunque i pattern non riguardano la dichiarazione degli attributi, ogni pattern si limita a permette la presenza di un numero arbitrario di attributi.

Per il momento dunque, questo aspetto non ci interessa.

Definizione di elmenti vuoti

Esempio di DTD:

      <!ELEMENT ElementoVuoto           EMPTY>        

Tutti gli elementi vuoti sono riconducibili al pattern marker per definizione.

Definizione di elmenti contenenti solo testo

Esempio di DTD:

      <!ELEMENT ElementoSoloTesto       (#PCDATA)>     

Tutti gli elementi contenent solo testo sono rinconducibili al pattern atomo per definizione.

Il pattern atomo presuppone che l'informazione memorizzata sia semanticamente atomica per chi utilizza il documento, ossia non divisibile. Questo aspetto non è possibile specificarlo mediante sintassi. Se per esempio memorizziamo il numero di telefono cellulare 3485037972, questo è sempre divisibile in un prefisso che identifica il gestore ed il resto del numero. Ma questa divisione dipende dalla conoscenza e l'uso che si intende fare dell'informazione e quindi del documento. Per esempio, ai fini della memorizzazione in una rubrica, il numero interessa solo nel suo complesso.

Definizione di elmenti contenenti strutturati (contenenti solo sotto-elementi)

La definizione della struttura avviene solo mediante una sintassi minimale che si rifà a quella per le espressioni regolari.

Esempi DTD:

      <!ELEMENT ElementoStrutturato1    (X)>
      <!ELEMENT ElementoStrutturato2    (X)?>      
      <!ELEMENT ElementoStrutturato3    (X)+>      
      <!ELEMENT ElementoStrutturato4    (X)*>
      <!ELEMENT ElementoStrutturato5    (A,B,C)>   
      <!ELEMENT ElementoStrutturato6    (A|B|C)>   
      <!ELEMENT ElementoStrutturato7    ((A|B|C)*,D,E,F)>

Gli elementi base su cui si basa questo approccio sono:

  • Opzionalità
  • Ripetitività
  • Sequenzialità
  • Alternatività

Sicuramente è necessario un costrutto che permetta di esprimere la ripetività.

(a , b , c , d)
(a | b | c | d)

FINIRE

Definizione di elementi contenenti content model misto.

La definzione di content model misto in DTD ammette una sola versione sintattica, ma non pone vincoli sul content model dei sotto elementi:

      <!ELEMENT CMMisto               (#PCDATA|X|Y|Z)*>
      <!ELEMENT X                     (Y)>
      <!ELEMENT Y                     (#PCDATA)>
      <!ELEMENT Z                     (X)+> 

Il content model dell'elemento segue chiaralmente le specifiche del pattern blocco. Tuttavia rimane il problema che i sotto elementi potrebbero non rispettare i vincoli previsti per gli elementi inline.

A questo punto bisogna vedere se è possibile trovare una struttura alternativa che sia equivalente ai fini della rappresentazione delle informazioni.

Per una ristrutturazione migliore bisognerebbe aver chiara il significato. Per esempio potrebbbe aver senso ristrutturare un content model misto che prevede paragrafi e tabelle riassuntive in modo che una tabella non possa stare dentro un paragrafo.

Magari cambiando il pattern dell'elemento in un contenitore di paragrafi e tabelle. Ma la correttezza di questo procedimento dipende dal cosa si sta effettivamente rappresentando, visto che per esempio operando in questo modo non è più possibile avere del testo tra i paragrafi. Cosa che invece prima era possibile.

Da un punto di vista strettamente sintattico, tenendo conto solo della struttura degli elementi, osservando lo schema le uniche due alternative sono:

  • Ristrutturare il content model dei sotto elementi conferendogli un content model misto che rispetti il pattern. Eventualmente utilizzando il contesto sotrattivo per impedire le occorrenze dei sotto elementi non voluti.

      <!ENTITY % cm                   "(#PCDATA|X|Y|Z)*">   
      <!ELEMENT CMMisto               &cm;>
      <!ELEMENT X                     &cm; -(Z,X)>
      <!ELEMENT Y                     &cm;>
      <!ELEMENT Z                     &cm;> 

  • Utilizzare un meccanismo di indirezione. In pratica sostituire tutti gli elementi che non rispettano il pattern con dei marker, e spostare il contenuto informativo in altre strutture in altri punti del documento.

      <!ELEMENT CMMisto               (#PCDATA|Xmark|Y|Zmark)*>
      <!ELEMENT Xmark                 EMPTY>
      <!ELEMENT Y                     (#PCDATA)>
      <!ELEMENT Zmark                 EMPTY> 
      <!ELEMENT X                     (Y)>
      <!ELEMENT Z                     (X)+> 

Entrambe le soluzioni sono sempre applicabili. Quindi è sempre possibile trovare una forma equivalente di conent model misto che rispetta il pattern blocco.

Tuttavia entrambe presentano degli inconvenienti pratici.

In particolare riguardo la prima soluzione:

  • Estende l'insieme dei documenti validi secondo lo schema rispetto alla versinoe originale. Il content model misto infatti permette del testo dove prima non era previsto. metto esempio di istanza?
  • In oltre non per una questione di effetto cascata non è sempre possibile utilizzare il contesto sotrattivo per eliminare le occorrenze dei sotto elementi. metto esempio?
  • Può provocare una crescita degli elementi. Se i sotto elementi sono usati in altri punti del documento ed è necessario mantenere la struttura originale in quei punti, l'unica soluzione è la creazione di elmenti "gemelli" usati solo per i casi di content model misto. metto esempio?

Riguardo la seconda soluzione:

  • può alterare in meglio o in peggio la leggibilità dello schema risultante e/o delle istanze risultanti, dipende dal numero modifiche apportate.
  • comporta l'aggiunta al documento di una sezione apposita destinata a contenere gli elementi che sono soggetti all'indirezione.

metto esempio?

Tuttavia ha il vantaggio che mantiene inalterata la cardinalità dei documenti validi secondo il nuovo schema rispetto allo schema originale. specifico meglio il concetto?

Definizione di elementi contenenti qualunque elemento alternato a testo

Esempio DTD:

      <!ELEMENT ElementoANY          ANY>

Sintatticamente se E1,...,En sono gli elementi definiti nello schema, questa dichiarazione equivale a:

      <!ELEMENT ElementoANY          (#PCDATA|E1|...|En)*>

Valgono quindi le stesse considerazioni fatte per il content model misto, l'unica differenza è che a questo punto probabilmente conviene privilegiare un meccanismo di indirezione, in quanto la modifica del content modegl di tutti gli elementi comporta una modifica totale dello schema.

Conclusioni

Le strutture più semplici definibili con DTD sono direttametne rappresentabili. I content model strutturati sono rappresentabili mediante wrapper e la sostiuzione dell'alternatività con l'opzionalità. I content model misti invece solo in parte risultano strutturabili mediante i pattern, dipende dagli effetti collaterali che si intende sopportare.

  • In alcuni casi è sufficente estendere il content model degli elementi inline. Questo però comporta sempre un aumento dei documenti validi secondo lo schema. Anche utilizzando contesti additivi e sotrattivi non in tutti i casi è possibile limitare questa espansione. Dipende dalla inclusione incrociata degli elementi inline. Il contesto sotrattivo diventa quindi efficace solo in parte.
  • Nel caso si scelga di utilizzare un meccanismo di indirezione il contesto additivo e sotrattivo diventano superflui.

NOTE: probabilmetne più che un contesto sotrattivo sarebbe necessario un sistema per escludere un elemento in caso si verifichi una determinata condizione.

Completezza rispetto a DTD-SGML

Per i DTD nella versione per Sgml valgono tutte le considerazioni fatte precedentemente per i DTD di Xml, ma è necessario fare alcune considerazioni aggiuntive per tener conto anche alcuni costrutti sintattici che erano previsti nella versione originale di DTD.

Tralasciando gli aspetti legati all'omissione di tag di inizio e fine elemento (che in xml non è possibile fare), e scorciatoie per associare a più elementi lo stesso content model, nella versione per Sgml erano previsti 3 ulteriori costrutti sintattici con cui strutturare un content model:

  • Contesto sotrattivo
          <!ELEMENT Elemento - -                    (E1 , E2 , E3)  +(X1|...|Xn) ) >
    
  • Contesto additivo
          <!ELEMENT Elemento - -                    (E1 , E2 , E3)  -(X1|...|Xn) ) >
    
  • Insieme non ordinato di sottoelementi
          <!ELEMENT Elemento - -                    (E1 & E2 & E3)>
    

Contesto sotrattivo

Il contesto sotrattivo di Sgml elimina l'occorenza di un elemento dal content model di un elemento e da tutto il sottoalbero associato. Dal punto di vista dello schema era una scorciatoia sintattica per fornire una eccezione al content model dell'elemento in un determinato contesto. In DTD infatti il content model è strettamente legato al nome dell'elemento, non è possibile definire due elementi omonimi con content model diversi.

In ogni caso questa opzione dei DTD Sgml è mappata direttamente, per definizione, dal pattern contesto sotrattivo.

Contesto Additivo

Il contesto additivo dei DTD Sgml non pone limitazioni alle occorenze degli elementi aggiunti, che anzi possono comparire in un qualunque punto del sotto albero ed in un qualunque numero.

In particolare gli elementi aggiunti possono comparire anche all'interno di elementi solamente testuali (il content model era definito come #PCDATA). Anche in questo caso questa possibilità sintattica era una scorciatoia per cambiare il content degli elementi, in particolare nell'ottica di un loro riutilizzo in vari punti del documento.

Prendiamo per esempio la definizione dell'elemento °head° in Html 4:

      <!ENTITY % head.misc    "SCRIPT|STYLE|META|LINK|OBJECT" -- repeatable head elements -->
      <!ENTITY % head.content "TITLE & BASE?"                                               >
      <!ELEMENT HEAD  O O (%head.content;)  +(%head.misc;) -- document head --              >
      <!ELEMENT TITLE - - (#PCDATA)         -(%head.misc;) -- document title --             >
      <!ELEMENT BASE  - O EMPTY                                                             >

Tramite questa definizione si permette ad elementi come "script" o "link" di comparire più volte dentro head. Questo effetto era ottenibile anche senza utilizzare il contesto additivo. Siccome però DTD non permette di definire il numero di occorrenze massime di un singolo elemento tra vari ripetibile, l'unico modo era getire il tutto mediante una versione molto lunga e quindi meno leggibile.

      <!ENTITY % head.misc    "(SCRIPT|STYLE|META|LINK|OBJECT)*"                            >
      <!ENTITY % head.content "%head.misc; & TITLE & %head.misc; & BASE? & %head.misc;"     >
      <!ELEMENT HEAD O O      (%head.content;)                                              >
      <!ELEMENT TITLE - -     (#PCDATA)                                                     >
      <!ELEMENT BASE  - O      EMPTY                                                        >

E' evidente che nel caso di un content model molto strutturato il contesto additivo presentava un grande vantaggio sintattico. In oltre il contesto additivo era considerato in maniera speciale nel caso di opzionalità dei tag di inzio e fine elemento.

Tuttavia aveva come effetto collaterale anche il content model degli elementi solo testuali. Nell'esempio si è resa necessaria la modifica del content model dell'elemento "title" utilizzando il conteso sotrattivo.

Per tutte le ragioni di cui sopra il pattern contesto additivo prevede delle limitazioni che cercano di preservare la semantica degli elementi su cui il pattern viene applicato.

Detto questo bisogna vedere se esistono content model esprimibili mediante il contesto additivo alla Sgml per i quali non è possibile trovare una versione "ragionevolmente" equivalente strutturata mediante i pattern.

FINIRE

Insieme non ordinato di sottoelementi

FINIRE

Conclusioni

FINIRE

Completezza rispetto a Xml-Schema

tipi separati dagli elementi

il problema dell'omonimia degli elementi

il problema dei tipi anonimi

Xml Schema è un linguaggio di schema standard che introduce una sostanziale differenza rispetto a DTD: i tipi. Un tipo di dato può essere dotato di attributi e content model, a seconda che sia un dato un "simpleType" o un "complexType".

La definizione di tipo può essere separata dalla definizione dell'elemento che ha quel tipo. Questo permette di avere una grande libertà nella strutturazione dello schema. trafiletto su bambole russe ecc?

FINIRE

scorciatoie sintattiche

Esistono in oltre delle caratterostiche puramente sintattiche che permettono il riutilizzo di pezzi dello schema, come ad esempio "group" ed "attributegroup".

Tutte queste funzionalità per la nostra discussione possiamo supporre che non vengano utilizzate, in quanto il banale riutilizzo sintattico di un pezzo dello schema si può assimilare ad un "copia e incolla" nei punti giusti.

Per dimostrare la completezza in questo contesto bisogna dimostrare che per ogni possibile tipo (e quindi content model) può essere trovata una versione equivalente che rispetta i pattern.

Tipi Semplici

I tipi semplici in Xml Schema sono tipi che prevedono l'assenza di attributi e il contenuto informativo è rappresentato da solo testo.

Tipi Complessi

I tipi complessi sono tipi che possono ammettere sia attributi sia un content model dotato di sotto elementi strutturati secondo le possibilità fornite dalla sintassi di Xml Schema.

Attributi

La definizione di attributi è equivalente a quella di DTD. DA FINIRE

Content model

A questo punto rimane da considerae il content model che può essere definito in un tipo complesso.

DA FINIRE

Sostituzioni

DA FINIRE

Completezza rispetto a Schema-Path

SchemaPath è una estensione minimale di XmlSchema? per la gestione di co-constraints. Dal punto di vista puramente sintattico introduce un solo nuovo elemento ed un tipo predefinito:

  • error dire quali sono gli elementi
  • elemento

A questo punto bisogna stabilire se anche per le strutture definibili mediante questi nuovi costrutti è possibile trovare una versione equivalente strutturata mediante i pattern.

FINIRE

tipo error

FINIRE

tipi alternativi

FINIRE

Completezza rispetto a DTD++

Completezza rispetto a Relax-NG

MATARIALE VARIO

Probabilmente la correttezza forse riguarda il fatto di utilizzare la minimalita' per fare le scelte. e riguarda la bonta' o meno di fare certe scelte quando si cerca di mappare un elmento con un Pattern. Per esempio:

    <!ELEMENT elemento (A,B,C,(A?|B?|C?)) >

Le possibili istanze di questo elemento possono essere o un record o al massimo mappabili tramite una tabella.

    (A,B,C)
    (A,B,C,A)
    (A,B,C,B)
    (A,B,C,C)

Quello che viene da pensare e' che A,B,C siano dei valori necessari di cui e' possibile indicare un secondo valore.

Soluzione 1:

    <!ELEMENT elemento (A+,B+,C+)) > 
    Quindi:
    <!ELEMENT elemento (WA,WB,WC)) > 

Soluzione 2:

    <!ELEMENT elemento (A,B,C)+ ) > aggiungdo poi un limite massimo e minimo alle occorenze di a,b,c

ATTENZIONE: Queste soluzioni non preservano l'ordine che era caratteristico della versione originale.

Soluzione 3:

    <!ELEMENT elemento (A,B,C,additional) >

Forse utilizzando un wrapper la soluzione e' piu' corretta. Anche se questo riduce "additional" ad un recordo di massimo un solo elemento.

Dal punto di vista della minimalita'... se non si usa sintassi aggiuntiva per limitare le occorenze l'aggiunta del wrapper dell'ultimo caso garantisce documenti molto piu' fedeli all'originale. In quanto "additional" e' un record e come tale al massimo uno potrebbe indicare sia A,B,C. Nelle due soluzioni precedenti invece se non si usa sintassi aggiuntiva

-- GuidoBilli - 16 Jan 2007

  • Set ALLOWTOPICVIEW =
  • Set ALLOWTOPICCHANGE =

to top

You are here: Tesi > ArgomentiDiTesi > TesiDTDandPattern > CapitoloContributoTeorico

to top

Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Fabio's Wiki? Send feedback