diff --git a/02 - XML.md b/02 - XML.md index 71d7d42..db5ab2c 100644 --- a/02 - XML.md +++ b/02 - XML.md @@ -735,7 +735,56 @@ Da notare che ``che `holder`finisce per un `/`quindi è un em ![23](immagini/lezione-02/23.png) -## Come viene processato un documento XML? + + + + +**Possibile soluzione:** + +Struttura base + + + +![28](immagini/lezione-02/28.png) + +In questa soluzione si ha una root la quale contiene due elementi: `group`e `host` + +Nel `group`si ha sia un `id` e una descrizione che può essere opzionale. Nel `host` si ha un `id`"che viene puntato" dal `id` del `group`. Ossia `group` (del host) contiene un link a `group id`. Come si può vedere nella figura sottostante:![29](immagini/lezione-02/29.png) + + + +Inoltre ci sono anche altre informazioni come ad esempio la scheda MAC che deve essere pari a 1 e cosi via. + +L'interfaccia dell host può essere sia 0 che più 1,2,3, ecc... questo perché alcuni pc potrebbero non avere di interfaccia. + +Si poteva anche (come possibile soluzione con i suoi pro e contro) togliere interfacia dell host e metter i suoi elementi dentro a host. + +Nel DTD c'è una limitazione ossia che se nel documento ci sono die ID come in questo caso (uni per il gruppo e l'altro per l'host ) ossia per il linguaggio DTD c'è un unico scope per il `unique ID` per tutto il documento. **Ossia non è possibile avere un ID del host uguale ad un ID del gruppo.** Quindi se si usa un validatore per DTD andrà a confrontare questi due ID come se fosse un unico ID. + +La cosa si ripercuote sul `group attribute`ossia essendo che va a puntare da qualche parte, il validatore non sa se deve puntare sul ID del host o del gruppo quindi per lui è tutto corretto se punta in uno dei due. +Questa è una limitazione del linguagio DTD. Tuttavia si possono fare ulteriori test usando altri strumenti come "schema".![30](immagini/lezione-02/30.png) + + + + + +**Soluzione in DTD** + +Nel `network`si ha sia il `group`che `host`i quali devono essere uno dietro l'altro tuttavia nessuno ci vieta di scrivere: `(group|host)*`quindi si avrebbe o un host o un gruppo con una multiplicità pari a 0 fino a n. + +Si può vedere che qui c'è un'incongruenza con quello visto prima ossia `interface` del host ha una multiplicità indicata con il `+`mentre prima era indicata con `*`. + +NMTOKEN non è un token unico ma c'è ne potrebbero essere altri nel documento uguali. + +Se si volesse che ci fosse un solo unico indirizzo Ip per ogni macchina allora si dovrebbe insirire un nuovo vincolo nel DTD. Tuttavia ID per i DTD iniziano con una lettera quindi si avrebbe dei problemi. + + + +![31](immagini/lezione-02/31.png) + + + +**Come viene processato un documento XML?** La seguente figura mostra lo schema _generico_ di elaborazione di un documento XML: @@ -788,13 +837,30 @@ In questo caso non ci sono particolari informazioni per la visualizazione (esemp Tuttavia si vede come c'è sia il DTD del documento che il documento in se. + + + ![05](immagini/lezione-02/05.png) + + + + + +Ripartendo da questa figura si può dire che il XML processor legge e scrive i documenti XML e si prende cura della validazione del documento. Di solito questo processore è configurabile e quindi si può dire quello che si vuole ossia se il documento è "well formed" o se è valido. + +Le applicazioni di solito leggono/scrivono le informazioni del XML processor attraverso una API. +Inoltre l'applicazione può dare degli ordine al processore XML come ad esempio se deve leggere e cosi via. + +L'applicazione può prendere le informazioni che butta fuori il processore attraverso l'API. + +**Si hanno degli standard: SAX, DOM e StAX** + #### SAX parsing SAX è un'API di basso livello il cui principale punto di forza è l'efficienza. ![](immagini/lezione-02/06.png) - Quando un documento viene parsato usando SAX, una serie di eventi vengono generati e passati all'applicazione tramite l'utilizzo di callback handlers che implementano l'handler delle API SAX. Gli eventi generati sono di livello molto basso e devono essere gestiti dallo sviluppatore che, inoltre, deve mantenere le informazioni necessarie durante il processo di parsing. Oltre ad un utilizzo piuttosto complicato, SAX soffre di due limitazioni di rilievo: non può modificare il documento che sta elaborando e può procedere alla lettura solo "in avanti": non può tornare indietro. Quindi, quello che è stato letto è perso e non è possibile recuperarlo. + Quando un documento viene parsato usando SAX, una serie di eventi vengono generati e passati all'applicazione tramite l'utilizzo di callback handlers che implementano l'handler delle API SAX. Gli eventi generati sono di livello molto basso e devono essere gestiti dallo sviluppatore che, inoltre, deve mantenere le informazioni necessarie durante il processo di parsing. Oltre ad un utilizzo piuttosto complicato, SAX soffre di due limitazioni di rilievo: non può modificare il documento che sta elaborando e può procedere alla lettura solo "in avanti": non può tornare indietro. Quindi, quello che è stato letto è perso e non è possibile recuperarlo e si dice `push the data to the application` . In questo caso è il processore XML che guida l'applicazione. L'applicazione mette a disposizione alcune API che vengon chiamate al generare di un evento dal processore XML. #### DOM parsing @@ -804,14 +870,24 @@ DOM, invece, ha come punto di forza la semplicità d'utilizzo. Una volta ricevuto il documento, il parser si occupa di costruire un albero di oggetti che rappresentano il contenuto e l'organizzazione dei dati contenuti. In questo caso l'albero esiste in memoria e l'applicazione può attraversarlo e modificarlo in ogni suo punto. Ovviamente il prezzo da pagare è il costo di computazione iniziale per la costruzione dell'albero ed il costo di memoria. +Di solito si dice `pull the data to the application` In questo caso è l'applicazione che guida il processore xml. + +Esso viene usato per le pagine HTML. + + + +Il DOM è molto flessibile mentre il SAX è molto più veloce. Perché il DOM deve prendere l'informazione e memorizzarla in memoria, mentre il SAX non appena arriva l'informazione la può subito farci il parsing. Quindi il tempo di latenza nel SAX è molto più piccolo rispetto al DOM. Inoltre nel DOM poiché si può navigare nell'albero si ha bisogno di più tempo per fare tutte queste operazioni che non si hanno nel SAX. + #### StAX parsing -StAX è un pull parser. +StAX è un pull parser e sta in mezzo ai due precedenti (DOM e SAX). ![](immagini/lezione-02/08.png) A differenza di SAX, che è un push parser, non riceve passivamente i segnali inviati all'handler per elaborarli, ma è l'utente a controllare il flusso degli eventi. Questo significa che il client richiede (pull) i dati XML quando ne ha bisogno e nel momento in cui può gestirli, a differenza del modello push, dove è il parser a inviare i dati non appena li ha disponibili a prescindere che l'utente ne abbia bisogno o sia in grado di elaborarli. Le librerie pull parsing sono molto può semplici delle push parsing e questo permette di semplificare il lavoro dei programmatori, anche per documenti molto complessi. Inoltre è bidirezionale, nel senso che oltre a leggere dati XML è anche in grado di produrli. Rimane il limite di poter procedere solo "in avanti" nell'elaborazione del documento XML. +Riassumendo si può dire che è simile all SAX per il pull ma è carraterizato dall'events base ossia come il DOM. Quindi il StAX può sia leggere che scrivere e non si ha nella memoria un albero come nel DOM. Quindi quando si leggono i dati si comporta similmente al SAX. Inolte è l'applicazione che chiede il prossimo "pezzo" di dato al processore XML. + ## Document Object Model (DOM) @@ -889,11 +965,13 @@ consiste in 6 specifiche differenti: ### L'elemento <\> +Queste interface vengono implementate dai vari DOM + ![](immagini/lezione-02/10.png) ![](immagini/lezione-02/11.png) - +Si hanno tante interface a seconda di quello che si deve fare ad esempio per i commenti oppure per un elemento. ## Semplice API per XML (SAX) @@ -943,14 +1021,18 @@ StAX è comodo in quanto permette sia di **leggere** sia di **scrivere** dal/sul +Ad esempio per l'accesso hai dati è molto meno facile nel DOM perché si ha il completto cotrollo dei dati: si può navigare nell'albero, si può decidere che dati si vuole prendere e quali dati non si vuole prendere e cosi via. + + + ## Presentazione di un documento XML La _presentazione_ (ovvero la _grafica_ detto beceramente) di un documento XML viene specificata separatamente utilizzando uno dei due modi: -- CSS: Cascading Style Sheet -- EXtensible Stylesheel Language (XLS) +- CSS: Cascading Style Sheet (come per HTML). CSS per XML è un pò complicato essendo che i tags sono personalizabili. +- EXtensible Stylesheel Language (XSL) è un XML application ossia se stesso è un XML application. Esso (XSL) non solamente definisce gli elementi che si possono avere nel XML ma anche include -Gli stili di rpesentazione vengono scritti su un documento a parte e poi inclusi all'inizio del file XML, ad esempio se ho due file di stile `mystyle.css` e `mystyle.xsl`potrò includerli nel seguente modo: +Gli stili di presentazione vengono scritti su un documento a parte e poi inclusi all'inizio del file XML, ad esempio se ho due file di stile `mystyle.css` e `mystyle.xsl`potrò includerli nel seguente modo: ``` @@ -978,6 +1060,14 @@ XSL è certamente uno dei più importanti linguaggi standard del W3C. Esso risul ![](immagini/lezione-02/13.png) +Nel primo esempio si hanno due file i quali passano per il XSLT processor e processa i documenti in altri documenti che in questo caso in un html che può essere visto attraverso un browser. E associato al html ci può essere un css file. + + + +Nel secondo caso si ha sempre un processore XSLT che fornisce in output un file che deve essere processato da qualche cosa (che nel disegno è rapresentato da un ovale vuoto) il quale fornisce in output il file desiderato in questo caso un .pdf. + + + ## XSLT L'XSLT (eXtensible Stylesheet Language Transformations) è il linguaggio di trasformazione dell'XML, diventato uno standard web con una direttiva (Recommendation) W3C del 16 novembre 1999. @@ -988,29 +1078,67 @@ Ci possono essere due casi specifici di trasformazione: da un documento XML a un Per generare una trasformazione XSLT occorrono due file: il documento da trasformare (in XML) ed un documento contenente il foglio di stile XSL, che fornisce la semantica per la trasformazione. Il foglio di stile XSLT vede un documento XML come una serie di nodi strutturati ad albero. È formato da un insieme di modelli (template) che contengono le regole di trasformazione dei tag del documento XML. Nella sintassi XSL, i template sono elementi, a ciascuno dei quali corrisponde l'attributo match, associato al nodo che verrà trasformato. In termini strutturali quindi il foglio di stile XSL specifica la trasformazione di un albero di nodi in un altro albero di nodi. -È possibile anche aggiungere al documento trasformato elementi completamente nuovi o non prendere in considerazione determinati elementi del documento origine, riordinare gli elementi, fare elaborazioni in base al risultato di determinate condizioni, ecc. +Più in particolare in ingresso si ha un .xml file (1), il quale passa attraverso un parser XML il quale crea un "DOM TREE" (2). Inseguito c'è un motore (3) per applicare le regole di trasformazione e trasforma l'albero originale in qualcos'altro (4). Per poi essere serializato in un documento (5). + + + +È possibile anche aggiungere al documento trasformato elementi completamente nuovi o non prendere in considerazione determinati elementi del documento origine, estrapolare informazioni, riordinare gli elementi, fare elaborazioni in base al risultato di determinate condizioni, ecc. ![](immagini/lezione-02/14.png) ### Esempio di XSLT ```xml - - -
-

My Articles

- - - - - - - - - -
Title
-

AltStyle によって変換されたページ (->オリジナル) /

-
-
+01 +02 +03 +04 +05 +06

My Articles

+07 +08 +09 +10 +11 +12 +13 +14 +15 +16
Title
+17 +18
+19
``` + + + + +- ` `denominato come `name space`. Ossia quando al root combaccia allora html viene generato. Mentre gli altri tags vengono usati all'interno del root elements. +- la radice del documento è ``. +- In questo esempio c'è una singola regola cha va dalla riga 03 alla riga 18 denominata `template`. +- `match="/"` per il matching della regola. +- Dalla riga 04 alla riga 17 si ha il template della pagina htlm. All'interno di queste righe si hanno altri tags che specificano altre cose per XLST processor. Ad esempio alla riga 11 si ha: + `` che significa che per ogni `article` che si trova sotto a `bibliography` viene applicata una regola. Il tutto si trova dentro ad una tabella come viene indicato alla riga 07. Quindi se si ha una tabella nel file di input le righe veranno generate automaticamente insieme alla seguente istruzione: + `` + + + +**Esempio**: + +Prodotto finale: + + ![32](immagini/lezione-02/32.png) + + + +Codice che genera il prodotto finale: + + ![33](immagini/lezione-02/33.png) + +1) Dove viene "linkato" il file stylesheet. Se si rimuove questa riga si ottine un prodotto finale senza stile. + +Quindi si vede come questo file passa attraverso XSLT file (visto prima) e come a questo file vengano tolte delle informazioni e vengono mantenute altre. Più in particolare dalla tabella viene mantenuto solo il titolo. + + + diff --git a/03 - XML Schema.md b/03 - XML Schema.md index 79525ca..7235111 100644 --- a/03 - XML Schema.md +++ b/03 - XML Schema.md @@ -2,6 +2,8 @@ In questa lezione vedremo gli **XML schema** e i **namespace XML**. +XML schema è un alternativa al DTD per specificare un linguaggio HTML o applicazione HTML. E esso è molto più potente del DTD. + ## XML Namespace @@ -45,6 +47,8 @@ Ciascun **namespace** è un insieme di nomi univocamente definiti utilizzando un +I documenti `unnamed namespace`sono quei documenti usati fino adesso. + ### Qualified names Utilizzare nei nostri documenti XML direttamente ciascun **IRI** è davvero scomodo, si pensi a scrivere di fianco a ciascun *tagname* il relativo *IRI* che lo distingue: @@ -59,6 +63,22 @@ Un *qualified name* può assumere due forme: 2. **forma implicita** per esempio `tagname`, cioè il namespace non viene specificato e quindi si utilizza l'*unnamed namespace* (che sarebbe a dire il quarto senza nome nella figura sopra). +In altre parole si preferisce creare una dichiarazione a cui è associatato il nome della URL. Ossia si scrive la URL una sola volta nella dichiarazione e poi si usa questa dichiarazione del documento. + +In altre parole si usa un `small name` al posto della URL. E si crea una dichiacazione che è associatata al `short name` con la URL. Ossia si scrive una sola volta la URL nella dichiarazione e poi si usa il `short name` nel documento. + +Quindi va da se che `short name`viene denominato come: +`symbolic local identifier`. + +**Ad esempio si potrebbe avere:** + +`ns1:letter` dove `ns1` è l'identificatore locale e `letter` è i nome. E vengono seperati dal "colon (`:`)". + +Idem per : `ns2:letter` e per `ns3:letter` ma hanno un qualificatore diverso. E quindi sono diversi. + +Se invece se si ha `letter` e quindi senza un prefisso allora il nome appartiene al default namespace. +Ovviamente nel documento si ha un defualt namespace che verrà poi associato a quel nome. + ### Dichiarazione dei namespace @@ -75,31 +95,33 @@ Entrambe le forme comunque hanno un **nome** e un **valore**, facciamo due esemp dove: - il *nome* (implicito) è **xmlns** - il *valore* è **http://www.w3c.org** + - In questo caso si é dichiarato il default namespace perché non si è usato il `:`. 2. `
...
` dove: - i *nomi* (forma prefissa) sono **xmlns:ns1** e **xmlns:ns2** - i *valori* sono **http://www.alpha.beta** e **http://www.alpha.gamma** + - In questo caso si è associato la URL con il symbolic name. Quindi si è associato `ns1` e `ns2` e quindi si potrà usare nel documento `ns1:letter` come visto prima. ### Esempio pratico ```xml - - - - - - A book list - - - - A funny picture - - - - +01 +02 +03 +04 +05 +06 A book list +07 +08 +09 +10 A funny picture +11 +12 +13 +14 ``` dove: @@ -126,11 +148,13 @@ dove: indicano elementi specificati nel name space **image** ovvero in **http://www.polito.it/xml/image** +- alle riga 03 si dichiarano i default namespace e `image` namespace, + ## XML Schema -La traduzione ~~schemi XML~~ è sbagliata, poichè **XML Schema** è un nome proprio che indica un linguaggio di descrizione del contenuto di un file XML, l'unico che finora abbia raggiunto la validazione ufficiale del W3C (la 1.1). +La traduzione ~~schemi XML~~ è sbagliata, poichè **XML Schema** è un nome proprio che indica un linguaggio di descrizione del contenuto di un file XML, l'unico che finora abbia raggiunto la validazione ufficiale del W3C (la 1.1). In realtà ci sono vari linguaggio XML schema tuttavia in questo corso ne studieremmo uno solo. Come tutti i linguaggi di descrizione del contenuto XML, il suo scopo è delineare quali elementi sono permessi, quali tipi di dati sono ad essi associati e quale relazione gerarchica hanno fra loro gli elementi contenuti in un file XML. @@ -140,25 +164,47 @@ Lo XML Schema permette inoltre l'estrazione da un file XML, o meglio una visione +Gli standard sono: + +• Reference Namespace: http://www.w3.org/2001/XMLSchema + +• Reference DTD (non-normative): +"-//W3C//DTD XMLSCHEMA 200102//EN""http://www.w3.org/2001/XMLSchema.dtd" + +• Reference schema (auto-description): http://www.w3.org/2001/XMLSchema.xsd +Questo è "il reference". + +• Tutorial (reference for study): +– XML Schema Part 0: Primer (W3C Recommendation) + + + + + ### Struttura base di un XML Schema La struttura base che permette di produrre un **XML Schema** è la seguente: ```xml - +02 +03 Annotazioni... +04 Elementi glocabli e dichiarazioni di attributi... +05 Tipi (dati/modelli) e definizioni di gruppi... - Annotazioni... - Elementi glocabli e dichiarazioni di attributi... - Tiupi (dati/modelli) e definizioni di gruppi... - - +06 ``` dove: -- *schemaName* è un nome scelto arbitrariamente, +- 01 *schema* è per il linguaggio scelto che in questo caso è *schema*, - *xsd* è un acronimo che sta per ***X**ml **S**chema **D**efinition*. +- xmlns:xsd = "http://www.w3.org/2001/XMLSchema" sarebbbe la dichiarazione del namespace. In questo caso il nome associato alla URL è xsd +- Dentro alla root element possiamo trovare in qualsiasi ordine: + - annotazioni (che sono delle annotazioni) + - elementi globali e dichiarazioni di attributi che sono simili agli attributi e elementi che si hanno nei DTD. Gli elementi globali sono accessibili da tutto il documento e si ha la possibilità di referenziare a questi elementi. Ad esempio si può assegnare un nome e "riprenderlo" attraverso il suo nome + - tipo (dati/modelli) e definizioni di gruppo. In questo caso è possibile creare la sua propria definizione simile a quello che si fa nei linguaggi di programmazione e di assegnare il nome a quel tipo. La defizione di gruppo possono essere considerate delle macro definizioni e definisce i gruppi di dichiarazioni o di definizione che possiamo referenziare dal documento stesso. @@ -168,21 +214,59 @@ dove: +- Nelle annotazioni ci sono vari elementi di vario tipo che sono differenti dalla "annotation" e più in particoalre una "documentation" è qualche cosa che è leggibile da un essere umano. + +- `` è una dichiarazione globale. Esso ha un nome `purchaseOrder`e un tipo `PurchaseOrderType` . Il type include il "content model" e l'attributo dell'elemento che ha. + + - In verde si vede come `PurchaseOrderType` è collegato a`PurchaseOrderType` : + - 1 è il "content model". Si può notare che `shipto` o come `billto` non è referenziabile in tutto in il documento. + - 3 è l'attributo dell'elemento. ![08](immagini/lezione-03/08.png) + - 4 ->si può tuttavia referenciare grazie all'elemento globale `name="comment"`. + - Inoltre gli elementi globali appaoiono nella root del documento. + + + + + ### Tipi +I tipi sono simile ai linguaggi di programazione l'unica differenza è che nel XML Schema si ha una rapresentazione sotto forma di caratteri mentre nei linguaggi di programmazione si usa la rapresentazione binaria. + +Se ad esempio si ha in integer in XML allora si hanno più modi per scriverlo: +`1` oppure `01`. + +Quindi nel linguaggio a caratteri si hanno molti modi per rapresentare qualchecosa. Ovviamente se si vuole fare dei confronti si dovranno fare in modo tale che tutto regga. Questa è in pratica l'unica differenza che c'è. + +Non si ha delle cose molto stringenti ma si hanno delle regole sintattiche come ad esempio un intero è una sequenza di stringhe. + +Si da ad un tipo un nome e un valore (stringa di caratteri). + +I tipi semplici contengono un markup mentre quelli complicati non lo contengono. + +I tipi complessi descrivono il tipo degli elementi. Più in dettaglio dentro i tipi complessi si hanno gli atributi degli elementi e il contenuto dell'elemento. +Ad esempio un elemento può essere (come visto prima): +`` +Il quale ha sia il suo nome `purchaseOrder` e il suo tipo `PurchaserOrderType`. Esso quindi contiene il suo "content model" e possibilmente il suo attributo. + +Il "complex type" o tipi complessi sono più generali rispetto al tipo semplice. Ossia il tipo semplice è un caso particolare del tipo complesso. + Le seguenti sono regole formali che definiscono i cosiddetti **tipi** di un XML Schema: -> I tipi sono strutturati secondo uno schema gerarchico. +> I tipi sono strutturati secondo uno schema gerarchico simile a quello che si ha nei programmi ad oggetti. Tuttavia invece di avere il concetto dell'eredità, si hanno altri concetti. I quali sono chiamati **restriction** e **extension**. + +**Restriction** è una stringa (visto che i tipi sono stringhe alla fine) che è più "ristretta" rispetto all'originale. Ossia la stringa amessa è un sotto-insieme della stringa-originale. Come si vede dalla freccia blu in cui sia ha un riferimento gerarchico in blu.![09](immagini/lezione-03/09.png) -> Il tipo radice viene chiamato `anyType`. +> Il tipo radice viene chiamato `anyType`. Corrisponde al DTD al `any`. Ossia ogni stringa combacia con `anyType`. Ogni altra stringa è un sottoinsieme del `anyType` . -> La sotto gerarchia di un *tipo semplice* ha sempre come radice il tipo `anySimpleType`. + + +> La sotto gerarchia di un *tipo semplice* ha sempre come radice il tipo `anySimpleType`. Sarebbe la radice degli elementi semplici. Quindi si potrebbe dire che il graffo è diviso in due parti: a destra ci sono gli elementi semplici mentre a sinistra ci sono gli elementi complicati. @@ -212,6 +296,16 @@ La seguente figura rappresenta la gerarchia di alcuni tipi predefiniti. +Si può vedere dalla figura sia tipi interi che tipi decimali (1) e cosi via. + +Nel DTD si aveva il token (2) come qui che è sotto a stringa perché il token è una singola parola senza spazi. + +Per essere compatibile con le tecnologie passate si sono inserite i loro tipi (3). + +C'è anche la data (3). + +Inoltre per i caratteri ci sono le varie rapresentazoini tra cui il base64Binary e cosi via. Come pure `anyURI`. + ### Restricion, List e Union Ora vediamo come possiamo definirei nuovi tipi in modo esplicito utilizzando *restriction*, *list* e *union*. @@ -235,15 +329,19 @@ La sintassi da utilizzare è la seguente: Per esempio: ```XML - - - - - - +01 +02 +03 +04 +05 +06 ``` -**Sinossi**: ho creato un nuovo tipo esplicitamente (utilizzando la *restriction*). Il nuovo tipo si chiama **myInteger** ed eredita dal tipo predefinito **integer**. Il nuovo tipo *myInteger* può assumere solo i valori da *10000* a *99999*. +**Sinossi**: ho creato un nuovo tipo esplicitamente (utilizzando la *restriction*). Il nuovo tipo si chiama **myInteger** ed eredita dal tipo predefinito **integer**. Il nuovo tipo *myInteger* può assumere solo i valori da *10000* a *99999*. + +La "Facet" sono i vincoli. + +Se si mettono le righe 01 e 06 allora la definizione è referenziabile in tutto il documento. @@ -267,7 +365,7 @@ Esempio: ``` -**Sinossi**: ho appena definitio un nuovo tipo di nome **ListOfMyIntType** che rappresenta una sequenza di valori tutti di tipo **myInteger**, secondo la definizione fatta prima, ciascuno diu questi valori sono compresi tra *10000* e *99999*. +**Sinossi**: ho appena definitio un nuovo tipo di nome **ListOfMyIntType** che rappresenta una sequenza di valori tutti di tipo **myInteger** (che è stato definito prima), secondo la definizione fatta prima, ciascuno di questi valori sono compresi tra *10000* e *99999*. @@ -293,10 +391,33 @@ Esempio: ``` -**Sinossi**: qui è stato definito un nuovo tipo di nome **IntegerAndDates** il quale è una sequenza di due semplici valori, nell'ordine: un **myInteger** e un **date**. +**Sinossi**: qui è stato definito un nuovo tipo di nome **IntegerAndDates** il quale è una sequenza di due semplici valori mixati come si vuole. + +#### 3. Extension + +E' per definire un nuovo tipo partendo da un'altro che esiste già. Ad esempio si può partire da un semplice elemento per definire un altro elemento (freccia verda). ![09](immagini/lezione-03/09.png) + + +1)Definizione dell'elemento. +2) Definzione dell'attributo. + +1)+2)=> è la defizione di un nuovo elemento complesso. + +![10](immagini/lezione-03/10.png) + + + + + +### Definizione dei tipi complessi + +Si hanno diverse possibilità come ad esempio per mezzo di una diretta costruzione (come visto prima). + +Oppure si può usare la "derivazione" con la "restriction" oppure con l "extensio". + ### Il Facet dei tipi di dati I tipi semplici (sia incorporati che derivati) presentano dei **facet**. Il facet è un singolo aspetto di definizione che contribuisce a determinare l'insieme di valori di un tipo semplice. Ad esempio, **length**, **minInclusive** e **maxInclusive** sono facet per i tipi di dati incorporati. Tutti i facet per un tipo semplice definiscono l'**insieme di valori validi** per quel determinato tipo semplice. @@ -309,7 +430,7 @@ I facet più comuni e importanti sono i seguenti: - lenght - minLenght, maxLenght -- pattern +- pattern ossia la possibilità di usare delle espressioni regolari. - enumeration - maxExclusive, maxInclusive, minExclusive, minInclusive - totalDigits, fractionDigits @@ -342,9 +463,12 @@ La dichiarazione degli attributi avviene secondo la seguente sintassi: #### Esempio 1. `` - questo attributo è obbligatorio e non può essere omesso, + + questo attributo è obbligatorio e non può essere omesso. Il tipo è un intero. + 2. `` - questo attributo, + questo attributo è fisso. Il tipo è una stringa. + 3. `` in questo caso non è obbligatorio specificare l'attributo, se non lo farò allora verrà definito automaticamente con un valore di default pari a *0*. @@ -369,7 +493,7 @@ La *frequenza* e l'*opzionalità* possono essere specificate utilizzando i segue ... ``` - +Con il termine `unbounded` si intende che non c'è un limite superiore a questo elemento. @@ -381,7 +505,13 @@ I tipi complessi sono definiti mediante l'elemento **complexType** e in genere c ![](immagini/lezione-03/05.png) +Si parte dall'alto con il `complexType` e dentro ad esso (in modo agreggato) ci sono gli elementi dell'attributo `attribute`. +Mentre il `Top-level Content model` può essere o un `Content model` oppure `all` . + +Un `content model`può essere un `choice` o una `sequence`. Tuttavia sia `choice` sia `sequence` contengono `Content model` in termini di `choise` o `sequence` . + +In altre parole il graffo serve per sapere cosa sia lecito fare e cosa non sia lecito fare. Ovviamente nella realtà sarebbe molto più complicato. #### Esempio 1 @@ -407,7 +537,7 @@ Un elemento dichiarato con il tipo usAddress risulterebbe simile al seguente: ``` - +La keyword `sequence` significa che gli elementi devono comparire con quel ordine. #### Esempio 2 @@ -453,6 +583,22 @@ Questo è ancora un terzo esempio in cui viene definito un tipo complesso: + ![11](immagini/lezione-03/11.png) + +1) è il `content model` ed è una sequenza di `singleUSAddress` (2) + +3) commento che è referenziato nella dichiarazione globale. Da notare come `minOccours` è pari a zero quindi essendo che il valore di default è zero e il valore minimo è zero, quindi si ha che il valore minimo è zero e che il valore massimo è 1. + +4)Items è associato al tipo di attributo. Quindi è un `Items` definito a livello globale che è referenziato qui. + +Quindi dentro a `PurchaseOrderType` si vuole avere un indirizzo, un commento (3) e gli items. + +5) è il "complex type definition" che in questo caso è anonimo. E dentro si hanno una sequenza di 3 elementi che caratterizzano l'indirizzo. I primi due sono due stringhe l'ultimo è un decimale. + +Sotto invece si ha `country` che è un `MNTOKEN`, il quale in questo caso è fisso ed è `US`. + +Inoltre si può notare come non ci sono dei vincoli (min, max) e quindi di default si ha 1. Quindi si ha un solo `name` e un solo `address` e un sono `zip` + ### Special models Ci sono dei *modelli* che vengono considerati *speciali*, tra questi ci sono quelli che hanno un **contenuto misto** e quelli che **non hanno un contenuto**. @@ -498,7 +644,11 @@ La *derivazione* viene specificata introducendo un elemento **complexType** (opp +E' il diagramma di classe che corrisponde a che cosa si può fare con le restrizioni. Il quale parte da `complexType` e si mette dentro ad esso `complexContent` o `simpleContent` . Il primo (`complexContent`) se si vuole partire dal `complexType`. Idemo per il `simpleContent`se si vuole partire dal `simpletype`. +La `restriction` è possibile solo nel `simpleContent` e solo da li si può aggiungere un `facet`. + + #### Esempio: l'estensione di un tipo semplice @@ -518,6 +668,12 @@ Si consideri il seguente tipo: +`simpleContent` il quale estende `simpleType`. Inoltre `base` è un decimale. + +Si va a estendere ` ` + +Una possibile vista è: + ```xml 423.46 ``` @@ -527,27 +683,27 @@ Si consideri il seguente tipo: #### Esempio: estensione di un tipo complesso ```xml - - - - - - - - - - - - - - - - - - +01 +02 +03 +04 +05 +06 +07 +08 +09 +10 +11 +12 +13 +14 +15 +16 +17 +19 ``` - +Dalla riga 01 alla riga 07 (comprese) è la definizione originale. In qui si ha l'indirizzo che è una sequenza di nomi: `name`, `street`, `city`. La riga 09 viene definito un complexType di nome `USAaddress` la quale estende la definizione di prima. #### Esempio: tipo equivalente definito da @@ -571,7 +727,7 @@ Si consideri il seguente tipo: - +Il meccanismo di restrizione è molto simile alla programmazione ad oggetti quando si derivavano una nuova classe con "l'overwritting". Mentre l'estensione è simile a quando si ha l' estensione e quando si aggiunge un nuovo attributo. #### Esempio di uno schema completo (The Purchase Order) @@ -582,6 +738,130 @@ Si consideri il seguente tipo: +PurchaseOrder.xml: + +01 +02 + + 03 + 04 Alice Smith + 05 123 Maple Street + 06 Mill Valley + 07 CA + 08 90952 + 09 + 10 + 11 Robert Smith + 12 8 Oak Avenue + 13 Old Town + 14 PA + 15 95819 + 16 + 17 Hurry, my lawn is going wild! + 18 + 19 + 20 Lawnmower + 21 1 + 22 148.95 + 23 Confirm this is electric + 24 + 25 + 26 Baby Monitor + 27 1 + 28 39.98 + 29 1999年05月21日 + 30 + 31 + + +In questo caso si hanno due indirizzi: +`shipTo` (03/09) e `billTo` (10/16). + +Poi ci sono due items: +-(19/24) `partNum` +-(25/30) `partNum` + + + + + +PurchaseOrder.xsd: + + + + + + + + + + + + + <—collegato X1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +C'è la radice che è: `purchaseOrder` : + + Qui c'è la "type definition":![12](immagini/lezione-03/12.png) + + + +Dentro a `PurchaseOrderType` c'è una sequenza di: `shipto` e `billTo` . Essi sono di tipo ` USAddress`. + +Inseguito si vede come c'è `xsd:date` che è collegato al file precedente + + + + + + + #### Gruppi (`group`) L'elemento `group` permette di creare un modello di contenuto che può essere referenziato con un semplice nome. Mentre l'elemento `attributeGroup` abilita un insieme di attributi confezionati in un `group` definito (avente un nome). diff --git a/History/1 CourseIntroduction.pdf b/History/1 CourseIntroduction.pdf new file mode 100644 index 0000000..06bdbdf Binary files /dev/null and b/History/1 CourseIntroduction.pdf differ diff --git a/History/2 UML_en.pdf b/History/2 UML_en.pdf new file mode 100755 index 0000000..0379156 Binary files /dev/null and b/History/2 UML_en.pdf differ diff --git a/History/3.pdf b/History/3.pdf new file mode 100644 index 0000000..2f65e87 Binary files /dev/null and b/History/3.pdf differ diff --git a/History/4 DTD_exercise.pdf b/History/4 DTD_exercise.pdf new file mode 100755 index 0000000..d6fb00f Binary files /dev/null and b/History/4 DTD_exercise.pdf differ diff --git a/History/5 XMLSchema_en.pdf b/History/5 XMLSchema_en.pdf new file mode 100755 index 0000000..bde6a7d Binary files /dev/null and b/History/5 XMLSchema_en.pdf differ diff --git a/immagini/lezione-02/14.png b/immagini/lezione-02/14.png index ae4c95b..902f252 100644 Binary files a/immagini/lezione-02/14.png and b/immagini/lezione-02/14.png differ diff --git a/immagini/lezione-02/28.png b/immagini/lezione-02/28.png new file mode 100644 index 0000000..4872e0c Binary files /dev/null and b/immagini/lezione-02/28.png differ diff --git a/immagini/lezione-02/29.png b/immagini/lezione-02/29.png new file mode 100644 index 0000000..cf70c08 Binary files /dev/null and b/immagini/lezione-02/29.png differ diff --git a/immagini/lezione-02/30.png b/immagini/lezione-02/30.png new file mode 100644 index 0000000..09cae83 Binary files /dev/null and b/immagini/lezione-02/30.png differ diff --git a/immagini/lezione-02/31.png b/immagini/lezione-02/31.png new file mode 100644 index 0000000..70df727 Binary files /dev/null and b/immagini/lezione-02/31.png differ diff --git a/immagini/lezione-02/32.png b/immagini/lezione-02/32.png new file mode 100644 index 0000000..ab63386 Binary files /dev/null and b/immagini/lezione-02/32.png differ diff --git a/immagini/lezione-02/33.png b/immagini/lezione-02/33.png new file mode 100644 index 0000000..2b58465 Binary files /dev/null and b/immagini/lezione-02/33.png differ diff --git a/immagini/lezione-03/03.png b/immagini/lezione-03/03.png index 141eb9f..626210e 100644 Binary files a/immagini/lezione-03/03.png and b/immagini/lezione-03/03.png differ diff --git a/immagini/lezione-03/08.png b/immagini/lezione-03/08.png new file mode 100644 index 0000000..40c6230 Binary files /dev/null and b/immagini/lezione-03/08.png differ diff --git a/immagini/lezione-03/09.png b/immagini/lezione-03/09.png new file mode 100644 index 0000000..09c0c26 Binary files /dev/null and b/immagini/lezione-03/09.png differ diff --git a/immagini/lezione-03/10.png b/immagini/lezione-03/10.png new file mode 100644 index 0000000..eb34403 Binary files /dev/null and b/immagini/lezione-03/10.png differ diff --git a/immagini/lezione-03/11.png b/immagini/lezione-03/11.png new file mode 100644 index 0000000..1dbc5be Binary files /dev/null and b/immagini/lezione-03/11.png differ diff --git a/immagini/lezione-03/12.png b/immagini/lezione-03/12.png new file mode 100644 index 0000000..0fe245a Binary files /dev/null and b/immagini/lezione-03/12.png differ