Tehnologii WEB Decrypted

TEHNOLOGII WEB
SUPORT CURS An universitar 2006-2007
Conf. dr. Cristina Mndru
pdfMachine A pdf writer that produces quality PDF files with ease! Produce quality PDF files in seconds and preserve the integrity of your original documents. Compatible across nearly all Windows platforms, simply open the document you want to convert, click print, select the Broadgun pdfMachine printer and thats it! Get yours now!
1. CONCEPTELE DE BAZ ALE ARHITECTURII WEB................................ 5

1.1 Arhitecturi pentru INTERNET............................................................................................ 5 1.1.1 Arhitecturi hardware pentru Internet ............................................................................. 5 1.1.2. Arhitecturi software pentru Internet.............................................................................. 7 1.1.3. Arhitectura client-server aplicat la Web ..................................................................... 8 1.1.4 Arhitectura MVC........................................................................................................... 9 1.2 Comunicarea in Web........................................................................................................ 10 1.2.1 Protocolul HTTP (HyperText Transfer Protocol) ..................................................... 11 1.2.2. Cererea HTTP............................................................................................................ 11 1.2.3 Rspunsul HTTP ..................................................................................................... 12 1.2.4 Identificare resurse: URI i URL ............................................................................... 13 1.2.6 Gestiunea reprezentrilor ......................................................................................... 19 1.2.7 Structura informaiilor pe site-uri Web ..................................................................... 20 1.3 Formate de date ............................................................................................................. 20 1.3.1 Formate binare i textuale pentru date ....................................................................... 20 1.3.2. Hipertext..................................................................................................................... 21 1.3.3. Formate de date bazate pe XML ............................................................................... 21 1.3.4. Versiuni i extensibilitate ........................................................................................... 23 1.3.5. Compoziie i formate de date ................................................................................... 23 1.3.6 Separarea ntre coninut, prezentare i interaciune ............................................... 24 1.4 Principiile generale ale arhitecturii Web....................................................................... 24 1.4.1. Specificaii ortogonale................................................................................................ 24 1.4.2. Extensibilitatea........................................................................................................... 25 1.4.3. Gestionarea erorilor ................................................................................................... 25 1.4.4. Interoperabilitate bazat pe protocol ......................................................................... 26
2. HTML......................................................................................................... 27
2.1 Modelul DOM-HTML ........................................................................................................ 27 2.1.1 Modelul Document- Obiect (DOM) ........................................................................... 27 2.1.2 Modelul DOM HTML ................................................................................................ 29 2.2 HTML (HyperText Markup Language) ........................................................................... 31 2.2.1. Elementele limbajului HTML ..................................................................................... 31 2.2.2. FORME ...................................................................................................................... 33 2.2.3 CADRE (FRAMES) ..................................................................................................... 34 2.2.4 HTML DINAMIC (DHTML) ......................................................................................... 37 2.2.5 FOI DE STIL (SS Style Sheets)............................................................................. 38
3. ARHITECTURI PENTRU EXTINDERE FUNCIONALITATE LA CLIENT 43

3.1. Componente .................................................................................................................... 43 3.2 OBIECTE N PAGINI WEB................................................................................................ 44 3.2.1 Plug-ins ....................................................................................................................... 44 3.2.2 COMPONENTE ActiveX............................................................................................. 45 3.3 JAVA SCRIPT.................................................................................................................... 46 3.3.1. Specificaiile standardului ECMAScript ..................................................................... 46 3.3.2. Identificarea obiectelor din ierarhia JavaScript.......................................................... 47 2
3.3.3. Modelul evenimentelor.............................................................................................. 49 3.3.4. Structura paginilor HTML ce conin JavaScript ......................................................... 50 3.3.5 Exemple ..................................................................................................................... 50 3.4 APPLET ............................................................................................................................. 53 3.4.1 Apel applet .................................................................................................................. 54 3.4.2 Operaiile realizate de agentul utilizator ..................................................................... 55 3.5 STRI PERSISTENTE LA CLIENT................................................................................... 57 3.5.1 COOKIE-s ................................................................................................................... 57 3.5.2 Crearea unui cookie.................................................................................................... 58 3.5.3 tergerea unui cookie ................................................................................................. 59 3.5.4 Accesul clientului la cookie ......................................................................................... 59
4. XML I TEHNOLOGII ASOCIATE ............................................................ 60

4.1 Baze de date semistructurate i XML ............................................................................ 60 4.2 SGML (Standard Generalized Markup Language) ....................................................... 62 4.3 XML (eXtended Markup Language) .............................................................................. 63 4.3.1 Documente XML ....................................................................................................... 63 4.3.2 Marcaje .................................................................................................................... 64 4.3.3 Elemente.................................................................................................................. 64 4.3.4 Atribute...................................................................................................................... 65 4.3.5 Referine ................................................................................................................... 66 4.3.6 Structura unui document XML ................................................................................... 67 4.3.7 Instruciuni de procesare ......................................................................................... 67 4.3.8 Restricii asupra documentelor XML....................................................................... 68 4.3.9 Definirea tipului unui document (DTD) .................................................................... 68 4.4 Terminologie i definiii.................................................................................................. 70 4.5 XML Schema .................................................................................................................... 72 4.5.1 Caracterizare XMLSchema........................................................................................ 72 4.5.2 Structura unei scheme XML ...................................................................................... 73 4.6 Spaii de nume i calificatori.......................................................................................... 77 4.7 Familia de limbaje XML................................................................................................... 82 4.7.1 XPath ......................................................................................................................... 83 4.7.2 Familia foilor de stil: XSL, XSLT i XSLFO.............................................................. 90 4.7.3 XQuery..................................................................................................................... 92 4.7.4 Modelul de date pentru XQuery, XPath i XSLT .................................................... 93 4.7.5 XLink ......................................................................................................................... 95 4.7.6 XPointer ................................................................................................................... 97 4.7.7 XInclude ................................................................................................................... 99 4.7.8 XML Base .............................................................................................................. 100 4.7.9 XHTML.................................................................................................................... 101 4.7.10 SVG ...................................................................................................................... 101
5. ARHITECTURI PENTRU EXTINDERE FUNCIONALITATE LA SERVER ............................................................................................................................... 103

5.1 CONTAINER-ul WEB ...................................................................................................... 103 3
5.2 CGI (Common Gateway Interface) ................................................................................ 104 5.3 Tehnologii de scripting la server.................................................................................. 106 5.3.1 Tehnologia ASP (Active Server Pages).................................................................... 106 5.3.2 Modelul Obiect al tehnologiei ASP ........................................................................... 108 5.3.3 Aplicaii ASP ............................................................................................................. 109 5.3.4 Programare la server cu PHP................................................................................... 111 5.4 ACCESUL LA DATE PERSISTENTE ............................................................................. 115 5.4.1 ACCESUL LA SISTEMUL DE FIIERE .................................................................. 115 5.4.2 ACCESUL LA BAZE DE DATE ................................................................................ 117 5.5. TEHNOLOGII JAVA PENTRU EXTINDEREA FUNCIONALITII LA SERVER....... 127 5.5.1 SERVLET.................................................................................................................. 127 5.5.2 JSP (Java Server Pages) ......................................................................................... 136
4
1. CONCEPTELE DE BAZ ALE ARHITECTURII WEB

n acest capitol sunt prezentate noiuni fundamentale despre arhitecturi de sisteme de calcul, arhitecturi hardware care stau la baza Internetului i arhitecturi software construite peste acestea, bazate pe paradigmele client/server i MVC. n continuare sunt descrise componentele fundamentale ale arhitecturii Web pentru identificarea resurselor, interaciunea resurselor i reprezentarea datelor i metadatelor. n final sunt prezentate cerinele i evoluia arhitectural ce a condus la apariia stilului REST, destinat sistemelor hipermedia moderne. Capitolul ofer o perspectiv de ansamblu asupra conceptelor i problematicii specifice Web, a crei cunoatere este necesar pentru dezvoltarea de aplicaii n acest mediu distribuit complex.
1.1 Arhitecturi pentru INTERNET

Arhitectura reprezint perspectiva structural asupra unui sistem de calcul. Aceasta definete numrul, tipurile i subtipurile resurselor componente i interconectrile lor. Fiecare tip de component corespunde unui mecanism pe care aceasta l realizeaz n sistem. Interconectarea componentelor este realizat pe baza unor abloane, care definesc modul de interconectare ntre componente prin reguli i restricii de interconectare. 1.1.1 Arhitecturi hardware pentru Internet Internet-ul este o reea de reele format din platforme (sub-reele) multiple i eterogene care trebuie s comunice ntre ele. Pentru aceasta se utilizeaz diferite ci de comunicare (cablu, fibr optic, unde radio) i componente ce distribuie informaiile ntre platforme, numite router-e.
Reea 1 CLIENT c1 Router Reea k Router k
Reea 2 CLIENT c2
Router 2
Fig.1.1 Arhitectur hardware pentru Internet
Privit din punct de vedere logic, comunicarea ntre clienii C1 i C2 aflai n subreele diferite, posibil cu protocoale de comunicare de nivel inferior diferite, este o comunicare direct. Din punct de vedere fizic aceast comunicare se poate face pe
5
cel puin dou ci: de la clientul C1 la router-ul R1, de la R1 la router-ul Rk i apoi la router-ul R2. De la R2 informaia este transmis clientului C2. A doua cale este format de succesiunea de corespondeni client C1, router R1, router R2 i client C2. Exist dou variante de realizare a unei comunicari logice ntre clienii Internet-ului. Anterior am prezentat varianta care utilizeaz router-e. A doua variant este mai complex i este reprezentat de furnizorul de servicii Internet. Fiecare din aceste variante ofer clienilor servicii specifice pentru comunicare n Internet. Router-ul realizeaz transparena comunicrii fizice pentru cei doi clieni. Din punctul de vedere al clienilor avem urmtoarea arhitectur:
Client 1 Cale de comunicare backbone Client 2
Fig.1.2 Comunicare logic n Internet
Router-ul este o component Internet ce furnizeaz dou servicii clienilor si: serviciul de tranzit i serviciul de acces. Serviciul de tranzit realizeaz legtura ntre regiuni cu lrgimi mari de band i viteze mari de transfer. Serviciul de acces realizeaz comunicarea ntre clieni prin linii dedicate sau comutate. Fiecare router gestioneaz informaii referitoare la zona sa de aciune. Routerele comunic ntre ele n mod dinamic, n vederea stabilirii cii optime de transmitere a fiecrui pachet de informaii. La acest nivel sunt rezolvate dinamic problemele care apar datorit unor defecte n reeaua fizic de comunicare sau datorit congestionrii traficului. Identificarea corespondenilor se face pe baza unui set de identificatori numerici unici disponibili la nivelul reea (IP). Pentru uzul nivelelor superioare, de care ne ocupm n monografia de fa, se utilizeaz o schem de nume explicite, bazat pe o organizare pe domenii i subdomenii a mainilor din Internet. Traducerea acestor nume n valorile numerice ale identificatorilor unici se face pe baza corespondenelor coninute n baze de date specializate aflate n servere care funcioneaz ca servicii de nume la nivel de domeniu (DNS - Domain Name Server). A doua variant de comunicare ntre clieni Internet este reprezentat de furnizorul de servicii Internet. Acesta este o form pentru intermedierea comunicaiilor n Internet superioar router-ului.
ISP
Internet
ISP
Client 1
Client 2
Fig.1.3 Comunicare utiliznd furnizori de servicii Internet
Furnizorul de servicii Internet (ISP Internet Service Provider) ofera mai multe tipuri de servicii clienilor si. Serviciul de tranzit i serviciul de acces au aceleai funcii ca i cele oferite de router. Furnizorul de servicii Internet ofer n plus servicii
6
cu valoare adaugat. Acestea sunt servicii de server Web, servicii de firewall, servicii de intranet i servicii de extranet. Serviciile de server Web realizeaz gzduirea de site-uri Web ca i accesul la acestea. Serviciile de firewall asigur protecia controlat a accesului clienilor la diferite servicii. Serviciile de intranet permit crearea de reele private cu acces limitat doar la clienii reelei respective. Serviciile de extranet ofer posibilitatea crerii de reele private virtuale, deoarece permit extinderea unui intranet cu posibilitatea de a iei n Internet ctre anumite noduri privilegiate, noduri pentru care se relaxeaz restriciile din firewall. Nodurile privilegiate au ataate nivele de privilegiu bazate pe structura de comunicare logic definit pentru reeaua virtual. De exemplu, se pot defini nivele de privilegiu diferite pentru diferite categorii de utilizatori cum ar fi clieni, furnizori sau prieteni. 1.1.2. Arhitecturi software pentru Internet Paradigma care st la baza arhitecturilor software pentru Internet este paradigma CLIENT-SERVER. Paradigma client/server se bazeaz pe doi actori: clientul i serverul. Clientul are rolul de a solicita un serviciu, iar serverul are rolul de a oferi clientului serviciul solicitat. Schimbul de informaii ntre procesele client i server se face prin intermediul unui canal de comunicare prin care circul mesaje de cerere de la client la server i mesaje de rspuns de la server la client.
cerere CLIENT rspuns SERVER
Fig.1.4 Paradigma client/server
O arhitectur simpl bazat pe paradigma client-server este compus dintr-un server i mai muli clieni.
Cerere Client Raspuns Client Server
Client
Fig.1.5 Arhitectura cu un server i mai muli clieni
Aceasta este o arhitectur pe dou straturi i este utilizat de aplicaiile client/server cu server centralizat. Solicitrile clienilor sunt rezolvate n ntregime de ctre server, acesta coninnd toate informaiile i procesele necesare construirii rspunsului.
7
n cazul n care serverul are un grad mare de complexitate, o arhitectur bazat pe paradigma client/server este organizat pe mai multe straturi.
cerere rspuns cerere cerere
SERVER
rspuns
CLIENT
rspuns
SERVER
raspuns cerere cerere
SERVER
Fig.1.6 Arhitectura client/server cu straturi multiple
rspuns
n acest caz, pentru realizarea unui serviciu, un client apeleaz la un server care, pentru a oferi serviciul solicitat, necesit o serie de funcii pe care le obine apelnd la rndul su la unul sau chiar mai multe servere. Un proces poate fi client al unuia sau mai multor procese, dar, n acelai timp, poate fi server pentru alt set de procese. 1.1.3. Arhitectura client-server aplicat la Web Arhitectura client-server pe dou straturi aplicat la Web este compus din clieni de tip navigator (browser) si din server de tip WebServer. Server-ul Web are dou interfee. Prin interfaa cu clienii se realizeaz operaiile de preluare a solicitrilor acestora i de transmitere a rspunsului. Clienii solicit documente aflate pe server care sunt depozitate n fiiere de tip *.html.
HTTP WebServer Cerere Browser
(URL)
Rspuns
Interfaa client Interfaa cu site-ul Web
Fig.1.7 Arhitectura Web clasic
Fisiere *.html aflate n sistemul de fiiere al mainii gazd
Serverul Web are ca principala funcie asigurarea accesului la fiierele *.html, care formeaz cea mai simpl varianta de site Web. Odat cu evoluia tehnologiilor au aprut modaliti de extindere a acestei funcionaliti simple att pe partea clientului, ct i pe partea server-ului. Acestea permit separarea diferitelor
8
tipuri de funcionaliti ale unei aplicaii Web, astfel nct arhitectura acesteia devine mai complex. n arhitectura client/server tradiional, pe dou straturi, clienii aplicaiei intermediaz interaciunile utilizatorului, n mod tipic prin GUI1, i implementeaz logica aplicaiei, incluznd i accesele la baze de date. n aceste arhitecturi logica aplicaiei este procesat pe mainile utilizatorilor. ntr-o aplicaie pe mai multe straturi clienii pot delega logica aplicaiei i accesul la baze de date ctre componente software aflate pe nivele intermediare. n aplicaiile din Internet clienii Web au nlocuit clienii aplicaiilor de sine stttoare. n arhitecturile bazate pe clieni Web, nivelul interaciunii cu utilizatorul este separat de nivelul client tradiional. Navigatoarele Web sau aplicaii cu scop general similare gestioneaz interaciunea cu utilizatorul, lsnd restul responsabilitilor nivelului client n seama aplicaiilor aflate pe server. Aceste responsabiliti includ logica de comand a interfeei utilizator, interaciunea cu componentele de pe nivelele intermediare i cea cu sursele de date. n aceast arhitectur, pentru un utilizator final, navigatorul este clientul tuturor aplicaiilor bazate Web. Clienii Web se caracterizeaz prin: un navigator sau o aplicaie similar pentru gestionarea interaciunii cu utilizatorul, HTML (cu JavaScript i/sau DHTML), XHTML sau XML (Cu XSL), ca mijloc de definire a interfeei utilizator, HTTP/HTTPS ca protocol pentru schimbul de informaii ntre clienii Web i aplicaiile Web. Prin separarea prezentrii datelor de ntreinerea acestora se obin aplicaii Web care corespund unei alte paradigme arhitecturale, numit Model-ViewController (MVC) i descris n continuare. 1.1.4 Arhitectura MVC Arhitectura MVC ("Model-View-Controller") este o modalitate de a mpri cerinele de funcionalitate ale aplicaiei ntre obiectele responsabile cu ntreinerea datelor i cele responsabile cu prezentarea datelor, astfel nct s se minimizeze gradul de cuplare ntre grupuri de obiecte cu funcionaliti diferite.
interogare asupra strii Model ncapsuleaz starea aplicaiei Rspunde la interogri asupra strii Expune funcionalitatea aplicaiei Notific modificrile ctre vederi modificare stare
notificare modificare
Vedere(view) Red modelele Solicit actualizri de la modele Trimite gesturile utilizatorului la controller Permite controller-ului sa selecteze o anumita vedere invocare metod eveniment
1
selecie view
gesturi utilizator
Controller Definete comportamentul aplicaiei Pune n coresponden aciunile utilizatorului cu actualizrile modelului Selecteaz view pentru rspuns Corespunde la o funcionalitate
Fig.1.8 Arhitectura MVC
Graphic User Interface. 9
Spre deosebire de separarea functionalitii unui sistem conform rolurilor de client i de server, aceast arhitectur introduce trei roluri in sistem. Modelul(M) reprezint datele aplicaiei i regulile referitoare la accesul i la modificarea acestora. De multe ori modelul servete ca o aproximare software a unui proces din lumea real iar n definirea lui se aplic tehnici simple de modelare a lumii reale. Atunci cnd modelul se modific, are loc notificarea vederilor, care au astfel posibilitatea de a interoga modelul asupra strii sale. Controller-ul acceseaz funcionalitatea aplicaiei ncapsulat n model. O vedere(V) red coninutul modelului ntr-un format specific. Funciile unei vederi sunt accesarea datelor din model i specificarea modului de (re)prezentare a acestora. Dac modelul se schimb, vederea este responsabil cu pstrarea consistenei ntre datele din model i reprezentarea acestora. Tot vederea rspunde de transmiterea ctre controller a solicitrilor (gesturilor) utilizatorului. Controller-ul(C) definete comportamentul aplicaiei. Pentru aceasta el interpreteaz gesturile utilizatorului i le pune n coresponden cu aciunile ce trebuie realizate de model. Pentru fiecare set de funcii nrudite exist cte un controller.
1.2 Comunicarea in Web

Arhitectura software este o perspectiv abstract asupra sistemului i un model pentru compararea diferitelor sisteme. Ea definete alocarea i identificarea componentelor unui sistem, interaciunile dintre acestea ca i cantitatea i granularitatea necesar realizrii acestor interaciuni n cazul aplicaiilor Web comunicarea este restricionat la transfer de mesaje. Realizarea unui transfer prin interfaa cu clientul se face n mai multe etape. Acestea sunt: stabilirea conexiunii, emiterea unei cereri de ctre client, emiterea raspunsului de ctre server i nchiderea conexiunii. Comunicarea ntre componentele arhitecturii Web are loc pe baza unui protocol de comunicare specific. Protocolul de comunicare este colecia de reguli care definesc comunicarea ntre doua entitati, n cazul nostru ntre componentele unei arhitecturi client/server. Aceste reguli se refer la structurarea datelor care se transfer i la ordinea de realizare a transferurilor. Protocolul de comunicare ntre componentele unei aplicaii Internet este o entitate complex care se bazeaz pe o stiv de protocoale. Fiecare nivel al acestei stive utilizeaz serviciul de comunicare oferit de nivelul inferior. Ultimul nivel aparine comunicrii fizice. Modelul general al comunicarilor n reea este modelul OSI, care conine apte nivele: aplicaie, prezentare, sesiune, transport, reea, legatur de date i nivelul fizic. Modelul TCP/IP utilizat n reele de calculatoare acoper primele patru nivele inferioare ale modelului OSI i reprezint un standard pentru nivelele reea (Internet) i transport. La nivelul reea Internet este definit protocolul IP care asigur legtura ntre calculatoare identificate prin adrese numerice unice de Internet numite IP. ntre acestea sunt transmise pachete cu informaii. La nivelul transport sunt furnizate servicii de gestionare a pachetelor IP. Aceste servicii realizeaz modelul comunicrii
10
end-to-end (cu surs i destinaie cunoscute), rendez-vous al conexiunilor i controlul fluxului pentru comunicare date. Peste TCP/IP se suprapune un singur nivel (corespunzator nivelelor superioare din modelul OSI), care reprezint nivelul aplicaiei. Pentru acest nivel exist mai multe protocoale, cele mai semnificative fiind urmtoarele: - Telnet protocol pentru conectarea clientului la o interfa de lansare comenzi, n regim de terminal - FTP protocol pentru transfer fisiere (File Transfer Protocol) - SMTP protocol pentru e-mail (Simple Mail Transfer Protocol) - POP protocol pentru e-mail - DNS protocol pentru numire maini Internet (Domain Name Server) - HTTP protocol pentru comunicare hipertext (HyperText Transfer Protocol) 1.2.1 Protocolul HTTP (HyperText Transfer Protocol) HTTP este un protocol la nivel de aplicaie pentru sisteme informaionale hipertext i hipermedia distribuite i colaborative. El este un protocol generic, fr memorare stare (stateless). Utilizarea sa de baz este n transferul de hipertext i hipermedia. Totui, prin extensii ale tipurilor de cereri, ale codurilor de eroare i coninutului din antet, poate fi folosit i de sisteme de gestiune a obiectelor distribuite sau de servere de nume. Una din caracteristicile sale fundamentale este tipizarea i negocierea reprezentrilor datelor, ceea ce permite construirea sistemelor independent de datele ce sunt transferate. HTTP este protocolul de comunicare cu serverul Web. Att clientul Web ct i serverul Web implementeaz acest protocol. Pentru aceasta, fiecare are un modul software care conine aceast implementare. Protocolul HTTP este de tip cerere/rspuns pentru o resurs identificat cu URL2. Protocolul HTTP ofer o funcionalitate sporit fa de alte protocoale, incluznd un subset al funcionalitii de transfer de fiiere, abilitatea de a solicita cutarea unui index, negociere automat a formatului i abilitatea de a deferi cererea clientului ctre un alt server. HTTP realizeaz unificarea diferitelor tipuri de date (text, imagine, etc.), a variaiilor de localizare i de protocol, prezentnd clientului un format omogen, sub form de pagini, a informaiilor. Prin HTTP se asigur transferul de fluxuri de caractere organizate pe linii terminate cu <CR>. Protocolul HTTP definete att formatul cererii ct i formatul rspunsului. 1.2.2. Cererea HTTP Fiecare cerere HTTP utilizeaz o conexiune proprie. Spunem ca HTTP este un protocol stateless deoarece nu pstreaz starea de la o cerere a unui client la alta. Acesta reprezint un dezavantaj ce este acoperit de o serie de tehnologii adugate peste HTTP, att la client (cookies) ct i la server (gestiune sesiuni client). Utiliznd aceste tehnologii se poate realiza gruparea coleciilor de cereri aflate n diferite relaii logice. O cerere HTTP este nsoit de identificatorul resursei solicitate, URL. Cererea HTTP este format din patru elemente componente, specificate n figura urmtoare. Component Metoda
2
Semnificaie Comanda de executat asupra resursei:
Uniform Resource Locator. 11
GET/HEAD/PUT/POST/DELETE/TRACE
Antet (header) Linie liber Coninut (body)
Informaii despre cerere i client Separator obligatoriu Date de transferat

Fig.1.9 Formatul cererii HTTP
Pentru fiecare cerere se definete o metod prin care se specific tipul rspunsului ateptat de client. Dac metoda specificat este GET, clientul primete resursa identificat cu URL. Dac metoda este HEAD, clientul primete doar informaii despre resurs (meta-date) i nu resursa propriu-zis. Dac n cerere se specific metoda PUT, serverul plaseaz coninutul transmis prin cerere (body) la locaia identificat cu URL Coninutul transmis devine noua resurs, aceasta fiind o metoda prin care clientul poate modifica coninutul site-ului Web. Evident c aceast modificare se face n limita permisiunilor acordate de administratorul site-ului. Metoda POST este, de asemenea, destinat transmiterii unei entiti de la client la server. n acest caz se specific identificatorul resursei ce va prelucra entitatea transmis n mesaj. Exist, de asemenea, nc dou metode mai puin utilizate: DELETE, prin care se solicit tergerea unei entiti de pe server i TRACE, prin care se invoc o cerere de diagnosticare. Prezentm n continuare un exemplu de cerere n care e specificat metoda POST.
POST /servlet/personal.class HTTP/1.0 User-Agent: Mozilla/4.04 Accept: image/gif, image/X-bitmap, image/jpeg, Host: www.pub.ro Content-type: application/x-www-form-urlencoded Content-length: 100 Connection: keep-alive Accept-Charset: ISO-8859-1, Referer: http://www.pub.ro/studenti.html <LF> nume = &prenume=&zi=&luna=&an=
1.2.3
Rspunsul HTTP
Rspunsul serverului Web este format din trei elemente componente, specificate n figura ce urmeaz. Component Stare Antet (header) Coninut (body) Semnificaie Versiunea HTTP, cod stare, descriere stare Informaii despre pagina returnat ca rspuns Pagina solicitat n cerere
Fig.1.10 Formatul rspunsului HTTP
12
Principalele informaii din antet se refer la tipul serverului Web, la tipurile de date acceptate, la tipul documentului returnat (MIME-type3 - ex. text/html, imagine/gif, audio/basic, multipart/digest, video/mpeg) i la dimensiunea documentului transmis. Exemplificm n continuare formatul rspunsului HTTP.
HTTP 1.0 200 document follows Server: Apache_Go_Webserver/4.6 Date: Thu, 20 Febr 2003 15:30:00 GMT Accept-Range: bytes Content-type: text/html Content-length: ... Last-Modified: Wed, 19 Febr Coninutul paginii solicitate
ANTET Meta-informaii (informaii despre pagin)
S-HTTP (secure HTTP) reprezint o extensie a protocolului cu faciliti de encriptare a informaiilor i cu semnturi digitale, n vederea asigurrii securitii acestora. 1.2.4 Identificare resurse: URI i URL World Wide Web (WWW) este un spaiu informaional compus din resurse identificate n mod unic cu URI (Uniform Resurce Identifier). n acest spaiu activeaz agenii Web care pot fi persoane sau componente software. Acesul persoanelor este intermediat de agenii utilizator. Agenii software includ ageni utilizator, ca navigatoare i player-e multimedia, i alte categorii de ageni de tip server, proxy i spider. Bazele arhitecturale ale Web sunt identificarea resurselor, interaciunea acestora i formatele de reprezentare a datelor i metadatelor. Identificarea resurselor se face n mod uniform, utiliznd URI. Agenii Web comunic prin mesaje, utiliznd protocoale standardizate ce definesc sintaxa i semnatica mesajelor. Cazul comun de interaciune este emiterea unei cereri de resurs, formatat conform definiiilor protocolului HTTP, la care serverul solicitat rspunde cu o reprezentare a resursei. Majoritatea protocoalelor utilizate pentru extragerea i/sau memorarea de reprezentri de resurse utilizeaz o secven de unul sau mai multe mesaje, care luate mpreun formeaz reprezentrile datelor i metadatelor, pentru a transfera reprezentrile ntre ageni. Alegerea protocolului limiteaz formatele reprezentrilor datelor i metadatelor ce pot fi transmise. Astfel, HTTP transmite n mod tipic un singur flux de octei plus metadate i utilizeaz n antet cmpurile Content-Type i Content-Encoding pentru a specifica formatul reprezentrii. Agenii utilizator de tip navigator sunt programai ca s interpreteze valorile din aceste cmpuri ca instruciuni de alegere a unui mod de redare a coninutului. Dac, de exemplu, valoarea specificat pentru Content-Type este application/xhtml+xml, atunci datele din reprezentare pot fi procesate conform specificaiei XHTML. Aceasta include i orice interaciune subsidiar
Multipurpose Internet Mail Extensions reprezint o specificaie tehnic utilizat pentru a descrie transferul de date multimedia cu ajutorul standardelor de pot Internet. 13
3
necesitat de tipul respectiv de reprezentare, cum ar fi n acest exemplu solicitarea de foi de stil externe sau imagini in-line. O astfel de aciune subsidiar poate indica o resurs cu reprezentare de alt tip, ceea ce va genera o procesare diferit a acesteia la agentul utilizator, conform tipului ei indicat n cmpul Content-Type din antet. Acest proces continu pn cnd sunt redate toate formatele de date referite direct sau indirect. Rezultatul acestor procesri, obinut n momentul n care navigatorul a ajuns n starea stabil de ndeplinire a cererii iniiale, este referit n mod uzual ca pagin Web. Urmtoarea figur ilustreaz relaiile dintre identificator, resurs i reprezentare:
URI
http://www.unSite.ro/cursuri
identific
RESURS
Lista cursurilor oferite
reprezint
REPREZENTARE
Metadate:
Content-type: application/xhtml+xml
Date:
<!DOCTYPE html PUBLIC ... http://www.w3.org/... <html xmlns=http://www... <head> <title>Cursuri universitare</title> ... </html>
Fig.1.11 Relaia ntre bazele arhitecturale ale Web-ului
Modelul clasic al interaciunilor utilizatorilor cu Web-ul este cel n care utilizatorul urmrete o hiperlegtur prin intermediul unui agent utilizator, agentul extrage i prezint datele, utilizatorul alege i urmrete o alt hiperlegtur, etc. Un alt model de interaciune este cel exclusiv audio, n care sistemul primete pe intrare informaii vocale i produce ieire audio. Alegerea unui model de interaciune are impact asupra comportamentului agentului utilizator. Identificare Web reprezint o comunitate global n care participanii partajeaz informaii. Comunicarea n aceast comunitate se face pe baza unui set de termeni cu sintax i semantici bine definite.
14
Un element fundamental al arhitecturii Web este URI (Unified Resource Identifier) ca identificator unic global n sistem. Pe lng avantajele oferite de caracteristica global a URI, utilizarea acestuia prezint beneficii legate de stabilire de legturi, liste de preferine, caching i indexare de ctre motoarele de cutare. Cu fiecare resurs care are ataat un identificator de tip URI se pot realiza diverse operaii. Asfel, ea poate fi indicat ca destinaie a unei hiperlegturi, poate fi analizat, extras ca atare sau se poate prelua n cache una din reprezentrile ei, poate fi inclus parial sau total ntr-o alt reprezentare, poate fi adnotat. Relaii URI-resurs URI identific o resurs. Termenul de resurs are un sens larg i reprezint orice entitate identificabil de ctre un URI. n Web resursele sunt diverse, dar au ca i caracteristic unificatoare faptul c produc informaii, numite reprezentri ale resursei, ce pot fi transferate prin intermediul mesajelor. De aceea ele sunt identificate cu termenul mai particular de resurse de informaii. Specificaiile pentru URI reprezint un acord referitor la modul n care comunitatea Internet face alocarea de nume asociate resurselor pe care le identific. URI este divizat n scheme care definesc, n specificaiile fiecrei scheme, mecanismul prin care se asociaz resurselor identificatori specifici unei schemei. De exemplu, schema http utilizeaz servere HTTP bazate pe TCP i DNS pentru alegerea i alocarea de identificatori. Ca rezultat, un identificator bazat pe schema http se refer la realizarea unei cereri HTTP de tip GET cu acest identificator, iar dac se primete un rspuns corect, acesta este interpretat ca o reprezentare a resursei identificate. Arhitectura Web permite asocierea mai multor URI-uri, de tip alias, cu o singur resurs. Alocarea unui URI pentru o resurs se poate realiza de ctre proprietarii acesteia sau de alte autoriti. Este esenial ca n acest proces de alocare s se evite fenomenul de coliziune produs de utilizarea aceluiai URI pentru identificarea mai multor resurse. Proprietatea asupra unui URI este o relaie ntre URI i o entitate social, care permite asocierea unei resurse cu URI-ul deinut. Dreptul de proprietate este gestionat de o ierarhie organizaional cu rdcina n specificaiile schemei URI nregistrate la IANA (Internet Assigned Numbers Authority). IANA gestioneaz un registru de corespondene ntre numele schemelor URI i specificaiile acestora. Scheme URI Fiecare schem URI are o specificaie care explic detaliile referitoare la alocarea i asocierea cu o resurs. Sintaxa URI este un sistem de numire federativ i extensibil, n care fiecare specificaie de schem poate impune restricii proprii asupra sintaxei i semanticii identificatorilor din schema respectiv. Multe din aspectele procesrii unui URI sunt dependente de schema cruia i se conformeaz acesta. Introducerea unei noi scheme induce costuri legate de dezvoltarea i distribuirea de componente software de tip client, gateway, proxy, etc. corespunztoare acesteia. De aceea se recomand utilizarea schemelor existente n toate cazurile n care acestea rspund cerinelor aplicaiei.
15
Opacitatea URI Web-ul este proiectat astfel nct agenii comunic informaiile despre starea resurselor prin intermediul reprezentrilor i nu prin identificatori. Dei unele nume ar putea fi sugestive, n general4 nu se poate determina tipul reprezentrii unei resurse pe baza URI-ului acesteia. De exemplu, un identificator ca http://www.unSite.ro/exemplu.html nu garanteaz faptul c reprezentarea resursei pe care o identific va fi de tip text/html, deoarece protocolul HTTP nu impune acest lucru. Avantajul acestei flexibiliti este transparena modificrilor aprute n starea unei resurse, deci i n reprezentrile acesteia. Identificatori de fragment Una din componentele unui URI este identificatorul de fragment. Acesta permite identificarea indirect a unei resurse secundare prin referire la o resurs primar, extins cu informaii adiionale de identificare. Resursa secundar poate fi o poriune sau un subset al celei primare, o anumit perspectiv a reprezentrilor resursei primare sau o alt resurs definit sau descris prin aceste reprezentri. n acest context, termenii de primar i secundar indic o relaie ntre dou resurse i nu limiteaz natura unei resurse la un fragment, n sens propriu, al alteia. Identificatorii de fragment pot fi utilizai cu nume de spaii de nume pentru a identifica componente abstracte. Preocuprile de viitor n domeniul identificrii resurselor n Web se refer la internionalizarea identificatorilor prin extinderea setului de caractere acceptate i la utilizarea tehnologiilor oferite de Web Semantic, inclusiv de limbajul OWL (Ontology Web Language), pentru a deduce c dou URI-uri identific aceeai resurs. URI i URL URI are o sintax standard pentru irurile prin care se identific o resurs n Web. Informal, URI este un termen generic pentru adresele i numele resurselor din Web. Resursa Web, n sens general, este orice entitate fizic sau abstract ce poate fi accesat n Web i care are o identitate proprie. URI-urile sunt de dou tipuri. URL (Uniform Resource Locator) care identific o resurs dup modul n care este accesat. De exemplu, "http://www.example.com/stuff/index.html" identific o pagin HTML pe un server al crui nume este http://www.example.com, pagin accesat prin intermediul protocolului HTTP URN (Uniform Resource Name) creaz un nume unic i persistent pentru o resurs, fie n spaiul de nume urn fie ntr-un alt spaiu de nume nregistrat. Spaiul de nume este cel care dicteaz sintaxa identificatorului de tip URN. Un identificator unic de resurs are urmtorul format general. protocol: // resurs # subresurs Identificarea unei resurse de pe un server Web se face cu URL (Unified Resource Locator). Un URL se poate specifica fie n manier absolut, caz n care
Sunt totui definite cteva cazuri particulare n care se poate deduce cu certitudine tipul reprezentrii. 16
conine identificatorul serverului i al localizrii absolute a resursei pe site-ul respectiv5, fie relativ la directorul curent al documentului care face referirea. n general, exist o serie de porturi standard pe care ascult procese ce comunic prin diferite protocoale. Procesul server Web comunica prin protocolul HTTP i ascult implicit pe portul 80 al masinii gazd pe care se execut. Aceast alocare poate fi modificat prin stabilirea altui port de ascultare la reconfigurarea serverului Web. Dac procesul solicitat ascult pe un alt port dect cel implicit (80), atunci se specific numrul portului n URL. Localizare pe site Sintaxa general a unui URL este urmtoarea: http: // identificator_proces[:port] / cale / nume_fisier Colectia de fisiere *.html ca i de alte tipuri (n cazul serverelor Web cu funcionalitate extins), formeaz site-ul Web, accesibil clienilor din Internet. Fiierele site-ului Web sunt localizate ntr-un director specific pe maina pe care se execut serverul Web. Acesta reprezint rdcina site-ului Web. De exemplu, n cazul unui server Apache rdcina (root) este %APACHE_HOME%/htdocs, unde variabila sistem %APACHE_HOME% conine calea pe care se afl instalat serverul Apache (ex. C:/ProgramFiles/Apache Group/Apache pe o main Windows). Un alt exemplu este rdcina unui site Web accesibil prin IIS (Internet Information Server de la Microsoft), aceasta fiind, n general, C:\InetPub\wwwroot\. 1.2.5 Interaciune Comunicarea inter-agent referitoare la resurse implic URI-uri, mesaje i date. Protocoalele Web (HTTP, FTP, SOAP, NNTP i SMTP) se bazeaz pe schimbul de mesaje. Un mesaj poate include date i metadate despre resurse, date despre mesaj, metadate despre metadatele mesajului (ex. verificri de integritate a mesajului) i, n fine, mesajul propriu-zis. Faptul c Web-ul este un sistem larg distribuit afecteaz restriciile arhitecturale i presupunerile legate de interaciuni. Metoda prin care agenii utilizeaz un URI pentru a referi o resurs este numit dereferirea URI6-lui. Accesul la resurs poate mbrca forme diferite. El include extragerea unei reprezentri a acesteia (ex. utiliznd metodele GET sau HEAD din HTTP), adugarea sau modificarea reprezentrii unei resurse (ex. HTTP POST sau PUT) care poate conduce la modificarea strii acesteia, sau tergerea uneia sau tuturor reprezentrilor unei resurse (ex. HTTP DELETE), caz n care se poate produce chiar eliminarea definitiv a resursei. Contextul aplicaiei este cel care determin modul n care se acceseaz o resurs identificat cu un URI dat. De exemplu, un navigator ar putea utiliza HTTP GET pentru a obine o reprezentare a resursei, pe cnd un agent de verificare a legturilor hipertext ar putea utiliza HTTP HEAD pe acelai URI doar pentru a stabili dac resursa este disponibil. O schem URI nu implic n mod necesar utilizarea unui anume protocol pentru a accesa resursa identificat. Aceasta poate fi accesat printr-o colecie de
Rdcina unui site este, n general, diferit de rdcina sistemului de fiiere al sistemului de operare pe care se afl site-ul. 6 Dereferencing the URI. 17
5
servicii de tip gateway, proxy, sau servicii de nume care sunt independente de protocolul asociat schemei de nume. Totui majoritatea schemelor URI definesc un protocol de interaciune implicit pentru accesul la resursa identificat. Acesta este de obicei baza alocrii identificatorilor schemei. Astfel, URI-urile care au la baz http sunt definite n termeni de servere HTTP bazate pe TCP. Stabilirea exact a reprezentrii ce va fi furnizat de o resurs depinde de o serie de factori. Acetia se refer la faptul c proprietarul resursei ofer reprezentarea respectiv, c agentul solicitant are privilegiile de acces necesare, c n urma negocierii dintre agentul utilizator i server s-a stabilit transferul reprezentrii respective dintr-un set disponibil de reprezentri ale resursei. Odat transferat, expresivitatea formatului reprezentrii va afecta precizia cu care furnizorul comunic starea resursei. O stare a resursei care nu este comunicat cu acuratee de ctre reprezentare poate conduce la confuzii semantice. O soluie este dat de Semantic Web, care propune un cadru de comunicare exact a semanticilor unei resurse ntrun format de reprezentare a acesteia ce poate fi interpretat de main.
Tipuri de reprezentri i tipuri de media n Internet
O reprezentare este o colecie de date care codific informaii despre starea unei resurse7. Reprezentrile unei resurse sunt transmise i recepionate utiliznd protocoale de interaciune. Aceste protocoale sunt cele care determin forma n care reprezentrile sunt difuzate n Web. De exemplu, protocolul HTTP transmite reprezentrile de resurse sub form de fluxuri de octei tipate8 conform tipurilor de media in Internet. Ca i n cazul schemelor URI, reutilizarea de tipuri de fluxuri de octei n protocoale diferite permite utilizarea acelorai produse software pentru redarea reprezentrilor9. Tipul de media Internet10 definete sintaxa i semanticile identificatorului de fragment (dac exist) care poate fi utilizat n conjuncie cu o anumit reprezentare. Aceste semantici sunt definite de setul de reprezentri care pot rezulta n urma unei aciuni de extragere din resursa primar. Formatul i rezoluia fragmentului sunt astfel dependente de tipul unei reprezentri ce poate fi extras, chiar dac aceast extragere are loc dac URI-ul este dereferit. Dac nu exist o astfel de reprezentare, atunci semanticile fragmentului sunt considerate necunoscute i nerestricionate. Semanticile identificatorului de fragment sunt ortogonale cu schemele URI i de aceea nu pot fi redefinite de specificaii pentru scheme URI. Interpretarea identificatorului de fragment este fcut n mod exclusiv de ctre agentul care face dereferirea URI-ului. Identificatorul nu este transferat altor sisteme n cursul procesului de extragere, astfel c elemente intermediare din arhitectura Web (ex. proxy) nu interacioneaz cu identificatorii de fragment n vederea redirectrii lor.
Identificatori de fragment i negocierea coninutului Tipuri de reprezentri i semanticile identificatorului de fragment
Negocierea coninutului are loc atunci cnd pentru acelai URI sunt disponibile reprezentri multiple. Negocierea ntre agentul solicitant i server determin reprezentarea considerat cea mai potrivit din punct de vedere a
7
Ea nu descrie n mod necesar resursa, nu este o copie sau o reprezentare n alte sensuri a
acesteia.
8 9
Care sunt caracterizate de un tip. Exemplu pentru principiul specificaiilor ortogonale prezentat n seciunea 1.4.1. 10 Internet Media Type. 18
posibilitilor de redare de la agent, aceasta fiind cea care va fi servit ca rspuns la cerere. HTTP este unul din protocoalele care permit negocierea coninutului. Unele formate individuale de date pot defini reguli proprii pentru utilizarea sintaxei identificatorului de fragment n vederea specificrii diferitelor tipuri de subseturi, vederi, sau referine externe care sunt identificabile ca resurse secundare de ctre acel tip de media. De aceea furnizorii de reprezentri trebuie s gestioneze cu grij negocierea de coninut atunci cnd aceasta este utilizat pentru un URI ce conine un identificator de fragment. Pe de alt parte, autorii de coninut Web pot folosi noile formate de date cu condiia s asigure compatibilitate rezonabil pentru agenii care nu le-au implementat nc.
Inconsistene ntre reprezentrile de date i metadate
Reuita comunicrii ntre doi corespondeni depinde de partajarea rezonabil ntre acetia a semanticilor mesajelor, coninnd att date ct i metadate, pe care le schimb ntre ei. n practic au fost observate o serie de inconsistene posibile ntre datele i metadatele transportate de un mesaj. n aceste cazuri agenii sunt responsabili cu detectarea inconsistenelor i cu executarea de operaii corespunztoare pentru recuperare. Pe de alt parte i furnizorii de reprezentri sunt responsabili de asignarea corect a metadatelor. Astfel, acurateea metadatelor se bazeaz pe administratorii de servere, pe autorii de reprezentri i pe componentele software utilizate pentru extragerea i prelucrarea acestora.
Interaciuni sigure
O interaciune sigur este cea n care agentul nu-i asum nici o alt obligaie n afara interaciunii propriu-zise. Un agent i poate asuma o obligaie prin alte mijloace, ca de exemplu semnarea unui contract. Altfel spus, dac un agent nu are o anumit obligaie nainte de o interaciune sigur, atunci el nu are acea obligaie nici dup realizarea interaciunii respective. O interaciune sigur se poate obine, de exemplu, prin utilizarea metodei HTTP GET. Interaciunile nesigure11 seamn mai mult cu ordinele dect cu interogrile i pot cauza schimbarea strii unei resurse, schimbare pentru care utilizatorul este responsabil. 1.2.6 Gestiunea reprezentrilor Proprietarul unui URI poate oferi zero sau mai multe reprezentri ale resursei identificate de acesta. Totui exist cazuri n care referirea unui URI nu trebuie s nsemne i extragerea unei reprezentri asociat acestuia. Dereferirea unui URI induce costuri potenial semnificative legate de operaii de calcul i de lrgime de band necesar transferului n reea, poate avea implicaii legate de securitate i poate impune o laten semnificativ aplicaiei. De aceea acest operaie trebuie evitat de cte ori este posibil. ncrederea n interaciunile din Web depinde de stabilitate i predictibilitate. Persistena unei resurse de informaii depinde de consistena reprezentrilor. Termenul de persisten URI descrie proprietatea prin care un URI asociat unei resurse o va identifica pe termen nelimitat. De aceea i reprezentrile acelei resurse trebuie s fie consistente i predictibile. Un exemplu de suport pentru consistena reprezentrilor este redirectarea HTTP, care permite serverelor s informeze agentul despre eventuale aciuni suplimentare ce trebuie realizate de agent n vederea rezolvrii cererii. Negocierea coninutului promoveaz de asemenea consistena,
11
Nu nseamn c sunt periculoase i pot fi acceptate ca atare. 19
deoarece un manager de site nu trebuie s defineasc un nou URI odat cu adugarea de suport pentru o nou specificaie de format. 1.2.7 Structura informaiilor pe site-uri Web Coninutul site-urilor Web este organizat ntr-o o structur ierarhic. Aceast structur se reflect n coninutul paginilor Web sub form de hipertext i hipermedia. Hipertextul este o manier de organizare a documentelor text dup un model ierarhic. Ierarhia conine documente i legturi ntre acestea. Legturile specificate n interiorul documentelor i se numesc hiperlegturi (hyperlink). Specificarea unei hiperlegturi se face utiliznd URL-ul corespunztor resursei legate. Hipermedia este o manier de organizare a documentelor media (grafic, audio, video, etc.) dup un model ierarhic i reprezint o extindere a hipertextului cu elemente de multimedia. Pentru a accesa informaii organizate conform modelului ierarhic, URL are o sintax specific ce evideniaz resurse i subresurse. n varianta clasic, resursele sunt fiiere tip text sau media. n cazul arhitecturilor ce extind funcionalitatea arhitecturii Web clasice resursele pot fi i fiiere ce conin cod executabil. Exist posibilitatea rafinrii identificrii informaiilor prin specificarea paragrafelor dintr-un document text. Sintaxa general a unui URL devine n acest caz:
protocol://serviciu (proces).maina/cale/fiier#paragraf
Urmtorul exemplu identific primul capitol dintr-un document numit curs1.html aflat pe calea /cursuri/cursSO a mainii unSite din domeniul ro pe care activeaz serviciul www.
http://www.unSite.ro/cursuri/cursSO/curs1.html#cap1
1.3 Formate de date

O specificaie pentru un format de date (ex. XHTML, RDF/XML, SMIL, XLink, CSS i PNG) conine un acord asupra interpretrii corecte a reprezentrii datelor. Primul format de date utilizat n Web a fost HTML. n prezent arhitectura Web nu impune nici o restricie asupra formatului datelor utilizate de furnizorii de coninut. Aceast flexibiltate suport evoluia constant a aplicaiilor, n sensul introducerii de noi formate de date sau al rafinrii celor existente. Corespondenii care schimb informaii ntr-un anume format de date trebuie s fie n consens referitor la sintaxa i semantica acestora. Acest lucru nu impune ns restricii asupra utilizrii acestor date. n continuare sunt descrise cteva caracteristici ale unui format de date, care i faciliteaz integrarea n arhitectura Web. 1.3.1 Formate binare i textuale pentru date Formatele binare sunt cele obinute prin codificarea datelor realizat n vederea utilizrii directe de ctre procesoare. Un format textual este cel n care datele sunt specificate ntr-o codificare definit ca secven de caractere. Un format textual nu implic utilizarea unui tip de
20
media care ncepe cu text/ ci poate fi i un format bazat XML. n principu, toate datele pot fi reprezentate n format textual. n practic anumite tipuri de coninut (ex. audio sau video) sunt reprezentate, n general, utiliznd formate binare. Formatele binare sunt n mod substanial mai compacte, pe cnd cele textuale au avantajul portabilitii i interoperabilitii precum i cel al apropierii de percepia uman. Alegerea unui tip pentru un format de date este fcut de proiectanii specificaiei pentru formatul datelor i se bazeaz pe studii cantitative ale compromisului ntre cele dou tipuri. 1.3.2. Hipertext O caracteristic definitorie a Web-ului este aceea c permite includerea de referine la alte resurse prin identificarea acestora cu URI. Legturile hipertext utilizez identificator URI absolut(<a href="http://www.unSite.ro/curs#c1">) sau relativ(<a href="curs#c1">). O hiperlegtur de tip XLink)12 poate conine i metadate. Este de remarcat faptul c o hiperlegtur reprezint o relaie i nu o conexiune fizic. Pentru flexibilitatea unei aplicaii se recomand utilizarea URI-urilor pentru exprimarea de legturi chiar i ntre elemente interne documentelor i, de asemenea, folosirea de URI-uri generice, neconstrnse de o a numit schem. Formatele de date utilizate n interfee bazate pe paradigma hipertext trebuie s permit autorilor crearea de hiperlegturi. Cele care nu ofer acest posibilitate conduc la crearea de noduri terminale n Web. Referine URI Legturile sunt exprimate prin referine URI care pot fi combinate cu un URI de baz pentru a se obine o referin utilizabil. Agenii rezolv referina URI iar rezultatul este folosit pentru a interciona cu un alt agent. Acest model al interciunii permite proiectarea local a reprezentrilor, fr ca autorul s fie preocupat de identificatorul global ce va fi folosit pentru a referi ulterior resursa asociat. 1.3.3. Formate de date bazate pe XML Formatele de date bazate pe XML se conformeaz regulilor sintactice definite n specificaia XML. XML definete formate textuale care se potrivesc n mod natural cu descrierea obiectelor procesate ierarhic ntr-o secven aleas. Modelul este larg aplicat dar nu se potrivete oricrui tip de formate de date (ex. formate audio sau video). Restriciile de proiectare specifice formatelor bazate pe XML sunt reprezentate de urmtorul set de cerine pentru datele ce vor fi reprezentate n aceste formate: - structur iererhic, - instrumente pe o larg varietate de platforme, - supravieuirea n raport cu aplicaiile care le proceseaz n mod curent, - abilitatea de a suporta internaionalizarea ntr-o manier autodescriptiv astfel nct s nu poat apare confuzie la opiunile de codificare, - detectarea timpurie a erorilor de codificare fr necesitatea de a le rezolva, - proporie nsemnat de coninut textual destinat a fi citit de utilizatorul uman,
12
Mecanism generic de legare folosit de limbaje bazate XML (v. cap. 4).. 21
potenial de compunere a formatului de date cu alte formate codificate XML, - uor de analizat lexical att de ctre main ct i de ctre utilizatorul uman, - vocabulare care s poat fi inventate n maier distribuit i cu flexibilitate combinat. Mecanismul XPointer are rolul de a permite realizarea de legturi pentru adresarea de coninut care nu are o ancor explicit i identificat cu nume. Mecanismul XLink este o specificaie pentru reprezentarea legturilor n aplicaii XML hipertext. Acesta permite ca o legtur s aib destinaii multiple i s poat fi exprimat fie in-line fie bazat pe informaii externe uneia sau tuturor resurselor identificate de legturile pe care le conine. Un spaiu de nume XML permite utilizarea de vocabulare (n care sunt definite nume de elemente i de atribute) ntr-un mediu global, astfel nct s reduc riscul coliziunilor de nume din interiorul documentelor ce folosesc combinaii de vocabulare. Ca orice resurs Web, fiecare spaiu de nume este identificat printr-un URI. Dac dou specificaii diferite (ex. MathML i SVG) utilizeaz acelai nume n definirea unui element (ex. set), fiecare utilizare a numelui respectiv trebuie nsoit de precizarea specificaiei la care se face referirea, prin URI-ului spaiului de nume corespunztor acesteia. URI-ul unui spaiu de nume poate fi folosit pentru a identifica o resurs de informaii care conine informaii utile, fie pentru maina de calcul fie pentru utilizatorul uman, despre termenii din spaiul de nume. Aceast resurs de informaii este documentul spaiului de nume13, care este valabil i autoritar pentru acesta. Un astfel de document ofer informaii despre scopul spaiului de nume, modul de utilizare a vocabularului de marcare din spaiul de nume, cine controleaz spaiul de nume, ce politici i sunt asociate, cum se solicit accesul la schem sau la materiale colaterale, posibilitile de raportare a unor probleme legate de utilizarea spaiului de nume. De asemenea, tot n acest document de afl informaii ce pot fi utilizate de procesoare pentru a extrage o schem de validare, o foaie de stil pentru prezentare sau o ontologie pentru a face raionamente. Formatele datelor utilizate n crearea de reprezentri ale resurselor de tip document al spaiului de nume ca i faptul c informaiile apar direct n reprezentare sau sunt referite din aceasta, sunt influenate de aplicaiile ce le utilizeaz. Exemple de formate de date pentru documente ale spaiilor de nume sunt OWL, RDDL, XMLSchema, XHTML. Fiecare ndeplinete cerinele descrise mai sus pentru a satisface cerina unui agent pentru informaii suplimentare despre spaiul de nume. QNames este o construcie sintactic pentru exprimarea compact a numelor calificate n documente XML. Un nume calificat este o pereche format dintr-un URI care indic un spaiu de nume i un nume local plasat n acel spaiu de nume. QNames sunt n general folosite n contextul numelor de atribute i elemente. Exist propuneri pentru utilizarea lor n valorile atributelor sau n coninutul elementelor dar n aceste cazuri nu pot fi folosite mpreun cu URI-uri deoarece nu se pot distinge de acestea. Deoarece QNames sunt compacte, unele specificaii au adoptat sintaxe identice cu cele pentru identificarea resurselor. Totui QNames nu pot nlocui URI ca sistem de identificare n Web. Utilizarea de QNames pentru a identifica resurse Web 13
Namespace document. 22
trebuie s fie nsoit de o mapare a acestora n URI-uri, pentru a fi consistent cu arhitectura Web. Un identificator de element este definit n declaraiile DTD sau XMLSchema care au valoarea ID pentru atributul name. RFC 3023 definete tipurile media pentru Internet application/xml i text/xml14 i descrie o convenie prin care formatele de date bazate XML utilizeaz tipuri media Internet cu sufixul +xml (ex. image/svg+xml). Semanticile identificatorilor de fragment specifice fiecrui format sunt definite de proiectanii formatelor de date bazate pe XML. XPointer Framework ofer un punct de plecare interoperabil pentru acetia. Nu se vor folosi identificatori de fragment dac tipul media asignat reprezentrii este application/xml sau dac are sufixul +xml, deoarece n aceste cazuri nu sunt definite semantici pentru identificatorii de fragment. Exist propuneri de normative pentru ca identificatoare de fragment de forma #abc s identifice elementul cu ID-ul abc al documentului XML referit. 1.3.4. Versiuni i extensibilitate Extensibilitatea i versiunile multiple sunt strategii de gestionare a evoluiei naturale a informaiilor din Web i a tehnologiilor de reprezentare a acestora. De aceea fiecare specificaie pentru un format de date trebuie s fie nsoit i de un numr de versiune. De asemenea, este ncurajat dezvoltarea de limbaje ce s permit o anumit form de extensibilitate care s nu necesite modificarea numelui spaiului de nume utilizat. Aceast extensibilitate este limitat de un set de restricii asupra modificrilor posibile n spaiul de nume, limitare necesar realizrii de implementri stabile. Posibilitile de extindere trebuie s rmn n cadrul conformanei cu specificaia original. De asemenea, o specificaie trebuie s indice comportamentul agentului n faa unor extensii pe care nu le recunoate. Acesta poate fi de ignorare a oricrui coninut nerecunoscut sau de tratare a acestuia ca pe o eroare. 1.3.5. Compoziie i formate de date Majoritatea formatelor de date includ mecanisme pentru compoziie. De exemplu, este posibil nglobarea de comentarii text n unele formate de imagini. Exist formate container, cum ar fi SOAP, care pot include coninut din spaii de nume multiple, dar care ofer o relaie semantic de ansamblu a elementenlor unui mesaj. De asemenea, sunt bine definite semanticile combinrii documentelor RDF care conin vocabulare multiple. n principiu, aceste relaii pot fi mixate i incluse n mod arbitrar. De exemplu, un mesaj SOAP poate conine o imagine SVG care conine un comentariu RDF ce se refer la un vocabular de termeni pentru descrierea imaginii. Totui, pentru XML n general nu exist un model semantic care definete interaciunile din interiorul documentelor XML cu elemente i/sau atribute dintr-o varietate de spaii de nume. Fiecare aplicaie trebuie s defineasc modul n care spaiile de nume interacioneaz i ce efect are spaiul de nume al unui element asupra ancestorilor, vecinilor i descendenilor elementului.
n general, furnizorii de reprezentri vor evita asignarea de tipuri media care ncep cu "text/" (pentru care este permis transcodarea de la o codificare la alta) la reprezentri XML care trebuie s fie autodescriptive. 23
14
1.3.6
Separarea ntre coninut, prezentare i interaciune
Web-ul este un context eterogen n care agenii ofer utilizatorilor acces la coninut. Autorii sunt interesai n a crea coninut pentru o audien ct mai larg n sensul diversitii dispozitivelor de preluare i prezentare a informaiilor: calculatoare de birou cu interfee grafice, dispozitive manuale, telefoane mobile, dispozitive pentru persoane cu disabiliti sau dispozitive ce urmeaz a fi proiectate n viitor. De asemenea, nu pot fi cunoscute n momentul crerii coninutului toate tipurile de prelucrri pe care le vor face agenii n vederea prezentrii acestuia. Soluia pentru flexibilitate este dat de separarea coninutului de prezentarea lui i de interaciuni, ca principii ortogonale. Aceasta are ca rezultat reutilizarea i independena de dispozitive a coninutului. Recombinarea acestor principii este realizat de ageni care utilizeaz un spectru ce variaz de la recombinare integral la client la recombinare exclusiv la server. Recombinarea la server are avantajul informaiilor puine, dedicate, transferate n reea, dar nu permite agenilor client s execute operaii care nu au fost anticipate de autor. Pe de alt parte, recombinarea la client ofer o reutilizare mai robust i care se poate adresa unei audiene mai largi, avantaj pltit cu transferuri importante de informaii de la server. Decizia de proiectare se face funcie de puterea de calcul de la client, de ncrcarea i de puterea de calcul de la server i de lrgimea de band oferit de mediul prin care acestea se conecteaz. Scalabilitatea unei aplicaii (referitor la numrul de clieni acceptai) este mai bun dac este mrit ncrcarea de calcul la client. Pe de alt parte, se poate dori limitarea accesului clienilor, lucru realizat prin tehnologii de encriptare i prin metode de control a accesului. Unele formate de date, cum ar fi SVG, XSL Formating Objects, sunt destinate descrierii prezentrii, caz n care prezentarea este inclus n coninut. Pentru a respecta principiul specificaiilor ortogonale este necesar ca aceste formate de date s se refere doar la elemente de prezentare. Formatele de date permit crearea de noi aplicaii care s utilizeze infrastructura spaiului informaional. Una din aplicaiile semnificative este Web-ul Semantic, construit peste RDF15.
1.4 Principiile generale ale arhitecturii Web

Urmtoarele principii se aplic pentru toate cele trei baze ale arhitecturii Web. 1.4.1. Specificaii ortogonale Identificarea, interaciunea i reprezentarea sunt concepte ortogonale. Tehnologiile specifice acestora evolueaz n mod independent. Astfel, resursele sunt identificate cu URI-uri care pot fi publicate fr a fi obligatorie existena reprezentrilor resursei. O sintax generic pentru URI permite agenilor s funcioneze fr a cunoate specificul schemelor URI. De asemenea, n multe cazuri, se poate schimba o reprezentare fr s fie afectate referinele la acesta (de ex. prin utilizarea mecanismului de negociere a coninutului).
15
Resource Description Framework (v. cap. 9). 24
Principul ortogonalitii spune c abstractizri ortogonale beneficiaz de specificaii ortogonale. Dac dou specificaii sunt ortogonale, fiecare se poate schimba fr a necesita modificri la nivelul celeilalte, chiar dac exist dependene ntre ele. De exemplu, dei specificaia HTTP depinde de specificaia URI, ele pot evolua n mod independent. Aceast ortogonalitate are ca efect creterea flexibilitii i robusteei n Web. De exemplu, se poate referi o imagine cu un URI fr a se cunoate formatul ales pentru reprezentarea acesteia. Acest lucru a facilitat introducerea de noi formate de imagine (PNG i SVG), fr a afecta referinele la resursele respective. Din experien s-a observat c pot s apar probleme atunci cnd conceptele ortogonale apar n aceeai specificaie sau cnd specificaiile ncearc s modifice abstractizri ortogonale descrise n alt parte. O prim etap n soluionarea acestor probleme este condiia ca o specificaie s indice n mod clar caracteristicile care se suprapun cu cele guvernate de o alt specificaie. 1.4.2. Extensibilitatea Informaiile din Web i tehnologiile utilizate pentru reprezentarea lor sufer modificri continue. Extensibilitatea este acea proprietate a unei tehnologii care promoveaz evoluia acesteia, fr a sacrifica interoperabilitatea ei. Exemple de proiectare care ofer acest proprietate sunt: - specificarea ortogonal a schemelor URI, - utilizarea unui set deschis de tipuri media Internet n mail i HTTP, pentru a specifica interpretarea documentului, - separarea gramaticii generice XML i setul deschis de spaii de nume XML pentru numele de elemente i de atribute, - extensibilitatea modelelor n CSS, XSLT1.0 i SOAP, - utilizarea de plug-in la agenii utilizator. n continuare ne referim la proprietatea de extensibilitate expus de URI, de unele formate de date i de unele protocoale (prin incorporarea de mesaje noi). Un limbaj este un limbaj subset, subset (sau profil) al altui limbaj numit limbaj extins (sau superset) n acest relaie, dac orice document scris n limbajul subset este un document valid i are aceeai interpretare i n limbajul extins. Diferena dintre cele dou limbaje se numete extensie. Pentru a pstra interoperabilitatea, se prefer extinderea unui limbaj i nu crearea unuia nou. n mod ideal, multe instane ale limbajului superset pot fi procesate ca i cum ar aparine limbajului subset. Limbajele care evolueaz astfel, permind aplicaiilor s ofere informaii noi atunci cnd este necesar i n acelai timp s interopereze cu aplicaii care neleg doar un subset al limbajului, se numesc limbaje extensibile. Extensibilitatea poate fi facilitat de ctre proiectanii de limbaje prin definirea unui comportament implicit pentru extensiile pe care nu le recunosc (ex. le ignor sau le trateaz ca erori). 1.4.3. Gestionarea erorilor Erorile pot fi bine caracterizate (ex. erori de formare corect n XML) sau pot s apar n mod impredictibil. Corectarea erorilor se definete ca fiind aciunea agentului de a soluiona problema astfel nct apariia acesteia s fie transparent la nivelul sistemului. Un exemplu de corectare eroare este retransmiterea datelor n cazul unei cderi temporare n reea. Recuperarea din eroare se refer la
25
comportamentul unui agent care nu soluioneaz problema ci continu procesarea cu indicarea faptului c s-a produs o eroare. n mod frecvent agenii corecteaz erori de transmisie n reea. Pe de alt parte, este la fel de important ca agenii s realizeze recuperarea din eroare ntr-un mod care s fie evident utilizatorului, deoarece ei acioneaz n numele acestuia. Pentru a nu ntrerupe utilizatorul la apariia necesitii de confirmare sau selecie din partea acestuia a unei anumite soluii propus de agent, utilizatorul poate indica n prealabil deciziile sale pentru diferite cazuri prin setri de configurare a agentului. Agentul va aciona conform acestor opiuni i va raporta utilizatorului apariia erorilor. Pentru a susine interoperabilitatea, proiectanii de specificaii trebuie s identifice condiiile de eroare predictibile. 1.4.4. Interoperabilitate bazat pe protocol Interfeele eseniale din Web sunt definite n termeni de protocoale prin specificarea sintaxei, semanticilor i restriciilor de secveiere a mesajelor interschimbate. Protocoalele utilizate sunt flexibile, asfel nct au permis extinderea Web-ului n medii foarte variate i au facilitat comunicarea peste granie multiple. Interfeele tradiionale de programare a aplicaiilor (API) nu iau n considerare ntotdeauna aceste restricii i nici nu este necesar. Unul din efectele proiectrii bazat pe protocol este acela c tehnologia partajat de ageni dureaz de cele mai multe ori mai mult dect agenii nii. Programatorii lucreaz n general direct cu cod care prelucreaz i genereaz direct aceste mesaje. Ele sunt rareori expuse ca atare i utilizatorilor finali, dei acest lucru prezint avantajul c acetia pot cpta abiliti de a lucra cu sistemul platform16.
16
Underlying system. 26
2. HTML
Acest capitol cuprinde principalele concepte ale modelului DOM i extensia DOM-HTML a acestuia . Este apoi descris limbajul HTML i foile de stil din DHTML, ca metode de programare a paginilor Web statice.
2.1 Modelul DOM-HTML

2.1.1 Modelul Document- Obiect (DOM) DOM (Document Object Model) este un model de date i un API independente de limbaj. Interfaa de programare a aplicaiilor (API) este destinat accesului programatic i manipulrii XML i HTML. Spre deosebire de instanele XML i schemele XML care sunt memorate n fiiere pe disc, DOM este o reprezentare n memorie a documentului. Necesitatea acestei reprezentri a derivat din diferenele dintre modul n care diferite navigatoare permit accesarea i manipularea documentelor dinamice. Unificarea este realizat printr-o reprezentare standard n memoria navigatorului pentru obiectele din document. Modelul acestei reprezentri este cel din programarea OO. Astfel, DOM se definete ca un model de date care utilizeaz obiecte pentru a reprezenta un document XML sau HTML. Programarea OO introduce dou concepte cheie n modelarea datelor: clasele i obiectele. Clasa este o definiie prin care sunt descrise caracteristicile i comportamentele unei entiti sau concept din lumea real. Pe baza acestei descrieri se pot construi n memorie instane ale clasei numite obiecte. Principalul avantaj al acestei abordri n modelarea datelor este este acela c limbajul de programare necesar prelucrrii acestora este mai apropiat domeniului problemei ce trebuie soluionat n programul respectiv. Modelul obiect din cadrul metodologiei OO specific interfee i obiecte. Modelul definete semantica interfeelor i obiectelor, comportamentul interfeelor i obiectelor, atributele interfeelor i obiectelor i relaiile i dependenele ntre interfee i obiecte. DOM (Document Object Model) este o particularizare, pentru domeniul obiectelor de tip document, a modelului obiect din cadrul metodologiei OO. DOM conine specificaiile interfeelor i obiectelor utilizate s reprezinte i s manipuleze documente, specificaii care definesc semantica, comportamentul, atributele, relaiile i dependenele ntre interfeele i obiectele utilizate s reprezinte i s manipuleze documente. DOM conine definiii pentru o interfa de programare a aplicaiilor care prelucreaz documente HTML i XML. Acestea prezint o modalitate structurat de a accesa i modifica coninutul paginilor Web, care sunt colecii de elemente. Specificaia DOM este independent de platform i de limbaj. Ea definete structura logic a documentelor, ca fiind obiectual i arborescent, i reguli pentru accesarea i modificarea lor. Modelul ofer o perspectiv structurat asupra documentului, o manier de specificare a comportamentului documentului i o manier de specificare a comportamentului obiectelor componente ale documentului. Componentele modelului sunt obiecte cu identitate i funcii. DOM poate fi vzut ca un set de clase care permit crearea n memorie a unei structuri arborescente de obiecte care reprezint o versiune a documentului (XML
27
sau HTML) ce poate fi manipulat ca atare. Obiectele acestei structuri pot fi accesate n dou moduri: generic i specific. n cazul accesului generic prile documentului sunt obiecte ale aceleiai clase (de acelai tip), numit Node. Acest mod ofer o perspectiv aplatizat, deoarece nu utilizeaz motenirea. Node
Node
Node
Node
Node
Node
Node
Fig.2.1 DOM ca arbore de noduri
Maniera specific de acces utilizeaz subclase specifice ale clasei Node pentru fiecare parte major a documentului (document, fragment, atribut, text sau comentariu).
Document
Element
Element
Element
Text
Element
Comment
Fig.2.2 DOM ca arbore de subclase
DOM a evoluat continuu prin extinderea detaliilor de reprezentare, prin creterea domeniului reprezentrilor i prin adugarea de noi metode de manipulare. Modelul are mai multe nivele. Nivelul fundamental este DOM Core care specific interfeele fundamentale ale modelului. Nivelele superioare ofer specificaii mai complexe pentru definire unui model structural pentru submulimile elementelor interne i externe ale documentelor, pentru validarea prin intermediul schemelor (XML Schema), pentru controlul reprezentrii documentelor prin foi de stiluri (CSS, XSL sau alt limbaj pentru specificare stiluri), pentru controlul accesului, pentru sigurana n execuie i pentru lucrul cu evenimente. DOM Level 1 este compus din setul claselor pentru reprezentarea documentelor XML 1.0 i HTML 4.0. DOM Level 2 extinde primul nivel cu suport pentru spaiile de nume, foi de stil (CSSS2), pesrpective alternative, evenimente de interfa utilizator i manipulare a structurii arborescente prin interfee pentru traversare i domenii. Foile de stil pot fi incluse n documente HTML sau XML n elemente style i este prevzut o metod pentru a ataa stiluri la nivel de element din document. Un document poate avea perspective alternative ale modelului DOM dup aplicarea foilor de stil. Evenimentele la interfaa cu utilizatorul sunt declanate de un utilizator (ex. manevre mouse sau tastatur) sau de alte componente software
28
(ex. ncrcare pagin Web). Traversrile se fac pe baza unor metode suplimentare de vizitare a arborelui, NodeIterator i Tree Walker, corespunztoare travesrii perspecivei aplatizat, respectiv ierarhic. Un domeniu permite o selecie de noduri ntre dou puncte de limitare. DOM Level 3 extinde nivelul 2 cu suport pentru vocabulare mixte (din spaii de nume diferite), expresii XPath, metode load i save i o reprezentare a schemelor abstracte. XPath este utilizat pentru selectarea unui set de noduri ale unui document. Metodele load i save specific modalitile standard pentru ncrcarea unui document XML ntr-o reprezentare DOM i pentru salvarea unei reprezentri DOM ntr-un document XML. Schemele abstracte ofer clase pentru reprezentarea schemelor i a operaiilor asupra schemelor. Pe scurt, DOM este o reprezentare intern a unui document XML sau HTML nsoit de metode pentru manipularea ei. DOM poate fi ncrcat din document XML, salvat n documente XML sau generat dinamic de ctre un program. DOM este reprezentat sub forma unui set de interfee i a unui limbaj sepcific de conectare la acestea. 2.1.2 Modelul DOM HTML Modelul DOM-HTML este derivat din DOM Core, fiind extins pentru definirea documentelor HTML. Pe lnga funcionalitatea necesar manipulrii structurilor ierarhice de documente, elementelor i atributelor, DOM-HTML reprezint o specializare a DOM API care adaug funcionalitate specific documentelor i elementelor HTML. De asemenea, grupeaz, sub form de mecanisme specifice, operaii comune i frecvente asupra documentelor HTML. Iat un exemplu de document HTML
<HTML> <HEAD> </HEAD> <BODY> <!> <HR> <UL> <LI> continut 1 <LI> continut 2 </BODY> </HTML>
i reprezentarea sa conform modelului DOM HTML:

HTML <!DOCTYPE>
<HEAD>
<BODY> <!...> <HR> <UL> <LI> <LI> coninut 1 coninut 2
Fig.2.3 Reprezentarea DOM HTML a unui document HTML 29

Specializarea DOM pentru HTML ofer interfeele HTMLDocument, HTMLElement, HTMLCollection i HTMLOptionsCollection, precum i extensii ale interfeei HTMLElement corespunztoare specificaiilor HTML care definesc tipurile de elemente, marcate cu tag-uri, ce pot fi coninute n documente HTML. Interfaa HTMLDocument este derivat din DOMDocument i conine operaii i interogri specifice pentru documente HTML. Interfaa HTMLElement conine operaii i interogri specifice pe elementele documentului HTML, inclusiv metode de tip set() i get() pentru atributele elementelor. Specializrile interfeei HTMLElement definesc tipurile elementelor coninute n documentele HTML. Interfaa HTMLCollection reprezint o list abstract format din noduri identificate fie prin index fie prin nume. Interfaa HTMLOptionsCollection reprezint o list abstract format din noduri ce conin opiuni HTML identificate prin index, prin nume sau prin id. Ierarhia de obiecte DOM-HTML este reprezentat n figura x.4. Prin proprietatea elements a documentului se ofera acces la orice element de pe pagin.
frames window document frame document
document
elements anchors applets objects frames images links plugins
form
text textarea radio
an
checkbox select button options
Fig.2.4 Ierarhii de obiecte DOM-HTML

forms
Foile de stil utilizeaz o alt ierarhie de obiecte pentru elementele din pagin asupra crora acioneaz. Aceasta consider tipurile de elemente, identificate cu taguri, cu clase sau cu identificator de tip id, fr a evidenia relaiile logice dintre acestea.
30
document
tags
all P DIV SPAN H1, H2, H6 etc
an
classes
all nume tag-uri
ids
Fig.2.5 Ierarhii de obiecte DOM-HTML pentru foi de stil
Standardul definit de W3C permite acces la orice tag i la orice atribut de configurare al acestuia, ofer independen fa de limbaj, independen fa de mediul grafic al clientului, i asigur securitatea agentului utilizator.
2.2 HTML (HyperText Markup Language)

2.2.1. Elementele limbajului HTML HTML este un limbaj simplu pentru definirea paginilor Web. O pagina Web este un un obiect de tip document, care conine la rndul lui obiecte din ierarhia de obiecte DOM-HTML. Elementele limbajului HTML sunt tag-uri (elemente de marcare, numite i etichete) utilizate pentru a descrie obiectele componente ale documentului17. Sintaxa general a unui tag este <nume_tag>. Semantica tag-ului este sugerat de numele acestuia i este definit n specificaiile HTML. Ea este recunoscut de componenta agentului utilizator responsabil cu interpretarea codului HTML. Pagina HTML este, la rndul ei, un obiect. Marcarea unui obiect de tip document HTML se face cu tag-ul HTML astfel:
<HTML> obiectul document </HTML>
Un document HTML se conformeaz unei structuri format din dou componente de baz: antet, a crui prezent este opional, i coninut. Structura general a unei pagini Web este urmtoarea:
Exista cateva exceptii de tag-uri HTML care nu definesc obiecte ci caracteristici de reprezentare a obiectelor text: CENTER, EM, B, U. 31
17
<HTML> <HEAD> obiectul antet </HEAD> <BODY> obiectul coninut pagin Web </BODY> </HTML>
Fiecare component a documentului HTML poate fi format din mai multe obiecte de diferite tipuri. Obiectul antet poate conine obiecte de tip titlu, metainformaii, definiii de stil i cod de funcii n limbaj de scripting. Obiectul coninut pagin Web este, de asemenea, o colecie structurat de obiecte de diferite tipuri, subtipuri ale interfeei HTMLElement definit n modelul DOM-HTML. Un obiect are un tip i o colecie de atribute prin care se definesc proprietile lui. Fiecare tag are un nume care corespunde unui tip de obiect i un set de atribute corespunztoare atributelor obiectelor de tipul respectiv. Pentru a specifica tipul obiectului coninut, acesta este marcat cu tag-ul corespunzator, iar pentru a specifica proprietile obiectului se atribuie valorile corespunztoare atributelor ataate tag-ului. Formatul general pentru specificarea unui obiect al unui document HTML este urmtorul: <nume_tag De exemplu, tipul de obiect coninut pagin Web este marcat cu tag-ul cu nume_tag = BODY care are atributele:
LINK culoarea pentru hiperlegtur (link) normal ALINK culoarea pentru hiperlegtur activ VLINK culoarea pentru hiperlegtur utilizat BACKGROUND culoare fundal BGCOLOR culoare TEXT culoare text
atribut1=val1 atribut2=val2 atributn=valn>
Pentru a defini un coninut de pagin Web la care culoarea textului este rou iar hiperlegturile active sunt scrise cu albastru se folosete18:
<BODY TEXT=RED ALINK=BLUE> coninut pagin Web </BODY>
Restul atributelor iau valori implicite.

18
Reprezentarea valorilor pentru culoare se poate face fie cu nume (RED, BLUE, etc.) fie utiliznd un cod hexazecimal corespunztor culorilor RGB ( #rrggbb ex. FFFFFF alb). 32
Tag-urile pot fi grupate pe mai multe categorii de funcii. Exist tag-uri pentru structurarea coninutului, cum ar fi tag-uri pentru specificarea de titluri de diferite nivele (H1, H6), pentru aliniere text (CENTER), pentru definire de liste (UL, LI sau OL, LI). De asemenea, exist tag-uri specializate n structurarea coninutului sub form de tabele (TABLE, TR, TH, TD), iar fiecare dintre acestea are un set de atribute printre care se numr atribute pentru aliniere (ALIGN), definire culoare (xxxCOLOR), definire contur (BORDER), spaiere ntre celule (CELLSPACING), distribuire coloane (COLSPAN), etc. Exist, de asemenea, tag-uri pentru evideniere coninut, care marcheaz obiecte de tip text cu caracteristici de afiare speciale. Acestea sunt EM pentru scriere cursiv, U pentru subliniere i B sau STRONG pentru supraimprimare. O alt categorie de tag-uri sunt utilizate pentru specificare de hiperlegturi, referine la alt document sau paragraf sau la un obiect de alt tip (ex. Obiect grafic). De exemplu, <A HREF = url >text</A> indic o referin la o resurs identificat cu url, iar <IMG = imagine.gif WIDTH=valW HEIGHT=valH> indic o referin la o resurs ce reprezint un fiier care conine o imagine grafic n format GIF, imagine ce va fi afiat ntr-o zon cu dimensiunile specificate de atributele WIDTH (lime) i HEIGHT (nlime). 2.2.2. FORME Colectarea informaiilor client ce vor fi communicate la server se face n containere speciale, numie forme, n care se definesc controale de interfa grafic cu clientul (GUI). Containerele sunt marcate cu tag-ul FORM, conform urmtoarei sintaxe generale:
<FORM atribute> definiii obiecte de tip control </FORM> Urmtoarea construcie:
<FORM marcheaz o form ecran care conine obiecte de dialog cu utilizatorul utilizate pentru preluare de informaii ce vor fi transmise la server cu metoda POST. Prin valoarea atributului ACTION, de tip URL, se specific o component aflat pe server responsabil cu prelucrarea informaiilor culese n cmpurile formei. O form e constituit din orice combinaie de obiecte de tip INPUT, TEXTAREA, SELECT, BUTTON. Obiectele de tip INPUT au urmtoarea sintax general: <INPUT NAME=nume_obiect TYPE=tip VALUE=val SIZE=... MAXLENGTH= ... [CHECKED] [READONLY]>
33
NAME=nume_forma ACTION=url METHOD=POST>
Exist mai multe tipuri de obiecte INPUT. Tipul asociat unui anumit control INPUT este precizat n atributul TYPE al acestuia. Tipurile de controale pot fi: linie de text(TEXT), fiier(FILE), parol(PASSWORD), informaie ascuns (text care se transmite la server dar nu se vede n form)(HIDDEN), imagine(IMAGE), caset de marcare(CHECKBOX), set de butoane radio(RADIO), butoane pentru specificarea unei aciuni(SUBMIT, RESET). Obiectele de tip TEXTAREA reprezint o zon de preluare text care ocup mai multe rnduri i coloane.
<TEXTAREA NAME=nume-camp ROWS=nr_randuri COLS=nr_coloane [READONLY]> continut implicit al zonei de text </TEXTAREA>
Obiectele de tip SELECT includ o list de obiecte marcate cu tag-ul OPTION reprezentnd opiunile din care se face selecia. Unul din atributele tag-ului specific, dac e cazul, posibilitatea realizrii de selecii multiple.
<SELECT NAME=nume-camp SIZE=valoare MULTIPLE> <OPTION SELECTED VALUE="val_1"> Valoare_afisata_1 <OPTION VALUE="val_2"> Valoare_afisata_2 <OPTION VALUE="val_3"> Valoare_afisata_3 ... </SELECT>
Prin SELECTED specificat ca atribut al unui obiect OPTION se indic faptul c aceasta este selecia implicit. Valoarea atributului VALUE reprezint, ca i n cazul general, valoarea opiunii corespunztoare a obiectului de tip SELECT al formei, valoare referit n modelul DOM HTML al documentului din exemplu cu: document.nume_form.nume_select.options[index_opiune].value 2.2.3 CADRE (FRAMES) Definire cadre Cadrele sunt zone independente ale unei pagini Web, ce pot fi ncrcate separat19. Cadrele se pot defini in-line sau n cadrul unui container specializat marcat cu <FRAMESET>, care nlocuiete containerul BODY, conform urmtoarei structuri generale:
<HTML> <HEAD> obiectul antet </HEAD> <FRAMESET> obiectul set de cadre </FRAMESET> </HTML>
19
Sunt asemntoare unor ferestre distincte. 34
Definiia unui cadru se face cu tag-ul <FRAME>, care are ca atribute identificatorul cadrului (NAME), localizarea fiierului surs (SRC) pentru coninutul cadrului, specificat prin URL, i elemente de descriere a aspectului cadrului. Pentru acestea din urm se folosesc urmtoarele atribute: SCROLLING , NORESIZE i FRAMEBORDER de tip comutator( yes/no, 0/1), i MARGINWIDTH i MARGINHEIGHT cu dimensiuni specificate in numar de pixeli, n inch sau n centimetri. Cadrul in-line Pentru definirea unui cadru in-line se utilizeaz urmtoarea sintax general:
<IFRAME [name=frameName] [src=URL] [frameborder=1 sau 0] [marginwidth=nr.pixeli] [marginheigh=nr.pixeli] [scrolling=yes sau no] [align=bottom, middle, top, left sau right] [heigh=val][width=val] </IFRAME>
Obs. Valorile notate cu val se pot specifica n numr de pixeli, n procente sau sub form de raport ( nr*). Crearea unui set de cadre Un set de cadre este coninut ntr-un container specializat, marcat cu <FRAMESET>. Cadrele din container pot fi organizate orizontal i/sau vertical. Containerul <FRAMESET> conine o list cu definiiile cadrelor din set.
<FRAMESET [rows=rowWidths] [cols=colWidths] [loadEvents]> lista cu definitii de cadre </FRAMESET>
Pentru definirea unui cadru se utilizeaz tag-ul <FRAME> cu urmtoarea sintax general:
<FRAME SRC="url" NAME="myFrame" SCROLLING=YES|NO|AUTO MARGINWIDTH="value" MARGINHEIGHT="value" NORESIZE FRAMEBORDER=YES|NO BORDERCOLOR="value" >
Identificarea acestuia n document sa face cu "myFrame", atributului NAME. Urmtoarea secven de cod HTML:
<FRAMESET SCROLLING=YES COLS=v1%, v2%, , vn%> <FRAME SRC=url NAME=nume_f_1> <FRAME SRC=url NAME=nume_f_n> </FRAMESET>
valoarea
definete un set format din n cadre organizate pe n coloane, fiecare coloan ocupnd un procent egal cu vi din limea ferestrei de afiare. Mai general, ntr-un set de cadre se poate defini o gril de cadre orientate pe ambele direcii, dac se folosete o definiie de forma : <FRAMESET ROWS=v1%, v2%, , vn% COLS=v1%, v2%, , vm% >
35
sau dac se folosete incluziunea seturilor de cadre ca n exemplul urmtor:

<HTML> <FRAMESET ROWS="25%,50%,25%"> <FRAME SRC="header.htm"> <FRAMESET COLS="25%,75%"> <FRAME SRC="label.htm"> <FRAME SRC="info.htm"> </FRAMESET> <FRAME SRC="footer.htm"> </FRAMESET>
Unele navigatoare nu suport cadre. Pentru navigatoarele care nu recunosc cadrele este utilizat tag-ul <NOFRAMES>, cu care se marcheaz textul care va fi afiat n loc. Comunicarea ntre cadre Un cadru este identificat cu un nume (stabilit cu atributul NAME al definiiei) i conine o resurs localizat cu URL (specificat n atributul SRC al definiiei). Pe baza identificatoarelor de cadru se pot stabili relaii de comunicare ntre acestea. Un cadru este, n general, specificat ca destinaie pentru prezentarea unei resurse. Pentru precizarea cadrului destinaie se folosete atributul TARGET. Orice tag ce suport atributul TARGET poate s-i atribuie acestuia numele unui cadru. Utilizarea etichetei <BASE target = nume1> n antetul unei pagini va afia coninutul fiecrei hiperlegturi din aceasta n cadrul identificat cu nume1. Pentru a face o alegere a paginilor care se vor afia n cadrul respectiv se utilizeaz construcia <A href=url target=nume1>Link la url</A> pentru fiecare hiperlegtur la paginile ce trebuie afiate n cadrul identificat cu nume1. Astfel, daca un fiier HTML conine:
<A HREF=f1.html TARGET=nume_f_3> ... <A HREF=f7.html TARGET=nume_f_3>
atunci att f1.html ct i f7.html se vor afia n cadrul identificat cu nume_f_3. n tabela urmtoare sunt prezentate numele implicite pentru cadre particulare ntr-o ierarhie printe-descendent.
Nume implicit Tip cadru
Fereastra nou, fr coninut _blank Frame-ul apelant _self Frame-ul printe al frame-ului apelant _parent Frame-ul rdcin _top
36
2.2.4 HTML DINAMIC (DHTML) DHTML reprezint un set de standarde pentru crearea paginilor Web interactive i dinamice. Utilizarea DHTML permite acces dinamic la actualizarea coninutului paginii, a structurii acesteia sau a stilului documentului. Cu DHTML se creaz pagini modificabile autoconinute care i pot schimba coninutul fr cereri suplimentare la server, pe baza unui set local de informaii i aciuni. De asemenea, se realizeaz controlul stilurilor de afiare funcie de facilitile de la client ca i de preferinele acestuia. DHTML este standard al consoriului W3 bazat pe DOM (Document Object Model). Acesta ofer faciliti de navigare prin structura documentului i de manipulare a documentului. Pentru a-i realiza funciile dinamice, standardul definete modelul eveniment i modelul obiectului foaie de stil. De asemenea, permite obinerea de informaii generale despre document i despre navigator prin capacitatea de a examina obiecte nglobate (ex. cookies). Exist mai multe implementri ale standardului. Implementarea Netscape i adaug etichete noi i noi tipuri de seturi de caractere descrcabile. Implementarea Microsoft i adaug atribute noi la etichete i controale ActiveX pentru acces la baze de date. Structura documentului Un document DHTML conine unul sau mai multe containere. Ca i n cazul HTML, containerul BODY (sau FRAMESET) este singurul obligatoriu. Tipurile de containere ce pot s apar ntr-un document DHTML sunt antetul, corpul, stilul, scriptul i setul de cadre.
<HTML> <HEAD> ... <STYLE> obiecte de tip stil </STYLE> ... <SCRIPT> cod scripting (funcii) </SCRIPT> ... </HEAD> <BODY> ... <SCRIPT> cod scripting </SCRIPT> ... </BODY> </HTML>
Antetul este marcat cu <HEAD> i conine informatii despre document. Corpul este marcat cu <BODY> i conine obiectele afiabile din pagina Web. Containerul pentru stil este marcat cu <STYLE> i conine definiiile stilului de afiare pentru pagina respectiv. Containerul marcat cu <SCRIPT> conine cod de scripting pentru definirea de activiti dinamice iniiate de interaciunea cu utilizatorul. Setul de cadre
37
este marcat cu <FRAMESET> i conine definiii de cadre multiple n acelai document. Containerele de tip stil sunt incluse n antet iar cele de tip script pot s apar fie n antet, fie n corpul documentului. 2.2.5 FOI DE STIL (SS Style Sheets) Foile de stil conin grupuri de proprieti care definesc aspectul unui document HTML. Utilizarea lor reprezint o modalitate de a separa forma de prezentare a unui document de coninutul acestuia, ceea ce conduce la independen fa de platforma i de agentul utilizator al clientului. Foile de stil pot fi folosite pentru a unifica prezentarea unui grup de documente ale unui site Web. Au fost standardizate dou nivele de definire a aspectului. CSS1 conine specificaiile nivelului pentru definire font, culoare i spaiere. CSS2 este un nivel superior care suport motenirea foilor, permite definire de efecte vizuale, poziionri i paginri, integrarea diverselor tipuri de media (ex. sunet). n prezent se lucreaz la CSS3. n HTML exist o serie de tag-uri utilizate pentru formatarea textului cu stiluri fizice. Acestea permit control asupra detaliilor de aspect ale paginii. Principalele taguri din aceast categorie sunt <I>, <B>, <U> pentru formatare general, <BIG>, <SMALL> pentru stabilire dimensiune caractere, <STRIKE>, <S>, <DEL> pentru text neactual, <TT> pentru caractere de lime egal, <SUP>, <SUB> pentru indicare super/subcript, <FONT>, <BASEFONT> cu atributele FACE pentru tipul de caractere, SIZE pentru dimensiune i COLOR pentru culoare. Modelul de formatare a unei entiti din document Orice entitate din document este modelat, n vederea aplicrii definiiilor de stil, sub form de casete incluse. Zonele exterioare coninutului propriu-zis sunt opionale. Acestea sunt zona de protecie (padding area), zona de bordur (border area) i zona de margine (margin area).
margin edge zon de margine (margin) zon de bordur (border) zon de protecie (padding) CONINUT
Fig.2.6 Zonele unei entiti document considerate n aplicarea foilor de stil
Definiia de stil O foaie de stil este o colecie de definiii de stil. Sintaxa general a unei definiii de stil este urmtoarea:
38
selector {nume_proprietate : valoare_proprietate} unde selector reprezint tag-ul HTML la care se asociaz definiia de stil, reprezentat de perechea (nume_proprietate, valoare_proprietate). Definiia de stil implic punerea n coresponden a doua entiti: tag HTML i stil al unei proprieti a acestuia. Iat o list de proprieti i de valori posibile ale acestora: font-family: nume font font-size: nr.{pt=puncte, px=pixeli, in=inchs, cm=centimetri, %} font-style: {italic, normal, oblique} font-weigh: {extra-light,demi-light, light, mediun, extra-bold, demi-bold, bold} background: culoare text-decoration: {none, underline, italic, line-through} line-heigh: nr. {pt=puncte, px=pixeli, in=inchs, cm=centimetri, %} color: culoare (nume culoare sau #RRGGBB) margin-left: nr. {pt=puncte, px=pixeli, in=inchs, cm=centimetri} margin-right, margin-top, text-ident text-align: {left, center, right} background: culoare (nume culoare sau #RRGGBB) n definirea unui stil exist mai multe cardinaliti de asociere a entitilor tag i proprietate, astfel:
11 1n n1 nn Motenirea stilului ntre tag-uri aflate pe o ierarhie printe-descendent, tag-ul descendent motenete stilul tag-ului printe. Se poate defini un stil pe o anumit ramur a unei ierarhii printe, identificat prin sel_1, descendent, identificat prin sel_2, indicnd succesiunea de tag-uri de pe calea respectiv astfel: sel_1 sel_2 {n_p : v_p} Ca urmare a acestei definiii, stilul definit se aplic pentru tag-ul sel_2 doar dac acesta se afl pe o ramur n care este descendent al tag-ului sel_1. De exemplu definiia de stil: H1 ol {font-size:10}
39
sel {n_p : v_p} sel {n_p1 : v_p1, n_p2 : v_p2, } sel_1, sel_2, , sel_k {n_p : v_p} sel_1, sel_2, , sel_k {n_p1 : v_p1, n_p2 : v_p2, }
Ea se aplic elementelor ol din urmtorului fragment de document:

... <H1> <ol> <li>se aplic definiia de stil <li>se aplic definiia de stil </ol> </H1> ...
dar nu se aplic n urmtorul caz:

... <H1> ... <H2> <ol> <li>nu se aplic definiia de stil </ol> </H2> </H1> ...
Particularizri ale utilizrii stilului pentru un anumit tag

Clase de stiluri
Se pot defini mai multe stiluri pentru acelai tag. Fiecare definiie de stil reprezint o clas de stil identificat printr-un nume. n cadrul unui tag se poate specifica clasa de stil ce se utilizeaz indicnd numele acesteia n atributul CLASS al tag-ului. Fie urmtoarele definiii de clase de stil: .nume_clasa1 {n_p : v_p} .nume_clasa2 {n_p : v_p} .nume_clasa3 {n_p : v_p} Utilizarea pentru o anumit instan a tag-ului s_1 a stilului definit n clasa nume_clasa2 este specificat cu sintaxa: <s_1 CLASS=nume_clasa2>
Asocieri particulare de stiluri
Dac stilul este definit folosind construcia: #nume_stil {n_p : v_p} se poate indica utilizarea acestuia doar n anumite instane ale unui tag, instane crora li se asociaz ca identificator numele stilului, astfel: <selector ID = nume_stil>
40
Stilul definit pentru selectorul #nume_stil se aplic doar instanelor acestuia nsoite de atributul ID=nume_stil.
Pseudo-clase
Pseudo-clasele definesc stiluri care se conecteaz la o anumit stare a unui tag sau a unui obiect al documentului. De exemplu, pentru tag-ul <A> (anchor) se disting trei stri: hiperlegtur normal, hiperlegtur activ i hiperlegtur vizitat, pentru fiecare stare fiind definit un stil propriu (n general, referitor la culoarea textului). De asemenea, pentru un paragraf se pot distinge obiectele de tip linie care pot fi n starea prima linie sau n starea restul paragrafului. Pentru starea prima linie se poate defini o pseudo-clas de stil care se va aplica la prima linie a fiecarui paragraf din document. Nivele de definire a stilului i aplicarea lor n cascad O foaie de stil este memorat ntr-un fiier de tip *.css. n aceasta trebuie specificat tipul documentului fie prin Content-Style-Type: text/css fie utiliznd tag-ul META astfel: <META http-equiv="Content-Style-Type" content="text/css"> Definirea stilului se poate face la nivel de tag in-line, la nivel de pagin HTML sau n fiier separat, de tip *.css, aplicabil mai multor pagini HTML. Foaia de stil poate fi nglobat n document sau poate fi doar conectat la acesta. Definiia de stil inline se face utilizd atributul style n cadrul altui tag, caz n care afecteaz doar obiectul marcat cu eticheta respectiv: <h3 style=font-family:Arial;color:red>Titlu de nivel 3</h3> Definiia de stil poate fi plasat n antetul documentului, caz n care afecteaz toate obiectele marcate cu etichetele pentru care se definete stilul.
<HEAD> <STYLE type="text/css"> definiii de stil </STYLE> </HEAD>
O foaie de stil poate fi nglobata n documentul HTML, prin specificarea faptului c se import definiiile dintr-o foaie de stil indicata prin URL. Aceste definiii acionez, de asemenea, la nivelul ntregii pagini HTML.
<STYLE TYPE="text/css"> @import url(http://www.myserver.com/style.css); </STYLE>
41
Cazul cel mai general este cel al foii de stil extern (legat), cnd se utilizeaz o foaie de stil aflat ntr-un fiier extern cu extensia .css, care se conecteaz la document prin specificarea acestui lucru n antet astfel: <link rel=stylesheet href=*.css type=text/css> Este posibil utilizarea alternativ a mai multor foi de stil. Acest lucru se exprim prin indicarea unui acelai titlu i prin folosirea cuvtului cheie alternate.
<LINK TYPE="text/css" REL="alternate stylesheet" TITLE="Example" HREF="A.css"> <LINK TYPE="text/css" REL="alternate stylesheet" TITLE="Example" HREF="B.css">
n cazul unui document complex se folosesc stiluri combinate. Exist o disciplin de aplicare n cazul mai multor definiii pentru acelai tag. Aceasta este reflectat de principiul foilor de stil n cascad (Cascading Style Sheets). Stilul unui document HTML poate fi definit n mai multe module de stil. Prin noiunea de cascad se reglementeaz modul n care se pot utiliza mai multe module de definire a stilului pentru un document HTML. Regula spune c dac pentru o pagin HTML exist mai multe module de definire a stilului, acestea sunt parcurse n cascad de ctre navigator. Este important de subliniat c se utilizeaz contextul grafic existent pe maina gazd. Avantajele utilizrii foilor de stil sunt modularitatea i reutilizarea modulelor prin indicarea explicit sau implicit (prin importuri) a fiierelor .css dorite i personalizarea n contextul utilizrii navigatoarelor care permit folosirea unor stiluri personale. Dac lum n considerare att contextul de la client ct i definiiile din paginile descarcate de la server, putem distinge urmtoarele tipuri de stiluri i prioritile lor. Stilurile definite la nivelul navigatorului sunt implicite i au prioritate minim. Urmeaz stilurile personale setate de utilizatorul client i, cu prioritate maxim, stilurile principale specificate de autor. La nivelul stilurilor specificate de autor exist, de asemenea, o ierarhie de aplicare. Prioritate minim o au stilurile definite n foile de stil conectate, ordinea prioritilor continund cu stilurile nglobate i cu stilurile inline. Regula spune c stilurile se aplic n cascad, n ordinea prioritilor, iar la prioriti egale, n ordinea specificrii lor. Aplicarea criteriului prioritilor poate fi eludat folosind cuvtul cheie important.
42
3. ARHITECTURI PENTRU EXTINDERE FUNCIONALITATE LA CLIENT

Acest capitol este destinat prezentrii de informaii eseniale n dezvoltarea aplicaiilor Web cu pagini dinamice, prin programare la client. Este descris arhitectura pentru extinderea funcionalitii la client, pentru ca apoi s fie analizate principalele metode de descrcare i de executare cod de ctre navigatoarele Web. Acest cod este de dou tipuri. Este vorba, pe de o parte, de codul corespunztor logicii aplicaiei, care poate fi cod coninut n diferite tipuri de obiecte sau fiiere multimedia, n componente ActiveX, n componente Java de tip applet sau poate fi cod de scripting inclus direct n pagina Web. Pe de alt parte, este vorba de extinderea funcionalitii agentului utilizator prin includerea sau descrcarea sub form de plug-in a motoarelor de interpretare necesare translatrii acestor tipuri de coduri.
3.1. Componente
Clientul Web este reprezentat de navigator i implementeaz o colecie de funcii specifice redrii coninutului paginilor transmise de la server. Aceste pagini pot fi statice, cu coninut nemodificabil, sau pot avea un coninut dinamic. Dinamica coninutului paginilor Web se datoreaz, n general, aciunilor utilizatorului i poate implica modificarea paginilor fie pe baza unei noi curse la server de unde se preiau informaii noi, fie pe baza informaiilor disponibile la client, fr a necesita o curs la server. Acest al doilea caz beneficiaz de extinderea funcionalitii la client conform definiiilor din paginile Web realizate n limbaje pentru care agentul client (browser) dispune de interpretoare.
DATE multimedia Cod HTML Cod JS Cod Java (applet)
WebServer Cerere Browser Raspuns Plugins HTML JS JVM Interfata client Interfaa cu site-ul Web
Nivel interpretoare cod
Fisiere *.html, *.dhtml, *.js,*.css, *.class aflate n sistemul de fiiere al mainii gazd
Fig.3.1 Extinderea funcionalitii la CLIENT
43
Interpretorul pentru cod HTML reprezint funcionalitatea primar a oricrui navigator. Plug-ins sunt componente software destinate fie interpretrii de informaii multimedia din fiiere transmise de la server, fie alte aplicaii destinate a fi executate pe maina de la client n vederea completrii funcionalitii unei aplicaii Web. Interpretorul de cod JavaScript permite nglobarea de cod JavaScript n paginile HTML. Acest cod este utilizat pentru a defini aciuni ce se execut ca urmare a unor evenimente declanate la interfaa paginii cu utilizatorul sau cu navigatorul Web. Interpretorul de cod Java (JVM) permite executarea codului Java descarcat de la server sub form de applet.
3.2 OBIECTE N PAGINI WEB

3.2.1 Plug-ins Pentru a extinde funcionalitatea primar oferit de un browser Web, acestuia i pot fi ataate componente software de tip plug-in. Avnd la dispoziie aceste componente, agentul client implementat de browser este capabil s execute funcii definite n componente create de programatorul aplicaiei Web sau componente disponibile pe maina client sau n Internet, unele dintre acestea fiind capabile s reproduc date transmise de la server n fiiere multimedia. Procedura general de extindere a funcionalitii la client n acest manier este realizat prin inserarea de obiecte n pagini Web. Unele din aceste obiecte pot fi de diferite tipuri MIME. Pentru fiecare astfel de tip, agentul utilizator gestioneaz un set de corespondene ntre tipul MIME i un plug-in specializat n prelucrarea acestuia. Atunci cnd apare o solicitare de prelucrare a unui astfel de fiier, navigatorul identific plug-in necesar i, dac acesta nu este deja instalat, l ncarc pentru ca apoi s-i transfere fiierul spre prelucrare. Pentru specificarea nglobrii unui obiect n pagini Web se utilizeaz tag-ul <OBJECT>20. Atributele acestuia identific prin URL plug-in necesar (CLASSID) i fiierul ce conine obiectul (DATA), precizeaz tipul MIME al obiectului inclus sau al fiierului de date al obiectului (TYPE), precum i caracteristici ale cadrului n care este prezentat obiectul respectiv (BORDER, HEIGHT, etc). De asemenea, pentru identificarea obiectului n ierarhia de obiecte a paginii Web, acesta primete un nume indicat ca valoare a atributului ID. Unui obiect i pot fi transmii parametri, care sunt formai cu tag-ul <PARAM> i sunt nglobai n tag-ul <OBJECT>.
<OBJECT definiii atribute > <PARAM NAME = nume_p1 VALUE = val_p1> <PARAM NAME = nume_p1 VALUE = val_p1> ... </OBJECT>
Pentru navigatoarele care nu suport obiecte nglobate n pagini Web se recomand furnizarea de coninut alternativ, ca n exemplu urmtor.
Exist, de asemenea, tag-ul <EMBED> cu o funcionalitate asemntoare dar mai restrns, valabil i la versiuni mai vechi de HTML 4. 44
20
<OBJECT DATA = film.avi WIDTH=100 HEIGHT=100> <PARAM NAME = AUTOSTART VALUE = TRUE> <A HREF=get_film.htm> <IMG SRC=poza.gif WIDTH=100 HEIGHT=100> </A> </OBJECT>
La clienii ce folosesc aceste navigatoare, din exemplul de mai sus va fi interpretat doar coninutul corespunztor tag-ului A(ANCHOR). 3.2.2 COMPONENTE ActiveX Funcionalitatea la client poate fi extins i prin includerea n pagina Web a unor obiecte de tip control ActiveX disponibile pe maini client de tip Windows. Acestea sunt, de asemenea, marcate cu tag-ul <OBJECT>. Atributul CLASSID indic obiectul ce va fi inserat, prin intermediul numrului unic al acestuia n cadrul coleciei de obiecte de pe maina Windows a clientului. Acesta se obine fie din documentaia controlului respectiv, fie automat utiliznd ActiveX Control Pad pentru inserarea controlului n pagina Web, fie inspectnd coninutul bazei de date Registry pentru a determina valoarea cheii asociat controlului n urma instalrii acestuia pe maina Windows. Sintaxa de specificare a valorii acestui atribut conine clsid urmat de numrul unic, ca n exemplul urmtor n care este utilizat controlul Popup Menu:
<OBJECT id=menu1 classid="clsid:0482B100-739C-11CF-A3A9-00A0C9034920" width=1 height=1 align=left hspace=0 vspace=0> <PARAM NAME="Menuitem[0]" VALUE="Optiunea_1"> <PARAM NAME="Menuitem[1]" VALUE="Optiunea_2"> <PARAM NAME="Menuitem[2]" VALUE=" Optiunea_3"> <PARAM NAME="Menuitem[3]" VALUE=" Optiunea_4"> </OBJECT>
Parametrii sunt marcai cu tag-ul <PARAM> care, pe lng NAME i VALUE, are i atributele TYPE i VALUETYPE care poate lua una din valorile REF,OBJECT sau DATA pentru a specifica semnificaia valorii atributului VALUE. Valoarea REF dat atributului VALUETYPE indic faptul c parametrul este o referin la un obiect identificat prin URL-ul dat ca valoare a atributului VALUE, iar atributul TYPE va specifica tipul acestuia. Valoarea OBJECT indic utilizarea unui alt obiect ca parametru. Valoarea DATA indic un parametru de tip ir de caractere. Atributul ID primete o valoare care identific controlul la nivelul ierarhiei de obiecte n pagina Web, identificator folosit n scripturile care trateaz evenimentele ce apar la control. Aceste evenimente sunt tratate cu cod VBScript, cod ataat unui eveniment utiliznd atributele FOR (pentru indicarea controlului) i EVENT (pentru a indica evenimentul tratat), ale tag-ului <SCRIPT>, ca n urmtorul exemplu:
45
<SCRIPT LANGUAGE="VBScript" FOR="b1" EVENT="Click"> <!-window.alert( "Ati apasat butonul !" ) --> </SCRIPT> <OBJECT ID="b1" WIDTH=96 HEIGHT=32 CLASSID="CLSID:D7053240-CE69-11CD-A777-00DD01143C57"> <PARAM NAME="Caption" VALUE="Apasati aici !"> <PARAM NAME="Size" VALUE="2540;847"> </OBJECT>
3.3 JAVA SCRIPT

JavaScript este un limbaj de scriptig, orientat obiect, derivat din limbajul Java. JavaScript se conformeaz ECMAScript21, standard pentru limbaje orientate obiect, de tip script. JavaScript este un limbaj special conceput pentru manipularea, automatizarea i integrarea facilitilor oferite de un navigator Web. 3.3.1. Specificaiile standardului ECMAScript Conform specificaiilor standardului, orice obiect este membru al tipului Object i reprezint o colecie neordonat de proprieti, fiecare cu zero sau mai multe atribute. Proprietate = obiect|valoarea primitiv|metod Valoare primitiv = Undefined|Null|Boolean|Number|String Metod= funcie asociate unui obiect prin intermediul unei proprieti. Standardul specific, de asemenea, urmtorul set de obiecte predefinite: {Global,Object,Function,Array,String,Boolean,Number,Math,Date} Operatori sunt cei cunoscui din limbajele Java i C, excepie fcnd faptul c % are operanzi reali iar && i || ntorc valoarea unuia din operanzi, indiferent de tipul acestuia. Tipurile de instruciuni sunt urmtoarele: - bloc de instruciuni delimitat de { } - instruciunea vid ; - instruciunea de test if - iteraii while, for, for-in - instruciuni de control return, continue, break, with. Limbajul ofer o ierarhie de obiecte predefinite, conform cu modelul DOM. Programatorii pot utiliza obiecte predefinite i i pot defini obiecte proprii. Limbajul este mai puin restrictiv i prin faptul c variabilele nu trebuie declarate ca tip, ele lund tipul valorii ce li se atribuie.
21
European Computer Manufacters Association. 46
3.3.2. Identificarea obiectelor din ierarhia JavaScript Ierarhia obiectelor n documentele HTML este accesibil codului JavaScript conform modelului DOM. Fiecare obiect din acest ierarhie are un set propriu de atribute. Acestea sunt identificate prin numele atributului ataat la identificatorul obiectului. Ierarhia cuprinde obiectele ce pot s apar i s fie identificate ca entiti distincte n paginile Web i evideniaz relaiile de subordonare dintre acestea. Aceste relaii trebuie respectate n crearea identificatorului unui anume obiect sau atribut al acestuia. Prezentm n continuare aceast iererhie i exemple de utilizare a ei n identificarea obiectelor unui document.
window window.frame window.document window.document.layer window.document.link window.document.image window.document.area window.document.anchor window.document.applet window.document.plugin window.document.form window.document.form.textarea window.document.form.text window.document.form.fileupload window.document.form.password window.document.form.hidden window.document.form.submit window.document.form.reset window.document.form.radio window.document.form.checkbox window.document.form.button window.document.form.select window.document.form.select.option window.location window.history navigator navigator.plugin navigator.mimetype
Iat cteva exemple de identificatori de atribute:

window.document.name window.document.action window.document.target window.document.form.select.option.value
Crearea unui obiect JS se face utiliznd operatorul new aplicat obiectului rdcin Object, unui obiect predefinit din setul { Global , Object , Function , Array , String , Boolean , Number , Math , Date}, unui obiect din ierarhia JavaScript sau unui obiect definit de programator.
47
Referinele la obiecte se pot face fie indexat (ex. document.forms[0]) fie prin nume (ex. document.nume_forma1). Navigarea n structura documentului se face pe baza relaiei de tip printe descendent, utilizndu-se notaia clasic de identificare a obiectelor dintr-o ierarhie de clase. Exemplul urmtor conine un document simplu HTML i identificatoarele obiectelor pe care le conine, conform ierarhiei DOM-HTML. Cod HTML
<OL id=lista_nivel1> <LI>element1</LI> <LI>element2</LI> <LI>element3</LI> <UL id=lista_nivel2> <LI>element4</LI> <LI>element5</LI> <LI>element6</LI> </UL> </OL>
Identificare DOM
document.lista_nivel1 document.lista_nivel1[0] document.lista_nivel1[1] document.lista_nivel1[2] document.lista_nivel1.lista_nivel2 document.lista_nivel1.lista_nivel2[0] document.lista_nivel1.lista_nivel2[1] document.lista_nivel1.lista_nivel2[2]
Identificarea obiectului este utilizat pentru realizarea de operaii asupra lui, n momentul apariiei unui eveniment. Exist un model al evenimentelor ce pot fi detectate la nivelul navigatorului. Acestea sunt lansate, n general, de aciuni ale utilizatorului. Detectarea i posibilitatea de tratare a lor permit realizarea de documente interactive. Evenimentele sunt declanate de operaii asupra controalelor din pagina Web (ex. Button, Submit) sau de operaii mai generale de interfa. Evenimentele sunt detectate de browser care lanseaz, la client, funcia definit (n general n limbaj de scripting) pentru tratarea lor. Definirea funciilor se face n manier clasic, conform urmtoarei sintaxe generale: function Nume_funcie(list_argumente) Exist mai multe variante sintactice pentru definirea unei funcii. Fie funcia care calculeaz ptratul numrului indicat ca parametru. Urmtoarele trei definiii ale acesteia sunt echivalente: function square(x) {return x*x;} var square = new Function(x, return x*x;); var square = function(x){return x*x;}
48
3.3.3. Modelul evenimentelor Codul JavaScript la client este destinat, n general, tratrii evenimentelor ce provin de la interfaa cu utilizatorul sau de la navigator. Agentul utilizator reprezint clientul Web i este un superset pentru navigator. Suportul pentru HTML dinamic ofer posibilitatea tratrii unor manevre utilizator direct la client, far a fi necesar o curs la server. Pentru aceasta se utilizeaz suportul interactiv oferit de sistemul de operare pe care este instalat agentul utilizator, care transmite aplicaiei de navigare, prin mecanismul de callback, evenimentele detectate la interfaa cu utilizatorul. Sistemul de operare detecteaz evenimentul (de exemplu o manevr cu mouse), transmite informaiile ce definesc manevra (poziie cursor, buton apasat, etc) la agentul de utilizator. Agentul utilizator este responsabil cu realizarea corespondenei ntre aceste informaii i pagina Web curent, adic ntre elementul de control al dialogului identificat prin poziia cursorului i rutina de tratare a evenimentului generat de manevra utilizatorului asupra acestuia i primit de navigator, prin mecanismul de callback, de la nivelul sistemului de operare. Evenimentele transmise de sistemul de operare sunt pstrate ntr-o coad de ateptare la agentul utilizator, n vederea tratrii lor. JavaScript are definit un set de evenimente intrinseci care sunt recunoscute de ctre agentul utilizator. Agentul utilizator include o rutin de ascultare a evenimentelor (event listener), oferind astfel suportul pentru lucrul cu evenimente. Aceste evenimente sunt standardizate, pentru a fi recunoscute de orice agent utilizator. Ele sunt tratate la client, utiliznd rutine de tratare a evenimentelor (event handler), specificate n limbaj de scripting n documentul DHTML. Astfel se extinde funcionalitatea clientului cu funciile pentru tratarea acestor evenimente. Specificarea corespondenei ntre eveniment i rutina de tratare a sa se face indicnd numele evenimentului ca atribut al unei etichete. Codul de tratare poate fi plasat inline, ca valoare a atributului respectiv, sau ca valoare a atributului se poate specifica apelul unei funcii destinat tratrii evenimentului i definit n antetul documentului, ca n exemplul urmtor: <IMG NAME=imagine SRC=fisier.gif onClick=Functie1();>
Urmtorul tabel conine lista evenimentelor HTML 4 Eveniment onLoad onUnload onReset onClick Descriere Finalizarea ncrcrii unei ferestre sau set de frame-uri similar Reiniializare formular Click buton mouse Etichete BODY, FRAMESET BODY, FRAMESET FORM Orice eticheta pentru marcarea unui element afiabil Idem Idem Idem Idem Idem Idem LABEL, INPUT,
onDblclick onMouseDown onMouseUp onMouseOver onMousemove onMouseOut onFocus
Dublu click buton mouse Buton mouse apsat Buton mouse eliberat Cursorul de mouse intra n zona elementului din pagin Cursorul de mouse se mic peste elementul din pagin Cursorul de mouse iese din zona elementului din pagin Focalizarea elementului, cu mouse sau tastatur 49
onBlur onKeyPress
Defocalizarea elementului Apasare i eliberare tast n zona elementului Apasare tast n zona elementului Eliberare tast n zona elementului Transmitere formular Selectarea unui text Modificarea valorii unui control ntre momentul pierderii focalizrii i momentul n care a recptat focalizarea
onKeyDown onKeyUp onSubmit onSelect onChange
SELECT, TEXTAREA, BUTTON Idem Orice eticheta pentru marcarea unui element afiabil Idem Idem FORM INPUT, TEXTAREA INPUT, SELECT, TEXTAREA
3.3.4. Structura paginilor HTML ce conin JavaScript Codul de scripting poate s apar att n antetul documentului DHTML ct i n zona de coninut propriu-zis. Codul din antetul documentului DHTML (<HEAD>) este marcat cu tag-ul <SCRIPT> i conine definiii de funcii i de obiecte. Codul din zona de coninut a documentului (<BODY>) poate fi marcat cu tag-ul <SCRIPT>, sau poate fi ncadrat ntre dac se afl n interiorul altui tag fiind totodat ataat unui eveniment, i conine apeluri de funcii i instruciuni. 3.3.5 Exemple Pentru descoperirea valorilor proprietilor obiectelor se foloseste urmtorul cod de scripting:
... <SCRIPT > var s= for (v in tip_obiect) s+=v+\n; alert(s); </SCRIPT>
Dac, de exemplu, n codul de mai sus nlocuim tip_obiect cu navigator se obin proprietile obiectului navigator. Urmtorul exemplu ilustreaz gestionarea evenimentelor cu cod de scripting la nivel de tag:
<IMG NAME=desen1 SRC=d1.gif onkeydown=window.alert(Constanta);> <IMG NAME=desen2 SRC=d2.gif onkeydown=window.alert(Bucuresti);> <IMG NAME=desen3 SRC=d3.gif onkeydown=window.alert(Timisoara);>
Pentru a ilustra cele doua variante de definire a codului de scripting fie integral n <BODY>, fie de definire a funciilor n <HEAD> cu apelarea lor din <BODY>, se consider o pagin Web care realizeaz evaluarea expresiilor introduse de utilizator: Pentru a exemplifica definirea codului de scripting integral n <BODY> se consider doar operaia de mprire a dou numere ntregi, operaie implementat astfel:
50
<HTML> <BODY> <SCRIPT language=JavaScript> var nr1 = window.prompt(Primul numar=, 0); var nr2 = window.prompt(Al doilea numar=, 0); var n1,n2; n1=parseInt(nr1); n2=parseInt(nr2); if (n2==0) window.alert(Operatie ilegala); else document.writeln (Rezultatul este +nr1+/+nr2+=+(n1/n2)); </SCRIPT> </BODY> </HTML>
Pentru a ilustra operaiilor ca funcii n <HEAD> i operarea lor din <BODY> se consider o pagin Web care realizeaz evaluarea oricarei expresii introdus de utilizator. Pentru aceasta se definete n <HEAD> funcia calcul care primete ca argument un obiect de tip form i care utilizeaz funcia de bibliotec eval.
<HTML> <HEAD> <SCRIPT type=text/javascript> function calcul(obiect) { obiect.rezultat.value = eval(obiect.expr.value); } </SCRIPT> </HEAD> <BODY> <FORM name=evaldinamic> <p> Introduceti o expresie cu valori numerice: <INPUT type=text name=expr size=40> <INPUT type=button name=buton value=Calculeaza! onclick=calcul(this.form)> <p> Rezultatul este: <input type=text name=rezultat size=20> </FORM> </BODY> </HTML>
Una din cele mai frecvente aplicaii ale scripting-lui la client este realizarea validrii informaiilor introduse ntr-o form, nainte ca aceastea s fie trimise la server. Urmtoarea form, definit n seciunea <BODY> a paginii Web, conine cmpuri pentru preluarea unor informaii despre client. O parte din cmpuri trebuiesc completate n mod obligatoriu, lucru identificat prin valoarea true a atributului form.field.optional. De asemenea, un alt criteriu de validare apare la
51
cmpurile numerice pentru care se testeaz tipul coninutului introdus de utilizator care trebuie s fie numeric i pentru care se pot defini, n plus, valori minime i maxime admise. Validarea se face pe evenimentul onSubmit, folosind funcia verify(f) definit n seciunea <HEAD> a paginii Web, funcie ce primete ca argument obiectul form pentru cmpurile cruia care se face validarea.
<BODY> ... <FORM onSubmit="this.nume.optional = true; this.telefon.optional = true;this.zip.min = 0;this.zip.max = 99999; return verify(this);"> Nume: <INPUT TYPE=text NAME="nume"> Prenume: <INPUT TYPE=text NAME="pnume"><BR> Adresa:<BR><TEXTAREA NAME="adr" ROWS=4 COLS=40></TEXTAREA><BR> Cod Zip: <INPUT TYPE=text NAME="zip"><BR> Numar telefon: <INPUT TYPE=text NAME="telefon"><BR> <INPUT TYPE=submit> </FORM> ... </BODY>
n seciunea <HEAD> sunt definite dou funcii. Prima, isblank(s), identific irurile formate numai din spaii i este folosit de cea de a doua, verify(), responsabil cu validarea coninutului completat n form.
<HEAD> ... <SCRIPT LANGUAGE="JavaScript1.1">
Funcia care ntoarce true dac irul primit ca argument conine doar spaii:
function isblank(s) { for(var i = 0; i < s.length; i++) { var c = s.charAt(i); if ((c != ' ') && (c != '\n') && (c != '\t')) return false; } return true; }
Funcia ce realizeaz validarea formei, apelat de rutina de tratare a evenimentului onSubmit. Aceast rutin ntoarce exact valoarea ntoars de funcia verify(f).
function verify(f) { var msg; var empty_fields = ""; var errors = "";
52
for(var i = 0; i < f.length; i++) { // parcurge obiectele din form, identificate prin index var e = f.elements[i]; if (((e.type == "text")||(e.type == "textarea"))&& !e.optional) { // izoleaz obiectele de tip text i textarea care nu sunt opionale if ((e.value == null)||(e.value == "")||isblank(e.value)) { // creaz un ir ce conine numele obiectelor care trebuie s conin text explicit empty_fields += "\n" + e.name; continue; }
// Identific cmpurile ce trebuie s fie numerice
if (e.numeric || (e.min != null) || (e.max != null)) { var v = parseFloat(e.value); if (isNaN(v) || ((e.min != null) && (v < e.min)) || ((e.max != null) && (v > e.max))) { errors += "- Campul " + e.name + " trebuie sa fie un numar"; if (e.min != null)
// verific n raport cu valorile minime i maxime impuse, acolo unde este cazul
errors += " mai mare decat " + e.min; if (e.max != null && e.min != null) errors += " si mai mic decat " + e.max; else if (e.max != null) errors += " mai mic decat " + e.max; errors += ".\n"; }}}}
// n caz de eroare afieaz mesajul corespunztor i este ntoars valoarea false, ceea ce nu permite // trimiterea formei la server // Dac nu sunt erori se ntoarce valoarea true care va declana trimiterea formei la server
if (!empty_fields && !errors) return true; msg = "__________________________________________\n\n" msg += "Forma nu a fost transmisa datorita urmatoarelor erori.\n"; msg += "Corectati-le si retransmiteti\n"; msg += "__________________________________________\n\n" if (empty_fields) { msg += "- Urmatoarele campuri obligatorii sunt necompletate:"+ empty_fields + "\n"; if (errors) msg += "\n";
3.4 APPLET
Applet este o aplicaie Java apelat dintr-un document HTML i ncrcat de pe server n momentul accesrii paginii Web ce conine documentul respectiv.
53
Applet-ul este executat n regim de interpretare, de ctre maina virtual Java a navigatorului de pe maina clientului. Execuia acestuia are loc ntr-o fereastr proprie. Un applet este o component Java. Ca orice component, acesta se conformeaz unei interfee. Interfaa Applet este definit n pachetul java.applet.* i conine metodele din tabelul de mai jos.
Nume metod Funcie
Iniializare (in general, a componentelor grafice) Crearea firelor de execuie. Pornirea firului principal. Actualizarea zonei de afiare ocupat de applet Oprete firele de execuie
Cnd se execut
La instaniere applet.
Comentarii
nlocuieste main(). Trebuie (re)definit de ctre programator.
init()
start()
Imediat dupa init() i la fiecare (re)afiare a applet-ului. Apelat de update(). Primete ca parametru contextul grafic al platformei pe care se afl browser-ul. Firele de execuie oprite nu mai pot fi repornite
paint(Graphics g)
Stop()
Destroy()
Eliberarea resurselor deinute de applet
nainte de destroy(). Cnd applet-ul dispare din fereastra curenta a navigatorului. La ncarcarea altei pagini. Cnd navigatorul elimin applet-ul.
3.4.1 Apel applet Apelarea unui applet se face dintr-un fiier HTML. Pentru aceasta se utilizeaz tag-urile specializate <APPLET> i <PARAM>. n tag-ul <APPLET> se specific identificatorul (CODE) i localizarea (CODEBASE) fiierului *.class ce conine codul applet-ului, dimensiunile ferestrei n care se va afia applet-ul (HEIGH, WIDTH), poziia acestuia n raport cu textul nconjurtor (HSPACE, VSPACE), identificatorul obiectului applet n restul sistemului (NAME) i un text ce apare n linia de stare (ALT). Setul atributelor tag-ului este: {CODE, CODEBASE, HEIGH, WIDTH, HSPACE, VSPACE, NAME, ALT} Tag-ul <APPLET> are urmtoarea sintax general:
<APPLET CODE = App.class [CODEBASE = url] HEIGH = val_h [HSPACE = val_sp_orizontal] WIDTH= val_w [VSAPCE = val_sp_vertical] [NAME=nume_app] [ALT=text]>
Ca oricrui program, unui applet i se pot trimite prametrii. Pentru transferul de parametri se utilizeaz tag-ul <PARAM> cu ajutorul cruia se specific numele i valoarea fiecrui parametru. Setul atributelor tag-ului este {NAME, VALUE} iar sintaxa general este urmtoarea:
54
<PARAM Structura codului HTML pentru aplelul unui applet conine elementul marcat cu tag-ul <APPLET>, avnd ca subelemente lista parametrilor de apel, astfel:
<APPLET ...> <PARAM ...> <PARAM ...> ... </APPLET>
NAME=nume_parametru
VALUE=valoare_parametru>
3.4.2 Operaiile realizate de agentul utilizator Agentul utilizator conine un container pentru ncrcarea i executarea componentelor de tip applet. Acest container se interfaeaz cu metodele clasei applet i lanseaz un mecanism specific ce st la baza exploatrii applet-ului.
init() Obiectul applet start() destroy() paint() stop()
Fig.3.2 Interfaa applet-container
Container
Acest mecanism execut o succesiune de operaii. Mai nti are loc ncrcarea codului (bytecode) applet-ului de pe server, identificat prin valorile atributelor CODE i CODEBASE. Urmeaz instanierea clasei. Pe obiectul astfel obinut are loc apelul metodei init(), urmat automat de apelul metodei start(). Funcie de evenimentele din sistem, determinate n special de gesturile utilizatorului, se lanseaz corespunztor metodele stop(), paint(), destroy(). Un applet prezint utilizatorului o interfa, format dintr-o colecie de componente grafice (GUI), definit de programator. Fiecare component grafic este o surs de evenimente pentru aplicaia applet, evenimente ce pot fi lansate prin aciuni ale utilizatorului. Spre deosebire de cod scripting la client care realizeaz nregistrarea ca ascultator22 de evenimente prin realizarea corespondenei ntre eveniment i codul de tratare a acestuia direct ca atribut al obiectului din interfa, applet-ul se nregistreaz ca ascultator la aceste surse de evenimente prin adaugarea explicit a unei interfee de ascultare la fiecare componenta grafic surs de evenimente, astfel: componenta_sursa_de_evenimente.addActionListener(this)
Identific obiectul applet
22
Event listener. 55
Fiecare apariie a unui eveniment este tratat de applet conform definiiilor din codul su, definiii aflate n implementarea, de ctre applet, a metodei actionPerformed() a interfeei ActionListener. Metoda actionPerformed() este lansat de cte ori apare un eveniment GUI, eveniment transmis acesteia ca parametru. Ea are funcia de dispecer de evenimente. n cadrul metodei are loc identificarea sursei evenimentului, urmat de tratarea acestuia. Corespondena ntre eveniment i codul de tratare al acestuia este realizat prin instruciunile de test din aceast metod. Fie urmtorul applet simplu care realizeaz suma i produsul a doua numere. Sgeile indic modul de specificare a corespondenei ntre eveniment i codul pentru tratarea lui.
import java.applet.Applet; import java.awt.*; public class Produs extends Applet { TextField t1, t2; Button b; public void init() { t1 = new TextField(20); t2 = new TextField(20); t3 = new Label(20); b1= new Button(SUMA); b2= new Button(PRODUS); add(t1); add(t2); add(t3); add(b1); add(b2); b1.addActionListener(this); b2.addActionListener(this); } public void actionPerformed(ActionEvent ev) { if(ev.getSource() instanceof Button) { if(ev.getActionCommand().equals(SUMA) t3.setText(parseInt(t1.getText()+parseInt(t2.getText()); if(ev.getActionCommand().equals(PRODUS) t3.setText(parseInt(t1.getText()*parseInt(t2.getText()); } }
Codul JavaScript la client echivalent este urmtorul. Sgeile indic, de asemenea, corespondena ntre eveniment i codul pentru tratarea lui.
56
<HTML> <HEAD> <SCRIPT type=text/javascript> function suma(f) { f.t3.value = parseInt(f.t1.value) + paresInt(f.t2.value) } function produs(f) { f.t3.value = parseInt(f.t1.value) * parseInt(f.t2.value) } </SCRIPT> </HEAD> <BODY> <FORM ...> <INPUT TYPE=text NAME=t1 SIZE=20> <INPUT TYPE=text NAME=t2 SIZE=20> <INPUT TYPE=text NAME=t3 SIZE=20> <INPUT TYPE=button NAME=b1 VALUE=SUMA onClick=suma(this);> <INPUT TYPE=button NAME=b2 VALUE=PRODUS onClick=produs(this);> </FORM> </BODY> </HTML>
3.5 STRI PERSISTENTE LA CLIENT

3.5.1 COOKIE-s Protocolul HTTP, bazat pe cerere-rspuns, transmite n antetul cererii o serie de informaii despre cerere i client, informaii care nsa nu sunt memorate la server, fiind disponibile doar pe parcursul tratrii cererii curente. Astfel, serverul nu pstreaz nici un fel de informaii despre clienii si i despre starea acestora. Cookies se definete ca fiind un mecanism prin care serverul solicit clientului s memoreze un set de informaii, informaii care supravieuiesc unei curse cerere/rspuns i care au ca perioad de via o sesiune client, sesiune format din mai multe curse cerere/rspuns. De asemenea, cookie-urile pot supravieui i unei sesiuni client. Aceste informaii memorate la client vor extinde coninutul antetului cererii i vor fi transmise de agentul utilizator odat cu fiecare cerere. Putem spune c aceste informaii formeaz o stare persistent la client, definind clientul n relaia acestuia cu serverul. Definiiile sunt dependente att de preferinele utilizatorului ct i de setri impuse de la server. Memorarea n cookie a preferinelor utilizatorilor pentru completarea unei anumite forme are avantajul reutilizrii informaiilor deja transmise de utilizator. O alternativ poate fi memorarea acestor preferine ntr-o baz de date la server, dar aceasta induce costuri suplimentare n regsirea datelor, dei ar putea reduce costurile de transfer.
57
Instalarea de cookie-uri necesit operaii de scriere pe maina client i are, de asemenea, implicaii legate de confidenialitate. De aceea, permisiunea instalrii de cookie-uri este setat din preferintele navigatorului. Acesta poate fi setat pentru a accepta implicit, cu confirmare din partea utilizatorului sau a nu accepta instalarea de cookie-uri. Dac este acceptat, instalarea de cookie-uri realizeaz o scriere ntr-un fiier cu numele cookies.txt (la Windows) sau cookies (la Unix) pe maina client, fr a avea acces la alte operaii ale acesteia. Acest fiier este localizat n subdirectorul Cookies al directorului personal al utilizatorului. Perioada de via a unui cookie este setat de programatorul acestuia. Solicitarea pentru setarea unui cookie este transmis n antetul mesajului de la server la client n formatul: ... Set_Cookie: definitie cookie ... Un cookie conine o stare definit sub forma de perechi (nume, valoare) precum i o colecie de atribute de validare a cookie-ului: expires, domain, path i secure. 3.5.2 Crearea unui cookie Definiia unui cookie conine perechile (nume, valoare) care definesc starea clientului i valorile atributelor de validare. Atributul expires are ca valoare data expirrii cookie-ului, aceasta fiind implicit nchiderea sesiunii navigatorului. Atributul domain este utilizat pentru specificarea domeniului (ex. ovidius.ro) n care se afl mainile care au dreptul de a accesa informaiile din cookie. Dac acestui atribut i este ataat i un indicator de acces TRUE, atunci toate mainile din domeniul specificat au acest drept. Dac nu se specific acest atribut, accesul este permis implicit mainii pe care se execut serverul Web care a generat cookie-ul respectiv. Atributul path conine un subset de URL-uri din domeniul specificat, pentru a preciza drepturile de acces la cookie. Dac se seteaz atributul secure, cookie-ul va fi transmis numai dac tranzacia este de tip HTTPS(secure). Clientul va transmite cookie-ul dac sunt ndeplinite toate condiiile specificate prin valorile atributelor de validare. Sintaxa general pentru setarea unui cookie este urmtoarea: Set_Cookie: nume_1=valoare_1;nume_2=valoare_2; ...; expires=data;path=cale;domain=domeniu;secure Starea memorat n cookie este transmis de la client la server n antetul cererii conform urmtoarei sintaxe:
Cookie:nume_1=valoare_1;nume_2=valoare_2;...;nume_k=valoare_k
58
Aceast transmisie are loc dac sunt indeplinite condiiile specificate n atributele de validare din definiia cookie-ului. ntr-o tranzacie HTTP se pot transmite mai multe solicitri pentru setare de cookie-uri, dimensiune lor fiind ns limitata. Astfel, n antetul unui rspuns de la server la client pot s apar mai multe linii Set_Cookie cu definiii23. 3.5.3 tergerea unui cookie n cazul clasic, tergerea unui cookie este comandat de la server, prin transmiterea unei alte setri de cookie cu acelai nume, cu valoare nul i cu timpul de expirare setat n trecut. Totui tergerea se mai poate face fie din navigator, fie acionnd direct asupra fiierului corespunztor de pe maina clientului. 3.5.4 Accesul clientului la cookie Informaiile din cookie-uri sunt gestionate de navigator care le transmite la server. Ele sunt disponibile ns i la client prin accesarea obiectului document.cookie. Acest obiect se poate afia prin specificarea la navigator a locaiei: javascript:document.cookie
23
Unele navigatoare limiteaz totui numrul de cookies (ex. Netscape =20). 59
4. XML I TEHNOLOGII ASOCIATE

n acest capitol este prezentat metalimbajul XML, fundamental pentru manipularea datelor semistructurate specifice Web-ului. Este prezentat, de asemenea, familia de limbaje derivate din acesta, precum i tehnologiile asociate, utilizate n formarea i prelucrarea documentelor Web ce conin date semistructurate, n protocoale de nivel nalt specifice aplicaiilor orientate pe servicii Web i n definirea semanticii informaiilor transferate ntre aceste aplicaii.
4.1 Baze de date semistructurate i XML

Modelul bazelor de date semistructurate rspunde necesitilor de comunicare a informaiilor distribuite i de unificare a modelelor diferite de reprezentare a informaiilor. Modelul a fost construit pentru a modela surse de date eterogene, cum ar fi cele din Internet. Acestea nu pot fi constrnse de o schem, iar regsirea informaiei se face dup coninut, deci modelul de date trebuie s aib puternice caracteristici semantice. Datele semistructurate sunt acele date care nu au o schem fix sau uniform. Modelul semistructurat (OEM-Object Exchange Model) reprezint datele sub forma unui graf etichetat. Nodurile corespund obiectelor iar arcele relaiei obiectsubiect. Etichetele arcelor descriu natura relaiei ntre obiect i subiect i pot fi valori ale tipurilor de baz, valori de date de tip abstract sau nume de atribute. Nodurile finale reprezint obiecte atomice. Interogarea unei baze de date implic, n mod clasic, cunoaterea schemei acesteia. Descifrarea unei scheme parial cunoscute ar putea fi fcut cu ajutorul unor interogri asupra acesteia, dar i asupra datelor a cror structur o cunoatem. Dac modelele de date convenionale fac o diferen net ntre schem (tipul i structura informaiei) i instan (valoarea informaiei), modelul de date semistructurat reprezint cele dou tipuri de informaii n mod uniform, permind interogarea lor simultan. De aceea, datele semistructurate se mai numesc i date autodescriptive, ele putnd fi descompuse i analizate fr referire la o schem extern deoarece conin i informaiile de descriere a datelor. Metoda principal de descriere a acestor tipuri de date este limbajul XML. Acesta permite fie definirea de etichete proprii ce corespund atributelor, fie se poate utiliza o definiie existent de tip de document care precizeaz atributele i o gramatic de utilizare a acestora. Elementele constructive ale limbajului sunt etichete ierarhizate. Fiecare element are o secven de perechi atribut-valoare i o secven de subelemente. Aceste subelemente pot fi, la rndul lor, marcate sau pot fi simple segmente de date de tip text. Un document XML bine format nu pune restricii privitoare la marcaje, nume de atribute sau abloane de ierarhizare. Alternativ, un document poate fi acompaniat de o definiie de tip care este, n mod esenial, o gramatic de definire a marcajelor i a structurii unui document.
60
Un document XML ce satisface o gramatica, definit n DTD sau n XMLSchema24, este considerat valid. ntr-un document XML sunt reprezentate structuri de date ierarhice, utiliznd marcaje incluse. Documentul nsui are o structur ierarhic, ceea ce permite un acces rapid la informaii i posibiliti simple de rearanjare a diferitelor poriuni de document. XML realizeaz o marcare a datelor conform semnificaiei acestora. Un marcaj identific coninutul datelor, specificnd tipul de date i nu modul lor de prezentare. Dac documentul nu se aliniaz unei definiii de tip, atunci trebuie s existe un acord al celor doi corespondeni asupra semnificaiei marcajelor. O soluie este oferit de iniiativa RDF(Resource Definition Framework), care definete meta-marcaje. Datele formatate cu XML sunt autodescriptive, deci conin elemente de semantic. Ele pot fi procesate cu diferite programe ce recunosc XML fie n vederea obinerii de diferite stiluri de prezentare, fie pentru a le transfera diverselor rezervoare (ex. baze de date). Este esenial faptul c se ofer astfel posibilitatea separrii coninutului datelor de forma lor de prezentare, ceea ce ofer flexibilitate sporit utilizrii prezente dar i viitoare, imprevizibile, a acestora. n plus, diferite date dintrun document pot fi identificate separat i prelucrate separat, n moduri specifice, ceea ce permite unui document s fie divizat n module independente, cu tipuri de date distincte. Reciproc, un document XML poate fi realizat din module XML multiple. Avantajele sunt similare celor oferite de utilizarea procedurilor n modularizarea programelor. E vorba n special de reutilizarea i partajarea modulelor. n plus fa de legturile expandabile, ntre documente XML se pot defini legturi bi-sens, legturi cu inte multiple sau legturi ntre dou documente definite n al treilea. Structura, coninutul i semanticile unui document XML sunt definite cu XMLSchema, ceea ce permite simultan definirea i validarea de tipuri de date. XML este un standard utilizat n schimbul informaiilor client/server pe Internet. Prin separarea datelor de prezentarea acestora, rspunde unor cerine importante ale dezvoltrii de aplicaii complexe distribuite. Acestea sunt flexibilitatea, ca suport pentru modularizare, i independena fa de platform n medii eterogene. n plus, el poate fi utilizat n programarea orientat document (DDP document driven programming). Astfel, un document XML poate descrie modul n care sunt conectate dinamic, n momentul accesului, diferite componentele de interfa cu componente ce implementeaz logica aplicaiei. Tehnologia XML asigur portabilitate. Instrumentele de procesare XML, scrise ntr-un limbaj portabil ca Java, extind tehnologia n manier portabil. Marcajele conectate la semantica informaiei definesc implicit prelucrri specifice asupra datelor. n plus, se ofer suport pentru automatizarea procesului de definire a prelucrrilor specifice diferitelor tipuri de elemente i subelemente, astfel nct se pot utiliza specificaii ale datelor pentru a defini module semnificative de cod. Informaiile organizate n documente XML prezint avantaje semnificative legate de intercomunicare n ingineria software. Familia de protocoale i limbaje XML reprezint un important avans n programarea distribuit i n special n programarea Web. Suportul pentru ataarea
DTD sau, mai recent, XMLSchema sunt formate pentru reprezentarea definiiilor de tip ale documentelor XML i vor fi prezentate n detaliu n acest capitol. 61
24
de semantici la structur, legturile hipertext sofisticate ca i spaiile de nume reprezint trei aspecte eseniale ale familiei XML. Suportul pentru ataarea de semantici la structur se refer la posibilitatea de a defini structuri n documentele XML, structuri crora li se pot apoi aplica semantici definite de utilizator i reguli de compoziie(cu DTD i XMLSchema). Suportul pentru spaii de nume permite mixarea i potrivirea25 de structuri ortogonale, independente, de documente. De exemplu, este posibil ca s se realizeze o descriere general a structurii unui document, urmat de includerea, n anumite cazuri speciale, de poriuni de coninut descrise de reguli specifice, care nu sunt incluse i chiar ar putea s nu fie permise n clasa documentului principal. Legturile hipertext n XML sunt mai sofisticate dect cele n HTML. Protocolul de realizare a legturilor XML este XLink, care suport legturi ce pot avea destinaii multiple, pot fi externe sau pot fi nedirecionale. Abilitatea de a specifica legturi multiple nedirecionale face posibil exprimarea de relaii generice ntre diferite pri ale documentelor, iar legturile externe permit autorilor s specifice seturi de legturi diferite i posibil independente ntre aceleai documente, pentru scopuri, cititori sau situaii diferite.
4.2 SGML (Standard Generalized Markup Language)

SGML reprezint un standard internaional pentru definirea unor metode de reprezentare a textelor n format electronic. SGML este independent de dispozitiv i de sistemul de calcul, asigur independena datelor fa de platforma hard-soft (suportul tehnologic, de prelucrare, al documentului) i fa de setul de caractere (suportul logic , de reprezentare, al documentului). Conceptul de codificare generic a fost introdus n 1960 de ctre William Tunniclife. Acesta a propus utilizarea de marcaje (tag-uri) descriptive pentru formatarea documentelor. n 1978 a fost lansat proiectul pentru crearea de limbaje de programare pentru prelucrarea electronic a textelor, avnd ca rezultat SGML. SGML este un meta-limbaj utilizat pentru descriere formal a unui limbaj. SGML este o descriere formal care definete marcaje ale textelor electronice. Marcajele sunt utilizate pentru codificarea unui text n vederea procesrii computerizate. n cazul documentelor, codificarea reprezint transcrierea unui manuscris ntr-un format special intern. SGML este un limbaj de specificare format dintr-un set de convenii de marcare utilizate pentru codificarea textelor. Limbajul specific, similar specificrilor de sintax i de semantic ale unui limbaj de programare, mulimea marcajelor obligatorii, mulimea marcajelor permise, maniera de identificare a marcajelor i semantica fiecrui marcaj disponibil. Un limbaj de programare descriptiv este format din marcaje descriptive, utilizate pentru a clasifica pri din document. Spre deosebire de acesta, un limbaj de programare procedural definete o aciune de ndeplinit la un moment dat26. Informaiile cu care lucreaz programele SGML, adic datele asupra crora opereaz, sunt documente. Documentele, ca i datele/obiectele unui limbaj, au tipuri.
25 26
match XML, descris in continuare, are i component procedural 62
Tipurile sunt definite sub form de DTD (Data Type Definition), aceasta fiind notaia pentru definirea regulilor gramaticii limbajelor definite cu SGML. Documentul este format din elemente corespunznd la uniti-text structurale (atomi-lexicali) cum ar fi seciuni, capitole, paragrafe. Fiecare instan de element este marcat de tag-uri <element> </element> cu numele corespunztor tipului de element marcat. Elementul este o construcie sintactic de tipul: element = vid | text | element(e) Datele sunt valorile specifice documentului iar metadatele descriu datele, indicnd semnificatia sau scopul lor. Din punct de vedere al aplicaiilor Web, considerm sursele de date, larg rspndite, de tip document electronic i de tip cmp de date. Un document electronic conine att informaia util ct i instruciuni care dirijeaz prezentarea lui. Coninutul util este reprezentat n limbaj natural. Pe de alt parte, cmpurile de date sunt perechi atomice nume-valoare procesabile de ctre calculator i capturate n general n forme. XML permite ataarea de metadate ambelor tipuri de surse de date considerate, astfel nct permite unificarea lor la nivelul Web.
4.3 XML (eXtended Markup Language)

4.3.1 Documente XML XML este un meta-limbaj pentru marcare structural a documentelor. Este compatibil cu SGML, succesor al acestuia, simplificat i adaptat la Internet. Fiind un meta-limbaj el conine un set de reguli sintactice pentru crearea de limbaje de marcare n diferite domenii. Astfel, XML permite definirea de limbaje i extinderea acestora. Fiecare astfel de limbaj este, de fapt, o aplicaie XML. Definirea limbajelor folosind un meta-limbaj comun se bucur de avantajul partajrii sintaxei, care are ca rezultat eficiena legat de utilizarea de analizoare sintactice i de alte instrumente comune, ca i eficiena utilizrii unui model comun n comunitatea programatorilor. Portabilitatea ce caracterizeaz documentele create n aceste limbaje permite prelucrarea documentelor n Internet, pe uniti eterogene de prelucrare. XML are patru valene primare: 1. Creaz date i documente independente de aplicaie, codificate sub form de texte accesibile majoritii programelor. 2. Are o sintax standard pentru metadate, adic ofer o sintax standard simpl pentru codificarea semnificaiei valorilor datelor, prin faptul c standardizeaz o metod simpl pentru codificarea pe baz de text a metadatelor. Astfel, XML ofer un mecanism simplu i robust pentru codificarea informaiilor semantice. 3. Are o structur standard, de form arborescent, att pentru documente ct i pentru date; aceast structur ierarhic permite utilizatorului s decompun conceptele n pri componente, utiliznd o manier recursiv. 4. XML nu e o tehnologie nou, ci un subset al SGML. Un limbaj descriptiv este format dintr-un set de marcaje i atribute i o colecie de constrngeri aplicate asupra lor. Acesta permite adugarea de informaii
63
semantice despre coninutul original al unui document prin ataarea de tag-uri elementelor documentului. Fie, n HTML, tag-urile HTML, HEAD, TITLE i BODY i atributele specifice acestora. Exemple de constrngeri sunt: elemente de tip HEAD i BODY pot s apar n cadrul unui element HTML, o singur dat, n aceast ordine; un element de tip TITLE poate s apar doar n cadrul unui element HEAD. XML este o tehnologie, o colecie de meta-constrngeri i un meta-limbaj, pentru definirea de limbaje de marcare. Aceasta tehnologie are o serie de avantaje, printre care faptul c este uor de implementat, c permite definirea de structuri orict de complexe, c suport reprezentare unicode. Un document XML poate fi privit din dou perspective diferite. El poate fi vzut, din punct de vedere sintactic, ca o secven linear de caractere coninnd date caracter i marcaje. Din punct de vedere semantic el reprezint o structur abstract de date sub forma unui arbore, ale crui noduri conin marcaje i atribute. Trecerea de la prima perspectiv la cea de a doua este realizat utiliznd analizoare lexicale27 specifice. 4.3.2 Marcaje Din punct de vedere sintactic, un document XML este format dintr-o colecie de elemente. n general, un element este un text cuprins ntre doua marcaje balansate, dar poate cuprinde i alte componente. Un principiu fundamental al XML este separarea marcajelor de coninut. Un corolar al acestui principiu spune c marcajul poate nconjura un coninut sau poate el nsui indica un coninut, cruia i adaug astfel semnificaie adiional. Sintaxa general a unui marcaj este: <nume_marcaj> Principalele tipuri de marcaje (tag-uri) sunt: marcajul de start, de forma <nume_marcaj>, marcajul de final, de forma </nume_marcaj> i marcajul vid28, cu sintaxa <nume_marcaj/>. Marcajul de start i de final demarcheaz nceputul, respectiv sfritul, elementului marcat. Marcajul vid este un exemplu de tag care indic un coninut. El nu include o informaie semantic ci are rolul de a indica includerea n document a unui obiect extern. 4.3.3 Elemente Putem introduce o definiie formal a termenului element XML. Un element XML este un container format din marcaj de start, din coninut propriu zis care poate fi format din caractere i/sau din subelemente XML i din marcaj de final, cu excepia marcajului vid care denot att marcajul de start ct i pe cel de final. Un element XML poate, la rndul lui, conine subelemente XML. Urmtorul exemplu conine, n HTML, descrierea unei lucrri pentru o conferin studeneasc:
27 28
parser empty 64
<H1>Solutii ASP pentru site de e-learning <H2> Ionescu Ana si Vasilescu Elena <ul> <li><B>Universitatea OVIDIUS Constanta</B> <li>Facultatea: Matematica si Informatica <li>Sectiunea: Programare in Internet <li>Referend1: acceptata <li>Referend2: acceptata cu modificari </ul>
Descrierea aceleiai lucrri n XML este urmtoarea:

<lucrare> <titlu> Solutii ASP pentru site de e-learning</titlu> <autor>Ionescu Ana</autor> <autor>Vasilescu Elena</autor> <univ>Universitatea OVIDIUS Constanta</univ> <facultatea>Matematica si Informatica</facultatea> <sectiunea>Programare in Internet</sectiunea> <referend>acceptata</referend> <referend>acceptata cu modificari</referend> </lucrare>
n varianta XML se observ o mai bun structurare i reguli mai stricte de apariie a marcajelor, precum i lipsa marcajelor de formatare a textului. 4.3.4 Atribute Elementele sunt descrise prin atributele ataate acestora. Atributele sunt perechi (nume, valoare). Atributele sunt unice. Pentru ca un document XML s fie acceptat din punct de vedere sintactic, el trebuie s fie bine format29. Un document este bine format dac marcajele sunt balansate i dac atributele sunt unice i au valorile reprezentate ca iruri de caractere ncadrate de ghilimele. Atributele pot s apar n tag-uri de tip start sau vid. Urmtorul exemplu ilustreaz utilizarea atributelor (limba i tip) pentru descrierea elementului marcat cu tag-ul <nume>. De asemenea, prima linie reprezint o declaraie xml care nu este obligatorie, dar care se recomand a fi utilizat.
Nume atribut Valoare atribut
<?xml version="1.0" ?> <lucrare> <nume limba=romana tip=short_paper>Solutii ASP</nume> <autor>Ionescu </autor> </lucrare>
Prin marcarea cu tag-uri a unui document, acesta este divizat n pri semantice. Un exemplu ar fi mprirea unui text n capitole i seciuni. Existena distinciei dintre diferite pri ale unui document permite clasificarea sau gruparea
29
well-formed 65
acestora, urmat de tratarea lor difereniat. n XML o astfel de clasificare ncepe prin impunerea restriciei ca un document valid s fie compus dintr-un singur element, numit rdcin, dar acel element poate conine alte elemente, astfel nct se poate crea o structur ierarhic a documentului. De aici deriv al doilea principiu fundamental n XML care spune c un document este clasificat ca membru al unui anumit tip prin divizarea prilor sale componente ntr-o structur ierarhic arborescent. De exemplu, documentele de tip HTML au ca rdcin elememtul HTML care poate conine un element HEAD i conine un element BODY. La rndul lor, aceste dou elemente pot conine diferite alte tipuri de subelemente. Putem deduce o alt funcie a XML, care este aceea de a clasifica toate prile unui document ntr-un singur set organizat ierarhic. Deci, un document XML conine un set de informaii organizat ntr-o structur arborescent. Aceasta are un element rdcin i orice alt element are un unic ascendent. Structura arborescent corespunztoare documentului precedent este reprezentat n figura urmtoare.
document
declaration nume
lucrare autor
attributes text Limba:romana Tip:short_pap text
Solutii ASP
Ionescu
Fig.4.1 Structura arborescent a unui document XML
ntre elementele unui document XML pot exista mai multe tipuri de relaii. Aceste tipuri sunt: secven, apariie, ierarhie, grupare, incluziune, referire. Combinaia de elemente i atribute permite modelarea cu XML att a datelor relaionale ct i a celor orientate obiect. Astfel, elementul XML este similar cu clasa din modelul orientat obiect i cu entitatea din modelul relaional. De asemenea, un atribut XML corespunde variabilei instan din modelul orientat obiect i relaiei din modelul relaional. 4.3.5 Referine ntr-un element se pot specifica referine la alte elemente. Structura unui document XML care conine elemente cu referine la alte elemente este o structur de tip graf. Pentru un element se poate preciza un identificator unic (ca valoarea a atributului id) care permite specificarea de referine (ca valori ale atributului idref) la elementul respectiv. Fie urmtorul document XML:
66
<?xml version="1.0" ?> <facultatea id=f1> <fnume>Matematica si Informatica</fnume> <fadr>Constanta</fadr> </facultatea> <lucrare> <nume limba=romana tip=short_paper>Solutii ASP</nume> <autor>Ionescu </autor> <sfacultate idref=f1>  </lucrare>
Reprezentarea sa cu o structur de tip graf este urmtoarea:

document
declaration
lucrare facultate nume autor sfacultate attributes attributes id fnume text fadr text
attributes text Limba:roman Solutii ASP Ionescu f1 text idref
Fig.4.2 Reprezentarea graf a unui document XML care conine o referin
4.3.6 Structura unui document XML Un document XML poate conine cinci tipuri de componente. Pe lng elementele marcate cu tag-uri, un document XML poate conine o seciune cu declaraii de tip, seciuni CDATA, comentarii i instruciuni de procesare. Ultimele trei tipuri au ca i caracteristic comun faptul c nu sunt supuse operaiei de analiz lexical, ci sunt luate ca atare i trimise altor interpretoare. Seciunile CDATA conin text, care poate fi, de exemplu, cod program. 4.3.7 Instruciuni de procesare XML nu este un limbaj pur descriptiv. El conine unui tip special de marcaj <?... ?> pentru a permite includerea de instruciuni de procesare. O instruciune de procesare conine numele unei aplicaii i parametrii de lansare ai acesteia. n exemplul urmtor este specificat lansarea aplicaiei cu parametrul document, a crui valoare specific fiierul pe care aceasta l va prelucra. <?excel document=lista.xls ?>
67
4.3.8
Restricii asupra documentelor XML
Restricii sintactice Specificaia XML definete dou nivele de conforman pentru documente: documente bine definite, care se supun unor reguli sintactice definite de consoriul W3C pentru a permite prelucrarea lor de ctre procesoare XML, i documente valide. Existena documentelor bine definite este obligatorie, pe cnd validitatea acestora este opional. Restricii semantice Fiecare instan XML trebuie validat la crearea sa, pentru a asigura acurateea tuturor valorilor datelor, ceea ce garanteaz interoperabilitatea acestora. Un document XML valid refer i satisface o schem. O schem este un document separat n care sunt definite regulile de construirea a elementelor, atributelor i structurii legale ale unei instane de document XML. O schem definete o clas, adic un tip particular, de documente. Deoarece validarea documentelor este costisitoare, la analizoarele logice XML se poate opta pentru executarea sau nu a acesteia. Pentru o mai bun performa, se recomand realizarea operaiilor de validare odat cu crearea documentului. 4.3.9 Definirea tipului unui document (DTD)
n general, un document XML este considerat valid i este acceptat din punct de vedere semantic dac se conformeaz unei definiii de tip realizat n format DTD(Data Type Definition) sau XMLSchema. O definiie de tip precizeaz marcajele permise, atributele acestora i restricii asupra valorilor lor, relaiile ntre marcaje ca i tipurile informaiilor marcate cu ele. Se definete astfel o gramatic pentru elementele unui tip de document. Cu o definiie de tip se definete, de fapt, un set de tipuri i un set de reguli gramaticale de utilizare a acestora. O definiie de tip n format DTD este realizat ntr-un fiier specializat, care ncepe cu indicarea versiunii. Apoi se definete un tip de document precizat n marcajul <!DOCTYPE ..., i se specific un nume pentru marcajul elementului rdcin. Urmeaz declaraiile celorlalte tipuri de componente ale documentelor XML descrise cu aceast gramatic. Tipurile de componente sunt: element, atribut, entitate, instruciune de procesare i notaie. Elementele se definesc cu construcia !ELEMENT, care precede numele tipului de element, folosit n documentul XML ca marcaj (tag) al elementelor de tipul respectiv, ca i lista de tipuri pe care le poate conine elementul respectiv. Acestea pot fi tipuri primitive (#PCDATA, CDATA) sau alte tipuri definite n DTD. Atributele sunt definite sub forma unei liste, !ATTLIST, ataat elementului pe care l descriu. Pentru fiecare atribut se specific numele, tipul sau o list de valori posibile, dac e obligatoriu sau opional, eventual o valoare implicit. n exemplul urmtor este prezentat definiia de tip pentru documentul XML precedent n care, pentru atribute se precizeaz seturile de valori permise i valoarea implicit.
68
<?xml version="1.0" ?> <!DOCTYPE lucrare[ <!ELEMENT lucrare (nume, ator)> <!ELEMENT nume (#PCDATA)> <!ELEMENT autor (#PCDATA)> <!ATTLIST nume limba (engleza, franceza, romana) engleza tip (short_paper, long_paper, DCT_paper) "short_paper"> ]>
O definiie de tip (DTD) conine instruciuni declarative. O declaraie este un meta-element care conine definiia formal a unui element. Pe lng elemente i atribute ale acestora, un document XML poate conine i entiti. Acestea pot fi de mai multe tipuri i sunt identificate prin nume. Entitile interne reprezint, n general, un text care va fi expandat, la momentul analizei sintactice, pentru a nlocui fiecare apariie a identificatorului entitii. Entitile externe sunt incluse prin referine la fiiere externe care pot conine fie cod XML, caz n care vor fi prelucrate ca i entitile interne, sau orice alt tip de informaie. Modul de procesare a entitilor externe ce nu conin cod este indicat n declaraii de tip !NOTATION. Spre deosebire de entitile interne, cele externe pot fi partajate de mai multe fiiere XML i orice modificare a lor este vizibil n fiierele care le refer. <!ENTITY un_ir Studenii de la MI> definete o entitate de tip ir de caractere cu identificatorul un_ir i valoarea Studenii de la MI. <!ENTITY cursSO SYSTEM SistemeOperare.doc> definete o entitate sistem de tip fiier extern, identificat prin cursSO i avnd ca valoare numele fiierului ce conine entitatea, SistemOperare.doc. Referirea pentru invocarea unei entiti n document se face utiliznd numele entitii precedat de &. n exemplul urmtor este definit o entitate curs:
<?xml version 1.0> <!DOCTYPE text [ <!ENTITY curs SYSTEM /cursuri/SistemeOperare> ]>
entitate ce poate fi referit apoi ntr-un document XML astfel:

<text <meta autor=CM an_univ=2002-2003/> <titlu> Sisteme de operare</titlu> &curs; </text>
Rezultatul referirii este inserarea ntregului fiier referit. Se pot defini, de asemenea, entiti parametru, pentru a fi folosite n interiorul DTD. Referirea acestora se face prin numele entitii precedat de semnul %.
69
DTD sunt create ntr-un limbaj specific, diferit de XML. Tipurile utilizate n documentele XML pot fi, de asemenea, definite utiliznd un concept mai modern dect DTD care este Schema XML. Acesta a permis unificarea definiiilor de tip prin utilizarea unei sintaxe XML care poate fi produs i utilizat cu instrumente standard. De asemenea, se pot defini i valida orice tipuri de date, utilizatorii i pot defini tipuri proprii, inclusiv tipuri de date structurate. Definiiile de tip reprezentate tot n XML asigur uniformitate cu restul documentelor XML, modularitate i extensibilitate.
4.4 Terminologie i definiii

n acest moment este necesar i posibil introducerea sau reformularea definiiilor principalilor termeni utilizai n continuare. - Modul abstract unitate de specificare a tipului de document corespunztoare unui tip distinct de coninut i pentru care exist o construcie de marcare ce reflect acest tip. - Model coninut structura de marcare declarat permis n interiorul instanelor unui tip de element. Se disting dou tipuri de element: cele care conin doar elemente i cele cu coninut mixt format din elemente dar posibil i din date de tip caracter caracterizate de o specificare de coninut ce ncepe cu irul #PCDATA#. - Model document reprezint structura propriu-zis i constrngerile unui tip de document. El constituie reprezentarea abstract a structurilor fizice sau semantice ale unei clase de documente. - Tip document reprezint o clas de documente cu structur abstract comun. Documentele de acelai tip au caracteristici similare. - Definiie tip document (DTD) o expresie formal, interpretabil de ctre maina de calcul, a regulilor structurii i sintaxei XML crora trebuie s se conformeze instana unui tip de document specific. DTD este un tip de schem, utilizat pentru a valida faptul c o instan a documentului este conform cu tipul declarat al documentului repectiv. - Driver fiier de dimensiuni reduse utilizat pentru a declara i a instania modulele unui DTD. Acesta nu trebuie s conin nici o declaraie de marcare care s cuprind o parte a nsui modelului document. - Element instan a unui tip de element. - Tip element definiia unui element, un container pentru o clasa semantic distinct a coninutului document. - Entitate unitate de memorare fizic sau logic pentru un coninut document. Entitile pot fi compuse din marcaje XML analizabile lexical, sau din date caracter, sau pot avea coninut ce nu este analizabil lexical fa de definiiile XML (non-XML i posibil non-textual). Entitile pot fi interne, avnd coninutul definit n ntregime n entitatea document, sau externe, cu coninutul definit n exteriorul entitii document. n cazul entitilor analizate lexical, textul de nlocuire poate include referine la alte entiti. - Referin la entitate ir mnemonic utilizat ca referin la coninutul unei entiti declarate. (ex. & pentru &, < pentru <,© pentru .). - Faciliti - elemente, atribute i semantici asociate cu acele elemente i atribute.
70
Identificator generic nume care identific tipul unui element. Document hibrid document care utilizeaz mai multe spaii de nume XML. Documentele hibride pot fi definite ca documente care conin elemente i atribute din mai multe tipuri de documente. Instaniere nlocuirea unei referine la o entitate cu o instan a coninutului su declarat. Declaraie de marcare construcie sintactic n cadrul unui DTD care declar o entitate sau definete o structur de marcare. n cadrul declaraiilor de tip document XML exist patru tipuri specifice: declaraia entitate definete legtura dintre un simbol mnemonic i coninutul cu care este nlocuit; declaraia element indic tipurile de elemente ce pot s apar ca descendeni ai unui element; declaraia de list de definiii atribut definete setul atributelor unui tip dat de element i poate, de asemenea, stabili constrngeri de tip i valori implicite; declaraia de notaie definete legtura ntre numele unei notaii i un identificator extern ca referin la formatul unei entiti neanalizat lexical. Model de marcare vocabularul de marcare, format din nume de elemente i de atribute, din notaii, etc., i gramatica, care conine definiiile de utilizare a vocabularului Modelul de marcare este reprezentarea concret n sintaxa marcajelor a modelului document i poate fi definit cu nivele variabile de conformitate strict. Acelai model document poate fi exprimat cu o varietate de modele de marcare. Modul unitate abstract n cadrul unui model document, exprimat ca un fragment al unei declataii de tip i utilizat pentru a consolida declaraiile de marcare n scopul creterii felxibilitii, modificabilitii, reutilizrii i nelegerii structurilor logice sau semantice specifice. Modularizare implementare a unui model de modularizare; procesul de compunere sau descompunere a unui DTD sau a unei XMLSchema prin divizarea declaraiilor sale de marcare n uniti sau grupuri, pentru a suporta eluri specifice. Modulele pot exista sau nu ca entiti fiier separate. Model de modularizare planul abstract al unei declaraii de tip care s suporte scopurile modularizrii cum ar fi reutilizarea, extensibilitatea, expresivitatea, utilizarea documentrii, dimensiunea codului, consistena i intuitivitatea utilizrii. Modelul de modularizare este relaionat ortogonal cu modelul document pe care l descrie, astfel nct dou modele de modularizare foarte diferite pot descrie acelai tip de document. Entitate parametru entitate al crei domeniu de utilizare este prologul documentului (adic subsetul extern/DTD sau subsetul intern). Entitile parametru nu sunt permise n instana documentului. Tipul documentului printe tipul documentului printe al unui document hibrid este tipul document al elementului rdcin. Tag marcaj descriptiv care delimiteaz nceputul i sfritul (inclusiv identificatorul generic i orice atribute) unui element.
71
4.5 XML Schema

4.5.1 Caracterizare XMLSchema XMLSchema este un limbaj de definiii care permite condiionarea documentelor XML de a se conforma unui vocabular specific i unei anumite structuri ierarhice. Pentru aceasta se definesc tipurile elementelor, tipurile atributelor i compunerea acestora n tipuri complexe30. Se ofer astfel o modalitate de a defini structura, coninutul i semanticile documentelor XML, permind partajarea acestora n medii distribuite. Definiiile dintr-un document de tip XMLSchema sunt regulile dup care se construiesc instane multiple de documente XML care se conformeaz schemei repective. O schem XML definete o clas de documente XML, astfel c un document XML este o instan a schemei creia i se conformeaz. n fig. 4.3. este ilustrat dublul rol pe care l are o schem XML, cel de model pentru generarea de instane ale unui tip de document i cel de suport pentru validarea acurateei documentelor respective. Un document ce conine o schem XML este, la rndul su, un document XML, ceea ce asigur o sintax uniform att pentru definiii ct i pentru documentele instan. Aceasta permite utilizarea unui analizor sintactic unic.
Schema
Schema ca ablon generare
Schema ca instrument de validare verificare
Interfee
Instane valide
Fig.4.3 Schem i instane
Instane invalide
30
XMLSchema este analog unei scheme a unei baze de date. 72
Fiecare instan de document trebuie s declare documentul ce conine schema pe care o respect. Aceast declaraie se face ntr-un atribut special ataat elementului rdcin i numit "xsi:noNamespaceSchemaLocation" sau "xsi:schemaLocation". 4.5.2 Structura unei scheme XML O schem XML utilizeaz sintaxa XML pentru a realiza un set de declaraii de tip pentru tipuri simple i complexe. Un tip este identificat printr-un nume i poate pstra una sau mai multe valori. Un tip simplu conine o singur valoare, iar tipurile complexe sunt formate din tipuri simple i multiple. Tipuri simple Tipurile simple pot fi tipuri predefinite i tipuri definite de utilizator pe baza tipurilor predefinite. Principalele tipuri predefinite n XMLSchema sunt string, boolean, ID (identificator unic), IDREF (referin la un ID), integer, long, int, short, decimal, float, double, date i time. Un tip simplu este o declaraie de element care include numele i restriciile asupra valorii. De exemplu, definiia unui element identificat prin numele autor i despre care se precizeaz c poate conine oricte caractere text este de forma: <xsd:element name="author" type="xsd:string" /> Conform acestei definiii, un document instan poate avea un element <author>Popescu Ana</author> Limbajul pentru definirea schemelor XML utilizeaz o abstractizare pentru un tip care este baza de la care se poate deriva orice tip simplu sau complex. Aceasta este reprezentat de tipul anyType, care poate fi utilizat ca orice alt tip i nu impune nici o restricie de coninut. Se pot defini noi tipuri simple utiliznd tipurile simple existente, la care se pot aplica restricii suplimentare. Pentru aceasta se utilizeaz elementul simpleType, n care se indic numele elementului nou definit i elementul restriction, n care se precizeaz elementul de baz i restriciile suplimentare asupra acestuia. n exemplul urmtor se definete un nou tip simplu, numit zeciDeMii, i derivat din tipul simplu integer, care poate lua valori de la 10000 la 99999.
<xsd:simpleType name="zeciDeMii"> <xsd:restriction base="xsd:integer"> <xsd:minInclusive value="10000"/> <xsd:maxInclusive value="99999"/> </xsd:restriction> </xsd:simpleType>
Restriciile impuse asupra noului tip se pot indica, de asemenea, pe baza unor abloane definite ntr-un element pattern a crui valoare este o expresie
73
regulat31. Un alt element pentru precizare de astfel de restricii este enumeration, care permite definirea unui set de valori posibile pentru elementul derivat. Tipurile simple predefinite ca i cele derivate din acestea sunt considerate tipuri atomice, n sensul c o valoare a unui astfel de tip este indivizibil din punct de vedere al schemei XML: n XMLSchema exist i doua tipuri simple care nu sunt atomice: tipul list i tipul union. Un element de tip list sau de tip union poate fi creat doar din tipuri atomice. Tipului list i se pot aplica restricii suplimentare numite faete (facets), care pot fi de tip length, minLength, maxLength, pattern, sau enumeration. Iat un exemplu de definire a unui tip simplu numit Student:
<xsd:simpleType name="Student"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Ana"/> <xsd:enumeration value="Maria"/> <xsd:enumeration value="Vlad"/>  </xsd:restriction> </xsd:simpleType>
definirea unui tip list cu elemente de tip Student:

<xsd:simpleType name="ListaStudenti"> <xsd:list itemType="Student"/> </xsd:simpleType>
i definirea unui tip Grupa ca tip derivat din lista de studeni:

<xsd:simpleType name="Grupa"> <xsd:restriction base="ListaStudenti"> <xsd:length value="5"/> </xsd:restriction> </xsd:simpleType>
Elementele de tip Grupa au cinci componente, fiecare fiind una din valorile atomice enumerate n tipul Student, ca n exemplul urmtor: <Grupa>Ana Maria Ion Dan Vlad</Grupa> Tipurile definite cu union conin o list de tipuri. Un element valid de tipul definit prin union poate avea, la un moment dat, unul din tipurile specificate n lista respectiv. Tipuri complexe Un tip complex este un element care fie conine alte elemente, fie are ataate atribute, fie ambele. Definirea unui tip complex se face utiliznd elementul complexType. Definiia conine un set de declaraii de elemente, referine de
31
Exprimat ntr-un limbaj descris n specificaiile XMLSchema de la www.w3.org. 74
elemente i declaraii de atribute. O declaraie ntr-o schem XML este o asociere ntre un nume i restriciile care guverneaz apariia acelui nume n documentele care se conformeaz schemei respective. Elementele sunt declarate cu elementul element, iar atributelele cu elementul attribute. Un exemplu de tip complex cu atribute multiple poate fi definiia unei cri cu atributele titlu i pagini astfel:
<xsd:element name="carte"> <xsd:complexType> <xsd:attribute name="titlu" type="xsd:string" /> <xsd:attribute name="pagini" type = "xsd:int" /> </xsd:complexType> </xsd:element>
Aceast declaraie spune c orice element identificat prin carte ce apare ntr-un document XML instan a acestei scheme trebuie s conin atributele titlu de tip ir de caractere i pagini de tip ntreg. O instan XML a elementului de tip carte poate fi <carte titlu = "Programare in Web" pagini="310" /> Tipurile complexe se definesc utiliznd elementul complexType. Prin utilizarea subelementului complexContent, se specific un tip complex format din subelemente. Subelementele unui tip complex pot fi obinute prin extindere, specificat ntrun element extension al crui atribut base are ca valoare numele tipului extins. n modelul coninutului unui tip obinut prin extindere se motenesc definiiile tipului baz, crora li se adaug definiiile specificate n derivare. Urmtorul exemplu ilustreaz derivarea unui tip complex din tipul simplu predefinit decimal:
<xsd:element name="Pret"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:decimal"> <xsd:attribute name="moneda" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>
Un exemplu de definiie a unui tip complex care are att atribute multiple ct i subelemente este definiia unui produs care are trei atribute, id, titlu i pret, i dou subelemente, descriere i categorie. Atributele minOccurence i maxOccurence precizeaz restricii asupra numrului de apariii ale subelementului respectiv n cadrul unui element printe. Valorile lor sunt numere ntregi ncepnd cu 0, sunt considerate implicit sunt 1 i maxOccurence poate avea i valoarea unbound, care specific un numr nelimitat de apariii posibile. Conform valorilor acestor atribute, n exemplul urmtor
75
subelementul categorie este obligatoriu i repetabil iar subelementul descriere este opional. Declaraia xsd:string se refer la un ir ca la o secven de caractere, acesta fiind unul din tipurile simple, predefinite32 n specificaiile XMLSchema.
<xsd:element name="produs"> <xsd:complexType> <xsd:sequence> <xsd:element name="descriere" type="xsd:string" minOccurs="0" maxOccurs = "1" /> <xsd:element name="categorie" type="xsd:string" minOccurs = "1" maxOccurs = "unbounded" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" /> <xsd:attribute name="titlu" type="xsd:string" /> <xsd:attribute name="pret" type="xsd:decimal" /> </xsd:complexType> </xsd:element>
Aceast declaraie spune c orice element identificat prin produs i care apare ntr-un document XML instan a acestei scheme trebuie s conin cel mult un subelement descriere de tip ir de caractere, cel puin un element categorie de tip ir de caractere, atributul titlu de tip ir de caractere i atributul pret de tip numr zecimal. O instan XML care se conformeaz acestui tip este urmtoarea:
<produs id="P01" titlu="Suport curs SO" pret="300"> <descriere> Suport pentru cursul de teoria sistemelor de operare. </descriere> <categorie>curs</categorie> <categorie>informatica</categorie> </produs>
O alt instan poate fi de forma:

<produs id="P02" titlu="Laborator SO" pret="89.99"> <categorie>laborator</categorie> <categorie>carte</categorie> <categorie>informatica</categorie> </produs>
Pentru a impune restricii asupra apariiei atributelor, n definiia acestora apare atributul use care poate avea una din valorile: required pentru a indica faptul c atributul este obligatoriu, optional, indicnd c nu trebuie definit, i prohibited, adic apariia atributului este interzis. Atributul default indic valori implicite ale elementelor i atributelor definite n schema XML. Cu valorile declarate default se nlocuiesc elementele care apar n instanele schemei dar care nu conin nimic. De asemenea, se nlocuiesc atributele care nu apar n elementele din instana schemei respective. Atributul fixed precizeaz valori obligatorii33 pentru atributul sau elementul din a crui definiie face parte.
32
primitive 76
Un caz particular este tipul complex vid, care corespunde elementelor al cror model coninut este vid. Pentru aceasta se definete un tip format din subelemente, dar pentru care nu se declar nici un subelement. n exemplul urmtor se definete un tip anonim care are coninut complex, adic e format doar din elemente.
<xsd:element name="Pret"> <xsd:complexType> <xsd:complexContent> <xsd:restriction base="xsd:anyType"> <xsd:attribute name="moneda" type="xsd:string"/> <xsd:attribute name="valoare" type="xsd:decimal"/> </xsd:restriction> </xsd:complexContent> </xsd:complexType> </xsd:element>
Utilizarea elementului complexContent semnaleaz c modelul coninut al unui tip complex va fi restricionat sau extins. Aplicarea restriciei anyType declar dou atribute dar nu i un element coninut. O sintax simplificat pentru exemplul anterior se bazeaz pe faptul c un tip complex este implicit format dintr-un element complexType care restricioneaz anyType.
<xsd:element name="Pret"> <xsd:complexType> <xsd:attribute name="moneda" type="xsd:string"/> <xsd:attribute name="valoare" type="xsd:decimal"/> </xsd:complexType> </xsd:element>
Dac un element are atribute multiple, definirea acestora se poate face fie inline, fie sub forma unui grup, marcat cu xsd:attributeGroup, cruia i se ataaz un identificator. Acest grup este referit, utiliznd acest identificator, de ctre un alt element xsd:attributeGroup din cadrul definiiei tipului complex. Aceast form de definire permite modularizarea definiiilor din schemele XML complexe. n general, absena unui element dintr-un document XML, instan a unei scheme XML, poate indica faptul c informaia este necunoscut, sau nu este aplicabil, sau elementul lipsete dintr-un alt motiv oarecare. Pentru a preciza faptul c informaia este necunoscut sau inaplicabil se utilizeaz un element numit nil, iar utilizarea acestuia este specificat la nivelul elementului prin atributul nillable="true".
4.6 Spaii de nume i calificatori

Ca n orice limbaj, n aplicaiile XML este necesar delimitarea spaiilor de nume, adic a domeniilor n care identificatorii de tip nume s se conformeze modelului de date set. Aceasta nseamn c orice identificator este unic n cadrul unui spaiu de nume.
33
Atributele fixed i default se exclud reciproc. 77
Acest lucru este cu att mai necesar cu ct aplicaiile Internet au un domeniu vast de aciune i, de exemplu, reutilizarea definiiilor de tip conduce la poteniale conflicte de nume. XMLNamespaces este mecanismul prin care se realizeaz evitarea conflictelor de nume n documentele XML. Acest mecanism implementeaz urmtoarele patru reguli: 1. Setul numelor34 elementelor unui document XML poate fi local sau poate fi asignat unui spaiu de nume global unic. 2. Un spaiu de nume este identificat n mod unic printr-un URI care trebuie s fie unic i persistent. 3. Fiecrui astfel de URI i se asociaz, n cadrul documentului XML, un nume scurt care se conformeaz sintaxei XML. Numele complet are dou componente desprite prin caracterul :. Prima component este un prefix35 care funcioneaz ca un proxy pentru URI-ul spaiului de nume iar a doua reprezint numele local36, n cadrul spaiului de nume. 4. n urma analizei sintactice prefixul este pus n coresponden cu URI-ul, pentru a furniza nume globale unice complete. Numele complet construit conform regulii 3 este un nume calificat (Qualified Name QName). O aplicaie XML este un limbaj pentru un anume tip de documente i are marcajele asociate cu un anumit spaiu de nume. De exemplu, documentele generate de aplicaia XSLT au <xsl:stylesheet> ca element rdcin. Acest element are un atribut prin care se stabilete corespondena ntre un prefixul ce identific spaiul de nume, xsl, i un URI, ca n exemplul urmtor: <xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform> Utilizarea unui URI are ca prim scop generarea unui nume unic universal n spaiul aplicaiilor Internet. Asocierea prefixURI este esenial, deoarece se pot ntlni prefixe identice care sunt ns asociate la diferite URI, genernd astfel spaii de nume diferite. Implementarea spaiilor de nume se bazeaz pe faptul c fiecare nume XML este format din dou componente: prefix i component local.
prefix Component local
<xsd:integer> n exemplul anterior apare un identificator de tip de element a crui component local este identificatorul metadatei, iar prefixul este o abrevierea pentru spaiul de nume cruia i aparine acest identificator. Acest spaiu de nume este o resurs identificat unic prin URI. Spaiile de nume reprezint un mecanism simplu pentru crearea de nume unice globale pentru elementele i atributele unui limbaj de marcare. Aceasta elimin
34 35
Cu restricia ca numele s nu conin caracterul :. Este un nume scurt asociat spaiului de nume. 36 Acesta poate conine caracterul :. 78
conflictele datorate denumirilor identice din limbaje de marcare diferite, ceea ce permite mixarea neambigu a mai multe limbaje de marcare37. Unul din avantajele oferite de XMLSchema este uniformitatea, n sensul c un document cu definiii de schem este un document XML. La rndul lui, acesta trebuie s se conformeze unei scheme i va folosi un vocabular specific pentru aceste definiii. Spaiul de nume utilizat de XMLSchema este identificat prin URL-ul http://www.w3.org/2001/XMLSchema cruia, printr-o definiie de forma xmlns:xsd=http://www.w3.org/2001/XMLSchema, i se asociaz prefixul xsd38. Acest prefix este o abreviere pentru spaiul de nume identificat prin URI-ul http://www.w3.org/2001/XMLSchema, pe care l reprezint n cadrul unui nume XML. n acest spaiu de nume se afl identificatorii elementelor i tipurilor simple din schemele XML. Astfel a fost declarat un spaiu de nume pentru toate elementele unei scheme XML, care sunt utilizate n documente de tip XMLSchema. Pentru a specifica spaiul de nume al elementelor nou definite n schem se utilizeaz atributul targetNamespace, ca n urmtorul exemplu:
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:sa="http://www.unSite/SchA" targetNamespace="http://www.unSite/SchA"> <element name="Elem_1" type="sa:Tip_Elem_1"/> <element name="Elem_2" type="string"/> <complexType name="Tip_Elem_1">  </complexType>  </schema>
n exemplul precedent atributul xmlns are ca valoare spaiul de nume al elementelor de definire a oricrei scheme XML, iar atributul xmlns:sa are ca valoare un subspaiu al acestuia, anume cel definit n schema curent. Acest subspaiu este, de asemenea, i spaiul int al elementelor definite n schema curent. Astfel, se observ c valoarea atributului type pentru elementul Elem_1 este un tip definit tot n schema curent, de aceea numele lui este precedat de prefixul spaiului de nume ce reprezint aceast schem. Spaiile de nume int utilizate n documente ce definesc scheme XML au ca rol validarea spaiilor de nume corespunztoare din documentele XML instan ale schemei ce specific spaiul de nume int. Un spaiu de nume se aplic unui document fie prin ataarea prefixului la fiecare element i atribut al acestuia, fie prin declararea sa ca spaiu de nume implicit al documentului respectiv astfel:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Spaiu de nume implicit</title> </head> <body>Test pentru spaiul de nume implicit</body> </html>
37 38
Spaiile de nume sunt integral suportate de XMLSchema, nu i de DTD. Acest prefix este consacrat, dar nu este obligatoriu. 79
Documentul din exemplul anterior este translatat de ctre un analizor XML n urmtoarea reprezentare text:
<{http://www.w3.org/1999/xhtml}html> <{http://www.w3.org/1999/xhtml}head> <{http://www.w3.org/1999/xhtml}title>Spaiu de nume implicit </{http://www.w3.org/1999/xhtml}title> </head> <{http://www.w3.org/1999/xhtml}body>Test pentru spaiul de nume implicit </{http://www.w3.org/1999/xhtm}body> </{http://www.w3.org/1999/xhtml}html>
Autorul unei scheme XML este cel care decide dac apariia elementelor declarate local ntr-o instan trebuie sau nu calificat pe baza unui spaiu de nume i precizeaz acest lucru specificnd c se va utiliza explicit sau nu un prefix pentru numele elementelor respective. Necesitatea calificrii elementelor i atributelor locale se poate specifica global, utiliznd perechea de atribute elementFormDefault i attributeFormDefault pentru elementul schema, sau se poate specifica separat la nivelul fiecrei declaraii locale prin atributul form. Valorile acestor atribute, qualified sau unqualified (valoarea implicit), indic faptul c atributul sau elementul respectiv trebuie sau nu calificat. De exemplu, ntr-un fiier Schema_A.xsd se specific necesitatea calificrii doar a elementelor, utiliznd valoarea qualified pentru atributul elementFormDefault i valoarea unqualified pentru atributul attributeFormDefault, astfel:
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:sa="http://www.unSite/SchA" targetNamespace="http://www.unSite/SchA" elementFormDefault="qualified" attributeFormDefault="unqualified"> <element name="Elem_1" type="sa:Tip_Elem_1"/> <element name="Elem_2" type="string"/> <complexType name="Tip_Elem_1">  </complexType>  </schema>
Fig.4.4 Extras din fiierul Schema_A.xsd
Un document XML instan a schemei definit n fiierul Schema_A.xsd de mai sus va califica toate numele de elemente, astfel:
80
<?xml version="1.0"?> <asa:Elem_1 xmlns:asa="http://www.unSite/SchA"> <asa:SubElem_1 atr_1=val_1> <asa:SubElem_11>unText</asa:SubElem_11> <asa:SubElem_12>altText</asa:SubElem_12>  </asa:SubElem_2>  </asa:SubElem_2> </asa:Elem_1>
Alternativ, se poate nlocui calificarea explicit cu una implicit bazat pe definirea unui spaiu de nume implicit, prin xmlns="http://www.unSite/SchA, ca mai jos:
<?xml version="1.0"?> <Elem_1 xmlns="http://www.unSite/SchA"> <SubElem_1 atr_1=val_1> <SubElem_11>unText</asa:SubElem_11> <SubElem_12>altText</asa:SubElem_12>  </SubElem_2>  </SubElem_2> </Elem_1>
Schemele de dimensiuni mari pot fi mprite n module reprezentate n fiiere diferite. Unificarea definiiilor din mai multe module se face utiliznd clauza include. n exemplul urmtor sunt evideniate dou module, al doilea specificnd includerea definiiilor din primul modul.
<schema targetNamespace="http://www.unSite/UNIV" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:unv="http://www.unSite/UNIV"> ...  <include schemaLocation="http://www.unSite/scheme/facultati.xsd"/> ...
Fig.4.5 Extras din fiierul universitate.xsd
Fiierul inclus este de forma:

<schema targetNamespace="http://www.unSite/UNIV1" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:unv="http://www.unSite/UNIV"> ...
Fig.4.6 Extras din fiierul facultati.xsd
Efectul directivei include este acela c definiiile coninute n facultati.xsd devin disponibile ca parte a spaiului de nume int al schemei
81
universitate.xsd. Spaiul de nume int al modulelor incluse trebuie s fie acelai cu cel al schemei ce le include. n general, o schem poate include module multiple care pot include, la rndul lor, alte module, rezultnd astfel o ierarhie de module. Condiia este aceea ca toate s fie declarate cu acelai spaiu de nume int. Documentele XML instane ale schemelor reprezentate n module multiple trebuie s refere doar la documentul din vrful ierarhiei de definiii i spaiul de nume comun acestora.
4.7 Familia de limbaje XML

Aa cum am menionat, XML propriu-zis este un subset al specificaiei SGML conceput pentru o implementare mai uoar a aplicaiilor Internet. Pe baza lui au fost definite o serie de limbaje i mecanisme necesare dezvoltrii aplicaiilor n Web. Enumerm n continuare principalele componente ale familiei de limbaje XML i relaiile dintre acestea. XLink reprezint o specificaie pentru definirea de legturi ntre documente i pri ale acestora. XLink este utilizat de SVG, prezentat mai jos, i poate utiliza XPointer. XPointer este mecanismul utilizat n adresarea nodurilor, a domeniilor i pentru a referi entiti din documente XML locale sau la distan (aflate pe alte maini virtuale). Este utilizat n XLink i n XInclude. XLL (Linking) este un set de mecanisme hipertext format din subseturile XLink utilizat pentru descrierea de legturi ntre obiectele Internet i XPointer cu care se pot defini termeni de localizare relativi la alte locaii. XInclude este un alt mecanism XML utilizat pentru a include mai multe documente externe ntr-un document cupriztor. XSL(Extensible Stylesheet Language) este limbajul standard al foilor de stil, destinat definiiilor de formatare i afiare a informaiilor din documente XML. XSLT(Extensible Stylesheet Language: Transformations) este limbajul n care se specific definiii pentru transformri ale documentului n vederea prezentrii acestuia conform definiiilor din foile de stil. XSLT este un limbaj puternic pentru rearanjarea i modificarea coninutului unui document. Utilizeaz XPath ca mecanism de adresare. Sub-familia format din XSL, XSLT i XLSFO(Extensible Stylesheet Language: Formatting Objects) este utilizat pentru a realiza transformarea i formatarea documentelor XML. XUA(User Agent) este un limbaj conceput pentru agenii utilizator i propune o direcie de standardizare a navigatoarelor XML. XPath este mecanismul standard de adresare pentru nodurile XML i este utilizat de majoritatea acestor tehnologii. XQuery este un limbaj de interogare pentru documentele XML. O interogare definit n acest limbaj este capabil s extrag i s prelucreze acele poriuni din documentele XML care se conformeaz unui anumit criteriu. XQuery partajeaz acelai model de date cu XPath i este o extindere a acestuia. XML Schema, aa cum am vzut deja, este limbajul bazat XML de definire a marcajelor. El permite definirea de nume legale i restricii pentru componente i atribute ca i structura ierarhic a documentelor XML. XMLBase este un mecanism pentru rezolvarea URI-urilor relative.
82
XHTML este o reformulare a HTML ca aplicaie XML, cu restricii semantice suplimentare fa de HTML. XForms este un mecanism puternic bazat pe XML pentru procesarea formularelor n Web. El utilizeaz XPath ca mecanism pentru adresare. SVG este un limbaj pentru redarea coninului documentelor cu coninut grafic bogat. Utilizeaz mecanismul XLink. Principalele direcii de utilizare a XML sunt crearea de documente pentru publicare n Internet, codificarea datelor, inclusiv a celor extrase din baze de date relaionale, configurarea aplicaiilor, dezvoltarea de vocabulare specifice diferitelor domenii. Fa de HTML, tehnologiile bazate pe XML realizeaz separarea prezentrii de coninut, iar coninutul este organizat i are semnificaie. In cadrul documentelor, XML marcheaz zone de text introducnd informaii despre structurarea i despre semantica textului. Astfel se definesc tipuri de date text asupra crora se pot specifica orice tipuri de prelucrri. Un tip de prelucrare este formatarea datelor n vederea prezentrii lor. Dac HTML este utilizat pentru marcarea de zone de text n vederea specificrii prelucrrilor de tip prezentare, n tehnologia XML prezentarea datelor, structurate n fiiere XML, este separat exclusiv n fiiere speciale, de tip foi de stil. Un alt tip de prelucrare este rearanjarea i filtrarea datelor n vederea comunicrii ntre aplicaii. O variant a acestui tip de prelucrare este destinat comunicrii cu sisteme de gestiune a bazelor de date. XML este un meta-limbaj care se bazeaz pe un nucleu i care posed un mecanism de creare de noi marcaje utilizat pentru extinderea nucleului limbajului Prin extinderea acestui nucleu se obin limbaje orientate pe diferite domenii i necesiti. n continuare vom detalia aceste tehnologii bazate XML. 4.7.1 XPath Caracteristicile limbajului XPath este un limbaj pentru definirea, folosind expresii regulate, a cilor unei structuri arborescente. El este destinat pentru crearea de expresii care specific seturi de ci ce satisfac o anumit condiie sau se potrivesc unui anumit ablon. Se ofer astfel o facilitate puternic i flexibil de conectare a diferitelor componente din Internet astfel nct att sursa ct i destinaiile unei legturi s poat fi specificate n termeni structurali. n particular, XML Path Language este un limbaj pentru construirea de expresii destinate adresrii diferitelor pri ale unui document XML. Limbajul definete semantici, sintax i funcionalitate cheie pentru alte standarde ca XSLT, XPointer i XQuery. XPath este folosit n diferite API i cadre software pentru a facilita i unifica referirea la componente individuale ale unui document XML. n plus fa de adresarea diferitelor zona ale unui document XML, XPath ofer funcionaliti de baz pentru manipulare de tipuri primitive: numere, iruri i boolean. XPath are o sintax compact pentru a facilita utilizarea sa mpreun cu URI-uri i cu valori ale atributelor XML. Utilizeaz o notaie asemntoare cilor URL de navigare prin structuri ierarhice. Elementul constructiv de baz este expresia, reprezentat ca ir de caractere. Expresiile sunt construite din cuvinte cheie, simboluri i operanzi. XPath este un limbaj funcional, expresiile putnd fi ncuibate, i puternic tipat, ceea ce nseamn c
83
operanzii, operatorii i funciile trebuie s se conformeze strict definiiilor de tipuri corespunztoare lor. Contextul unei expresii date este reprezentat de totalitatea informaiilor care pot afecta rezultatul acesteia. Contextul complet este format din contextul static i contextul dinamic. Contextul static al unei expresii este dat de informaiile disponibile analizei statice a expresiei care precede evaluarea acesteia. Informaiile din contextul static sunt utile n depistarea erorilor statice. Contextul dinamic al unei expresii se definete ca fiind totalitatea informaiilor disponibile n momentul evalurii expresiei i permite depistarea erorilor dinamice. Contextul static este iniializat cu un set, determinat de limbajul gazd, de tipuri predefinite. Acestea sunt definite n spaiile de nume http://www.w3.org/2001/XMLSchema identificat prin prefixul xs i http://www.w3.org/2004/10/xpath-datatypes identificat prin prefixul xdt. n figura urmtoare este reprezentat ierarhia tipurilor XPath.
xs:anyType xs:anySimpleType xdt:untyped i tipuri complexe specifice
xdt:anyAtomicTyp
tipuri specifice, list i union cum ar fi xs:IDREFS
xdt:untypedAtomic i tipuri atomice specifice cum ar fi xs:integer, xs:string i xdt:dayTimeDuration
Fig.4.7 Ierarhie de tipuri XPath
Expresii n continuare sunt descrise formele de baz ale expresiilor XPath. O expresie XPath poate fi format din dou expresii singulare separate prin virgul. O expresie singular poate fi expresie repetitiv (for), expresie cuantificat, expresie decizional (if), sau expresie logic (and sau or). Expresiile primare sunt primitivele de baz ale limbajului i pot include literali, referine la variabile, expresii entitate context i apeluri de funcii. O expresie poate include paranteze pentru a specifica ordinea de realizare a operaiilor. Un literal este reprezentarea sintactic direct a unei valori atomice. n XPath exist literali numerici i literali ir de caractere. O referin la variabil este reprezentat prin QName precedat de caracterul $. Dou astfel de referine sunt echivalente dac numele lor locale sunt identice i prefixele sunt conectate la acelai URI de spaiu de nume. Din evaluarea unei expresii entitate context rezult o entitate context ce poate fi un nod (fn:doc("bib.xml")/books/book[fn:count(./author)>1]) sau o valoare atomic ((1 to 100)[. mod 5 eq 0]). Dac entitatea context nu este definit, expresia genereaz o eroare dinamic.
84
n expresii XPath se pot apela att funcii predefinite ct i funcii definite de utilizator39 oferite n contextul static. Apelul unei funcii se face specificnd un QName pentru numele funciei i lista argumetelor acesteia ncadrat de paranteze. O expresie ce reprezint o cale const dintr-o serie de unul sau mai muli pai separai de / sau //. Separatorul / sau // folosit la nceputul cii reprezint unul sau mai muli pai iniiali adugai implici la nceput. Separatorul / reprezint fn:root(self::node()) treat as document-node(), nodul rdcin, care trebuie s fie de tip document, a arborelui ce conine nodul context. Separatorul // reprezint fn:root(self::node()), treat as documentnode()/descendent-or-self::node()/, adic paii iniiali pentru stabilirea unei secvene ce conine nodul rdcin i toate nodurile descendent40 ai acesteia. O cale este format din subsecvene E1/E2 care se evalueaz de la stnga la dreapta. Secvenele rezultate din toate evalurile lui E1 reprezint o intrare pentru una din evalurile lui E2. Toate secvenele rezultate din evalurile unei expresii trebuie s conin entiti de acelai tip, adic fie noduri context, fie valori atomice41. Secvenele rezultate din evaluarea lui E2 sunt combinate astfel: - n cazul secvenelor de noduri, rezultatul este o secven obinut prin combinare i eliminarea nodurilor duplicat - n cazul secvenelor de valori atomice, rezultatul este obinut prin concatenarea, n ordine, a acestora. De exemplu, expresia child::div/child::para selecteaz elementul para descendent al elementului div1, descendent la rndul su al nodului context. Un pas genereaz o secven de entiti pe care apoi o filtreaz cu zero sau mai multe predicate. Valoarea obinut pentru pasul respectiv este format din entitile care satisfac aceste predicate. Aplicarea predicatelor pentru secvene ce conin noduri se face indicnd direcia de deplasare n arbore, numit ax, i un test la nivel de nod care selecteaz nodurile pe baz de fel, nume i/sau tip. n expresia child::para, child este numele axei iar para numele nodurilor element selectate de pe acest ax. Axele pentru traversarea documentului sunt orientate n dou sensuri: forward i reverse. n sensul forward este disponibil setul format din axele child, descendent, attribute, self, descendant-or-self, followingsibling, following i namespace, iar n sensul reverse axele parent, ancestor, preceding-sibling, preceding i ancestor-or-self. Testul la nivel de nod se face n baza unei condiii care indic felul nodului (element, atribut, text, document, comentariu sau instruciune de procesare), numele sau tipul acestuia42. Fiecare ax are un fel principal de noduri pe care le conine. Un test * este adevrat pentru orice nod de felul principal al axei. De exemplu, child:: * selecteaz toate elementele fii ai nodului context, iar attribute:: * selecteaz toate atributele nodului context.
39 Se va folosi mecanismul oferit de limbajul gazd, deoarece XPath nu ofer un mecanism pentru definire funcii utilizator. 40 Exclusiv nodurile de tip atribut i de tip spaiu de nume. 41
Deoarece fiecare pas din cale ofer noduri de context pentru pasul urmtor, doar ultimul pas poate returna o secven de valori atomice. 42 Pentru nodurile element, atribut sau document. 85
Un predicat este o expresie inclus n paranteze ptrate i utilizat n filtrarea secvenelor. Predicatul se evalueaz pentru fiecare entitate din secven. De exemplu, expresia urmtoare selecteaz toi descendenii nodului context care sunt elemente cu numele curs i pentru care atributul optional are valoarea no: descendant::curs[attribute::optional = "no"] Pentru simplificarea expresiilor se folosete abrevierea @ pentru attribute i axa child ca ax implicit dac aceasta nu conine un test de atribut, caz n care axa implicit este attribute. Astfel, section/para este echivalent cu child::section/child::para iar para [@type= "unTip"] este echivalent cu child:: para [attribute::type= "unTip"]. De asemenea, deoarece axa conine un test de atribut, section/attribute(id) este echivalent cu child::section/attribute::attribute(id). Un alt exemplu, mai complex, este expresia XPath: //item[@type=nota/curs[text()=Programare OO] care identific toate nodurile care sunt elemente curs i care ndeplinesc condiiile ca printele nodului s fie un element de tip <item>, al crui atribut type are valoarea nota iar coninutul text al nodului s fie Programare OO. Limbajul XPath conine, de asemenea, expresii funcionale. Se poate scrie, de exemplu, o condiie de forma fn:count($nume_var)=0 care impune selectarea cilor pentru care elementul sau atributul cu numele indicat n variabil nu are nici o apariie. n general, filtrarea unei secvene se face utiliznd expresii filtru. Acestea sunt expresii primare urmate de zero sau mai multe predicate. Rezultatul este format din toate entitile returnate de expresia primar care satisfac predicatele. Rezultatul poate conine noduri, valori atomice, sau orice combinaie a acestora. De exemplu, selectarea produselor cu pre mai mare dect 100 dintr-o secven de produse dat n variabila $prod se face cu expresia $prod[pret gt 100], iar selectarea ultimului capitol sau anex din cartea legat la variabila $carte se face cu expresia $carte[(capitol | anexa) [fn:last()]. O expresie filtru poate fi unul din paii unei expresii cale. Astfel, expresia fn:doc(cursuri.xml/fn:id(POO) returneaz nodul element din documentul cursuri.xml al crui ID este POO. Combinarea secvenelor de noduri se face cu operatorii pentru reuniune(|), intersecie (intersect) i diferen (except). Toi aceti operatori elimin nodurile duplicat din rezultat. De asemenea, n expresiile XPath se pot folosi operatorii aritmetici clasici i operatori relaionali. Pentru comparaii generale, aplicate secvenelor de orice lungime, se folosesc operatorii relaionali =, !=, <, <=, >, >=, pentru compararea de valori atomice eq, ne, lt, le, gt, ge, iar pentru compararea de noduri is, <<, >>. Expresiile logice se construiesc folosind operatorii and, or i funcia fn:not care preia ca parametru o secven general pe care o reduce la o valoare de adevr pe care o inverseaz. XPath ofer, de asemenea, o facilitate de iterare prin intermediul expresiilor for. Dac expresia for utilizeaz variabile multiple, atunci ea este expandat la un set de expresii for ncuibate, fiecare de cte o singur variabil. De exemplu, expresia:
86
for $x in X, $y in Y return $x+$y este transformat n: for $x in X return for $y in Y return $x+$y ntr-o expresie for cu o singur variabil, variabila se numete variabil domeniu, valoarea expresiei care urmeaz cuvntului cheie in este numit secvena de legare iar expresia ce urmeaz dup return este expresia rezultat. Rezultatul expresiei for se obine prin evaluarea expresiei rezultat pentru fiecare element din secvena de legare, cu variabila domeniu legat la acel element. Secvenele rezultate sunt concatenate conform ordinii elementelor din secvena de legare din care au derivat. n urmtorul exemplu este ilustrat utilizarea expresiei for n restructurarea unui document. Expresia are ca intrare urmtorul document XML:
<bib> <carte> <titlu>Programare Java</titlu> <autor>Popescu</autor> <editor>Matrix Rom</editor> </carte> <carte> <titlu>Programare avansat n Linux</titlu> <autor>Popescu</autor> <editor>Matrix Rom</editor> </carte> <carte> <titlu>Programare Web</titlu> <autor>Ionescu</autor> <autor>Vasilescu</autor> <autor>Tudor</autor> </carte> </bib>
Expresia for care transform documentul ntr-o list n care numele autorului apare o singur dat, urmat de lista publicaiilor sale, este urmtoarea: for $a in fn:distinct-values(/bib/carte/autor) return ($a, /bib/carte[autor = $a]/titlu) Rezultatul este format din urmtoarea secven de elemente:
<autor>Popescu</autor> <titlu>Programare Java</titlu> <titlu>Programare avansat n Linux</titlu> <autor>Ionescu</autor> <titlu>Programare n Web</titlu> <autor>Vasilescu</autor> <titlu>Programare n Web</titlu> <autor>Tudor</autor> <titlu>Programare n Web</titlu>
Urmtoarea expresie for are variabile multiple:

for $i in (10,20), $ j in (1,2) return ($i +$j)
87
i ntoarce ca rezultat secvena de numere 11, 12, 21, 22. Domeniul unei variabile legate n expresia for cuprinde toate subexpresiile expresiei for care apar dup variabila legat. Astfel, o secven de legare poate fi construit prin referirea unei variabile legate anterior n aceeai expresie for, ca mai jos:
for $x in $z, $y in f($x) return g($x, $y)
XPath suport expresii condiionale bazate pe construciile if, then i else. n exemplul urmtor expresia test verific existena unui atribut numit bursier, independent de valoarea acestuia.
if ($student/@bursier) then $student/bursa else $student/taxa
Expresiile cuantificate suport cuantificare existenial i universal i au valori booleene. O astfel de expresie ncepe cu un cuantificator reprezentat de unul din cuvintele cheie some (cuantificator existenial) sau every (cuantificator universal) urmat de una sau mai multe clauze utilizate pentru legare variabile, urmate de cuvntul cheie satisfies i o expresie test. Fiecare clauz asociaz o variabil cu o expresie care returneaz o secven de entiti. Aceste clauze genereaz tupluri pentru fiecare combinaie de entiti din secvena de legare a variabilei respective. Conceptual, secvena de test este evaluat pentru fiecare tuplu. n cazul utilizrii cuantificatorului some, expresia cuantificat are valoarea true dac cel puin una din evalurile expresiei test este true. Utilizarea cuantificatorului every ntoarce true dac toate evalurile expresiei cuantificate ntorc true. n continuare este exemplificat folosirea fiecrui cuantificator:
every $student in /studenti/student satisfies $student/@bursa some $student in /studenti/student satisfies ($student/bursa > 0.80 * $student/taxa)
Fiecare din urmtoarele expresii cuantificate i evalueaz expresia test pe nou tupluri, format din produsul cartezian al secvenelor (1,2,3) i (2, 3, 4). Rezultatul primei expresii va fi true, iar al celei de a doua, false.
some $x in (1,2,3), $y in (2,3,4) satisfies $x + $y = 4 every $x in (1,2,3), $y in (2,3,4) satisfies $x + $y = 4
Limbajul XPath ofer, de asemenea, operatorii instance of, cast, castable i treat. Operatorul boolean instance of este utilizat pentru testarea tipului la momentul execuiei. Expresia instance of element() ntoarce true dac
88
entitatea context este nod, false dac acesta este definit dar nu este nod i eroare dac entitatea context nu este definit. Operatorul cast este utilizat n conversiile de tip i are doi operanzi: expresia de intrare i tipul int, care trebuie s fie un tip atomic identificat prin QName urmat opional de indicatorul ? dac se permite secvena vid. Dei se poate specifica utiliznd operatorul cast, nu orice conversie este permis. XPath ofer posibilitatea construirii unei expresii care s verifice dac o anumit valoare V poate fi convertit la un tip dat T, expresie care va fi de forma V castable as T. Aceast expresie poate fi folosit ca predicat pentru evitarea erorilor la momentul evalurii i, de asemenea, pentru a selecta tipul corespunztor pentru procesarea unei anumite valori, ca n exemplul urmtor:
if ($x castable as Student) then $x cast as Student else if ($x castable as IQ) then $x cast as IQ else $x cast as xs:string
Pentru fiecare tip atomic din cadrul unui spaiu de nume se definete n mod implicit o funcie constructor cu acelai nume cu cel al tipului int (inclusiv identificatorul spaiului de nume). Semntura funciei constructor pentru un tip T este urmtoarea: T($arg as xdt:anyAtomicType?) as T? n urmtorul exemplu de utilizare a funciei constructor, xs:date(2004-1205) este echivalent cu 2004-12-05 cast as xs:date. Pentru tipurile atomice care nu aparin spaiului de nume este necesar ns utilizarea explicit a operatorului cast pentru a construi instane ale tipului respectiv. n plus, XPath ofer un operator numit treat utilizat pentru modificarea tipului static al operandului pe care acioneaz. El primete, ca i cast, doi operanzi: o expresie i un tip secven. Spre deosebire de cast, nu modific tipul dinamic sau valoarea operandului su ci asigur faptul c o expresie are un tip dinamic ateptat la momentul evalurii. O expresie de forma expr1 treat as tip1 nseamn, c n cursul analizei statice, ea poate fi utilizat ca argument al unei funcii ce ateapt un parametru de tip tip1, iar n cursul evalurii dinamice fie expr1 este de tip tip1, fie se returneaz o eroare dinamic. Detalii suplimentare i informaii actualizate sunt disponibile la http://www.w3.org/TR/xpath20/ XPath este un mecanism de adresare puternic, utilizat n majoritatea standardelor bazate pe XML. Astfel, utiliznd XSLT se poate defini un ablon n avans ce conine expresii XPath prin care se specific un stil pentru document. XQuery este un superset al lui XPath i utilizeaz expresii de acest tip pentru a interoga baze de date XML native i fiiere XML multiple. XPointer utilizeaz XPath pentru a referi noduri specifice n documente XML. XML Signature i XML Encription pot utiliza, de asemena, expresii XPath. n ontologiile din semantic Web se utilizeaz grupuri de expresii XPath pentru a indica modul de regsire a datelor i relaiile dintre
89
acestea. De asemenea, specificaia DOM Level 3 XPath definete interfee pentru accesarea nodurilor unui arbore DOM utiliznd expresii XPath. 4.7.2 Familia foilor de stil: XSL, XSLT i XSLFO Foile de stil specific modul n care un document XML poate fi transformat n noi documente i modul de prezentare a acestuia pe diferite tipuri de media i n formate diferite. Limbajele asociate foilor de stil sunt XSL (Extensible Stylesheet Language), XSLT (Extensible Stylesheet Language: Transformations), i XSLFO (Extensible Stylesheet Language: Formatting Objects). Un procesor pentru foi de stil prelucreaz un document XML i o foaie de stil, pentru a produce ca rezultat prezentarea informaiilor din documentul XML n formatul definit n foaia de stil (fig.4.8). Urmtoarea declaraie <?xml-stylesheet href=carte.css type=text/css?> precizeaz utilizarea aplicaiei XSL pentru prelucrarea fiierului carte.css ce conine date de tip text.css. XSL are dou pri. Prima este motorul pentru foile de stil (XSLT) i ofer un mecanism de transformare a documentelor XML n alte documente XML pe baza unui set de reguli. Cea de a doua ofer un vocabular pentru formatarea obiectelor (XSLFO). Principala consecin a utilizrii acestei familii de limbaje este separarea coninutului de prezentare, ceea ce permite proiectarea aplicaiilor conform paradigmei MVC (Model View Controler). Aceasta ofer maximum de reutilizare a resurselor disponibile i flexibilitate sporit a aplicaiei. Procesoarele pentru foi de stil de care dispun navigatoarele Web permit ataarea dinamic a definiiilor de prezentare la datele XML exact n momentul descrcrii acestora de la server. Mecanismul implementat n procesorul pentru foile de stil preia documentul original, l ncarc ntr-o structur arborescent surs, de tip DOM, i apoi l transform pe baza instruciunilor din foaia de stil. Aceste instruciuni folosesc expresii XPath pentru a referi poriuni din structura arborescent surs i captureaz informaii ce vor fi plasate n arborele rezultat. Acesta este formatat, dup care este returnat documentul XML rezultat, care, de cele mai multe ori, este post-procesat. Post-procesarea transform documentul XML rezultat, pe baza stilului exprimat n XSLFO, ntr-un format diferit (ex. PDF).
Procesor pentru foi de stil Document XML transformare formatare Document rezultat
Foaie de stil
Fig.4.8 Aplicare stil unui document
n exemplul de mai jos este ilustrat utilizarea foilor de stil cu un document XML ce va fi stilizat dinamic. Fiierul XML are urmtorul coninut:
90
<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet href="simplestyle.xsl" type="text/xsl"?> <cursuri name="Facultate.com"> <descriere>Cursurile oferite la facultate</descriere> <plan> <curs> <nume>SO</nume> <descriere>Teoria sistemelor de operare</descriere> </curs> <curs> <nume>POO_1</nume> <descriere>Introducere n programare orientat obiect</descriere> </curs> <curs> <nume>POO_2</nume> <descriere>Tehnici avansate de programare orientat obiect</descriere> </curs> </plan> </cursuri>
Foaia de stil, exemplificat n continuare, va fi utilizat pentru crearea unui document HTML. Se observ utilizarea expresiilor XPath pentru a defini modele de ci de cutare n arborele surs. Valoarea elementului <xsl:value-of> returneaz valoarea entitilor selectate pe baza unei expresii XPath. Procesorul XSLT va aplica modelele de formatare dac nodul curent corespunde expresiei XPath precizat n atribut.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"> <xsl:template match="/"> <html> <TITLE>Plan cursuri pentru <xsl:value-of select="/cursuri/@name"/> - <xsl:value-of select="/cursuri/descriere"/> </TITLE> <CENTER> <TABLE border="1"> <TR> <TD><B>Nume</B></TD> <TD><B>Descriere</B></TD> </TR> <xsl:apply-templates/> </TABLE> </CENTER> </html> </xsl:template> <xsl:template match="cursuri"> <H1>Ofertant: <xsl:value-of select="@name"/> </H1> <HR/> <xsl:apply-templates/> </xsl:template>
91
<xsl:template match="plan"> <H2>Plan cursuri</H2> <xsl:apply-templates/> </xsl:template> <xsl:template match="curs"> <TR> <TD> <xsl:value-of select="nume"/> </TD> <TD> <xsl:value-of select="descriere"/> </TD> </TR> </xsl:template> </xsl:stylesheet>
4.7.3
XQuery
XQuery este un limbaj destinat procesrii datelor XML prin interogarea surselor de date XML dup modelul interogrii bazelor de date. XQuery este un limbaj cu care se construiesc expresii. Sintaxa limbajului este bazat pe XML, ca i XPath, dar are avantajul c este uor interpretabil de utilizatorul uman i permite combinarea logic a rezultatelor interogrilor asupra surselor XML. Procesorul XQuery utilizeaz expresii XPath i funcii proprii lui pentru a interoga i manipula date XML. XQuery este un limbaj funcional deoarece este construit din expresii i nu din instruciuni. Fiecare construcie a limbajului este o expresie ce poate fi construit n mod arbitrar, iar rezultatul unei expresii poate fi utilizat ca intrare pentru alt expresie cu condiia respectrii restriciilor de tip. Variabilele unui limbaj funcional sunt transferate n exclusivitate prin valoare, iar valoarea lor nu poate fi modificat prin efecte colaterale. XQuery este, de asemenea, un limbaj tipat. Tipurile se pot importa din una sau mai multe scheme XML. Limbajul suport, de asemenea, analiza static de tipuri prin care se deduce tipul de ieire al unei expresii pe baza tipurilor intrrilor acesteia. Astfel se permite detectarea erorilor de tip i se ofer o baz pentru unele optimizri. Iat un exemplu de expresie XQuery valid care returneaz cursurile din fiierul din exemplul anterior, sortate alfabetic dup descrierea acestora:
let $cursuri := document("facultate.xml")/cursuri let $curs := $cursuri/plan/curs return $curs sortby (descriere)
Prima linie ncarc documentul XML interogat i asigneaz o variabil elementului cursuri. n cea de a doua linie, colecia elementelor de tip curs este asignat variabilei curs utiliznd o expresie XPath. Ultima linie asigur sortarea pe baza valorilor elementului descriere. Rezultatul acestei expresii XQuery conine elementele selectate n ordine alfabetic:
92
<curs> <nume>POO_1</nume> <descriere>Introducere n programare orientat obiect</descriere> </curs> <curs> <nume>POO_2</nume> <descriere>Tehnici avansate de programare orientat obiect</descriere> </curs> <curs> <nume>SO</nume> <descriere>Teoria sistemelor de operare</descriere> </curs>
XQuery are ca scop oferirea unei interfae standard de interogare a bazelor de date XML. 4.7.4 Modelul de date pentru XQuery, XPath i XSLT XPath opereaz pe structura logic abstract a unui document XML. Aceast structur este reprezentat de modelul datelor. XPath este utilizat pentru a adresa nodurile arborilor XML i este inclus n limbaje gazd ca XSLT sau XQuery. Modelul de date conine specificaiile formale pentru reprezentarea coninutului documentelor XML. Limbajul XPath/XQuery este definit formal ca operaii asupra acestui model al datelor. Modelul de date definete informaia din intrarea unui procesor XSLT sau XQuery. De asemenea, definete toate valorile permise pentru expresiile limbajelor XSLT, XQuery i XPath, acestea fiind nchise43 n raport cu acest model. Pe lng valorile de intrare sau ieire pentru o foaie de stil sau pentru o interogare, modelul de date poate reprezenta i diferite valori de expresii utilizate n calculele intermediare. Acestea pot fi unul sau mai multe documente de intrare44, rezultatul unei expresii ce reprezint o cale (valoare atomic), etc. Modelul de date este un concept general concretizat n entiti specifice care sunt instanele modelului de date, exemple de astfel de instane fiind documentele, elementele, valorile atomice, etc. O instan a modelului de date este o secven. Secvena este o colecie ordonat de zero sau mai multe entiti. Secvenele nu pot fi incluse una n alta, adic o secven nu poate fi membru al altei secvene. O entitate, nod sau valoare atomic, este echivalent cu o secven ce conine un singur element, anume nodul sau valoarea atomic respectiv. Un nod ataat unei secvene i pstreaz identitatea, astfel nct un nod poate s apar n una sau mai multe secvene iar o secven poate conine elemente duplicat. O entitate poate fi un nod sau o valoare atomic. Fiecare entitate are o valoare i un tip.
Se spune c un limbaj este nchis (closed) n raport cu un model de date dac valoarea fiecrei expresii din acel limbaj aparine modelului de date. 44 Ssecven de noduri de tip Document. 93
43
Nodurile formeaz un arbore i fiecare nod este accesibil pe baza accesorilor dm:children, dm:attributes, i dm45:namespaces. Fiecare nod aparine exact unui arbore i fiecare arbore are exact o rdcin. Un arbore care are ca rdcin un nod de tip Document. Node este un document, iar dac rdcina este de alt tip atunci acesta reprezint un fragment. Fiecare nod are o identitate unic ntr-o instan a modelului de date. O valoare atomic este o valoare din spaiul de valori al unui tip atomic i este etichetat cu numele tipului respectiv. Spre deosebire de nod, ea nu are identitate unic. Un tip atomic poate fi un tip simplu primitiv sau un tip derivat prin restricie46 dintr-un alt tip atomic. Un tip este reprezentat n modelul de date prin QName expandat. Acesta este o pereche de valori format dintr-un URI al unui spaiu de nume (posibil vid) i un nume local. Ele aparin spaiului de valori xs:QName al tipului XML Schema. Modelul de date expune proprietile entitilor pe care le conine prin intermediul unei familii de funcii accesor. Acestea nu sunt accesibile ca atare din aplicaii ci au rolul de a descrie informaiile pe care o implementare a modelului de date trebuie s le expun aplicaiilor. Principalele funcii accesor expun URI-ul unui nod (base-uri), tipul nodului (node-kind), numele nodului (node-name ca valoare xs:QName), nodul printe (parent), valoarea reprezentrii ir a nodului (string-value), valoarea nodului corespunztoare tipului su47 (typedvalue), tipul nodului (type-name), descendenii acestuia (children), nodurile sale atribut (attributes), spaiile de nume ataate nodului (namespace-nodes sau namespace-bindings), ca i valori de adevr pentru afirmaiile c nodul este de tip nil (nilled), nod de tip identificator (is-id) sau de tip referin la identificator (is-idrefs). Modelul de date definete apte tipuri de noduri. Nodul de tip document ncapsuleaz documente XML i este caracterizat de proprietile: base-uri, children, unparsed-entities, document-uri, string-value i typed-value. Nodurile de tip element ncapsuleaz elemente XML i au proprietile: base-uri, node-name, parent, type-name, children, attributes, namespaces, nilled, string-value, typed-value, is-id, isidrefs. Nodurile atribut reprezint atributele XML i au proprietile: node-name, , parent, type-name, string-value, typed-value, is-id, is-idrefs. Nodurile de tip spaiu de nume ncapsuleaz spaiile de nume XML i au proprietile: prefix, uri, parent. Nodurile de tip instruciune de procesare ncapsuleaz instruciunile XML de procesare i au urmtoarele proprieti: target, content, base-uri, i parent.
Prefix pentru funcii abstracte, care nu sunt accesibile direct din limbaj ci au rolul de a explica interfaa dintre modelul datelor i specificaiile ce se bazeaz pe acest model. 46 Tipurile derivate prin extensie (list sau union) nu sunt atomice. 47 Ca secven de valori atomice. 94
45
Nodurile de tip comentariu ncapsuleaz comentariile XML, avnd proprietile content i parent. Nodurile de tip text ncapsuleaz coninut XML de tip caracter i au proprietile content i parent. Restriciile pentru fiecare tip de nod ca i detalii necesare procesoarelor pentru aceste limbaje sunt specificate la http://www.w3.org/TR/xpathdatamodel/. 4.7.5 XLink XLink este un mecanism generic de legare folosit de limbaje XML. El este un limbaj destinat inserrii n documentele XML de elemente prin care se creaz i se descriu legturi ntre resurse, se asociaz metadate sau se leag documente externe. Limbajul reprezint o extensie a hiperlegturilor HTML cu caracteristici de comportament avansate, care s le ofere flexibilitate sporit. XLink permite legarea de multiple inte, roluri, resurse i rspunsuri la elemente. Un link se definete ca fiind o relaie explicit ntre resurse i poriuni de resurse. Limbajul permite legarea de documente externe, legarea de de resurse ntre ele i legarea relaiilor ntre resurse. n urmtorul exemplu este ilustrat utilizarea XLink pentru a defini o legtur simpl, similar cu elementul <A> din HTML. Atributul type al legturii are valoarea simple iar atributul href indic un document extern i elemente din documentul curent.
<?xml version="1.0" encoding="UTF-8"?> <doc> <nume xlink:type='simple' xlink:href='profesori/info.xml'>Popescu Ana</nume> este angajat la <facultate xlink:type='simple' xlink:href='#MateInfo'> Matematica si Informatica. </facultate>, si preda <curs xlink:type='simple' xlink:href='#CS333'> Sisteme de Operare 333 </curs> <angajati> <facultate id='MateInfo'>Matematica si Informatica</facultate> <facultate id='Econ'>Stiinte Economice</facultate> <facultate id='Bio'>Biologie si Ecologie</facultate> </angajati> <listacursuri> <curs id='CS111'>CS 111 Introducere in IT</curs> <curs id='CS333'>CS 333 Sisteme Operare</curs> <curs id='CS555'>CS 555 Programare OO</curs> <curs id='CS777'>CS 777 Sisteme distribuite</curs> </listacursuri> </doc>
Cu XLink se pot defini i legturi mult mai complexe, pn la nivel de legturi de relaii ntre documente.
95
XLink permite conectarea de relaii prin utilizarea tipului extended de legtur. Acest tip permite definirea de arce care descriu relaiile dintre elemente i resurse aflate la distan. Exemplul urmtor conine o variant modificat a celui precedent, cu scopul de a incorpora relaii ntre unele elemente.
<?xml version="1.0" encoding="UTF-8"?> <doc> <extendedlink xlink:type='extended'> <loc xlink:type='locator' xlink:label='MateInfo' xlink:href='#MateInfo'> </loc> <loc xlink:type='locator' xlink:label='curs333' xlink:href='#CS333'> </loc> <loc xlink:type='locator' xlink:label='descriere_curs593' xlink:href='cururi/CS333.xml'> </loc> <loc xlink:type='locator' xlink:label='descriere_MateInfo' xlink:href='angajati/MateInfo.xml'> </loc> <arc xlink:type='arc' xlink:from='curs333' xlink:to= 'descriere_curs593'> </arc> <arc xlink:type='arc' xlink:from='MateInfo' xlink:to= 'descriere_MateInfo'> </arc> </extendedlink> <nume xlink:type='simple' xlink:href='profesori/info.xml'>Popescu Ana</nume> este angajat la <facultate xlink:type='simple' xlink:href='#MateInfo'> Matematica si Informatica. </facultate>, si preda <curs xlink:type='simple' xlink:href='#CS333'> Sisteme de Operare 333 </curs> <angajati> <facultate id='MateInfo'>Matematica si Informatica</facultate> <facultate id='Econ'>Stiinte Economice</facultate> <facultate id='Bio'>Biologie si Ecologie</facultate> </angajati> <listacursuri> <curs id='CS111'>CS 111 Introducere in IT</curs> <curs id='CS333'>CS 333 Sisteme Operare</curs> <curs id='CS555'>CS 555 Programare OO</curs> <curs id='CS777'>CS 777 Sisteme distribuite</curs> </listacursuri> </doc>
96
Adugarea elementului <extendedlink> cu valoarea atributului type egal cu extended permite crearea de relaii ntre elemente. Atributele unui element de tip arc ne-au permis s conectm un curs cu descrierea sa, cu un angajat i o descriere. XLink este utilizat n limbaje ca SVG (Scalable Vector Graphics) i MathML. De asemenea, RDDL (Resource Directory Description Language) utilizeaz sintaxa XLink pentru a specifica relaii ntre URL-uri i alte resurse. Specificaiile RDF i XTM ofer, de asemenea, conceptul maprii asociaiilor ntre resurse. 4.7.6 XPointer Specificaiile cadrului48 XPointer se refer la un sistem extensibil pentru adresare n tehnolgii bazate XML. Acest cadru reprezint baza de construire a identificatorilor la nivel de fragment pentru orice resurs Web la care tipul de media este: text/xml, text/xml-external-parsed-entity, application/xml, sau application/xml-external-parsed-entity. XPointer (XML Pointer Language) este un limbaj pentru adresare, utiliznd identificatori de tip URI, n structura intern a resurselor XML. XPointer este un limbaj puternic ce ofer referine la fragmente ale documentelor aflate pe alte maini, utiliznd expresii XPath, i referine la domenii de date i la date n document. Un pointer este de forma unui ir de caractere, care se conformeaz specificaiilor W3C pentru XPointer49. Acest ir este prelucrat, de ctre procesoare specializate, n vederea extragerii informaiilor de identificare a unui set de subresurse al unui document XML i aplicrii acestor identificatori documentului pentru a obine subresursele respective. Aplicaiile incorporeaz i utilizeaz un procesor XPointer cu un comportament specific formatului datelor cu care lucreaz (bazate sau nu XML). Un procesor XPointer preia pe intrare o resurs XML50 i un ir de caractere ce va fi utilizat ca pointer i ncearc evaluarea acestuia n raport cu resursa. Funcie de modul n care s-a realizat acest operaie, la ieire va raporta identificarea unei subresurse sau una sau mai multe erori. Din punct de vedere sintactic, un XPointer poate fi de tip simplu51 sau bazat pe schem52. n ir se pot separa pri ale acestuia ncadrate de paranteze. irul este format din caractere Unicode din care unele, cum ar fi parantezele, sunt rezervate. Acestea pot fi utilizate cu alte sensuri dac se folosete secvena de escape ^. Pointerii de tip simplu sunt utilizai pentru identificarea unui singur element din setul de informaii al resursei. Funcie de structura elementului, pointerul va utiliza ca identificator valoarea atributului ID, coninutul descendentului ID, sau o valoare de tip ID determinat extern.
48 49
Framework. http://www.w3.org/TR/xptr-framework/ 50 Poate fi un document sau o entitate extern parsat. 51 Shorthand. 52 SchemaBased. 97
Un pointer bazat pe schem const din una sau mai multe pri.53 Fiecare parte are o schem de nume i conine, ntre paranteze, date conforme cu aceasta. Fiecare din aceste pri reprezint un identificator alternativ. Astfel, procesorul XPointer realizez evaluarea de la stnga la dreapta i raporteaz ca ieire rezultatul obinut de la prima dintre pri care se evalueaz corect i care identific una sau mai multe subresurse. Exemplul urmtor conine dou pri. Partea element se evaluaz doar dac partea xpointer nu identific nici o subresurs. #xpointer(//curs [@id= 'CS333'])element(curs/3) n cadrul unui pointer se pot specifica legturi la spaii de nume. Spaiile de nume legate astfel formeaz contextul spaiilor de nume pentru toate prile din dreapta celei n care s-a fcut o astfel de specificare. Contextul iniial al spaiilor de nume este format din spaiul identificat prin prefixul xml, care este legat la http://www.w3.org/XML/1998/namespace. n exemplul de mai jos se utilizeaz schema xmlns pentru a aduga un spaiu de nume la context. nainte de evaluare, procesorul XPointer va utiliza acest informaie pentru a verifica apartenena numelui img:rect la spaiile de nume din contextul curent. #xmlns(img=http://example.org/image)img:rect(10,10,50,50) n continuare este prezentat modul n care se rescriu informaiile coninute n elementul extendedlink, dintr-un exemplu anterior, folosind expresii XPointer. Aceste expresii sunt folosite n atributele xlink:href ale elementului loc pentru a indica direct la elemente. Legturile adreseaz elementul facultate cu ID-ul MateInfo i elementul curs cu atributul ID de valoare CS333.
<extendedlink xlink:type= 'extended'> <loc xlink:type= 'locator' xlink:label= 'MateInfo' xlink:href= '#xpointer (//facultate [@id= 'MateInfo']) '></loc> <loc xlink:type= 'locator' xlink:label= 'curs333' xlink:href= '#xpointer (//curs [@id= 'CS333']) '></loc> <loc xlink:type= 'locator' xlink:label= 'descriere_curs333' xlink:href= 'cursuri/cs333.xml '></loc> <loc xlink:type= 'locator' xlink:label= 'descriere_MateInfo' xlink:href= 'angajati/MateInfo.xml '></loc> <arc xlink:type= 'arc' xlink:from= 'curs593' xlink:to= 'descriere_curs333'></arc> <arc xlink:type= 'arc' xlink:from= 'MateInfo' xlink:to='descriere_MateInfo'></arc> </extendedlink>
XPointer utilizeaz expresii XPath pentru a referi resurse i are funcii suplimentare pentru a specifica domenii de elemente i puncte n cadrul unui
53
Separate opional prin spaii. 98
document. Urmtoarea expresie XPointer refer obiecte de tip ir cu valoarea CS dintr-un document XML. xpointer (string-range (//*, 'CS')) Specificaiile referitoare la XPointer sunt compuse din cadrul nucleu XPointer, din schema element() pentru adresarea elementelor XML, din schema xmlns() pentru interpretarea corect a prefixelor spaiilor de nume n pointeri i din schema xpointer() pentru flexibilitate total n adresare. XLink i Xinclude pot utiliza expresii XPointer. 4.7.7 XInclude Aceast specificaie definete posibilitatea de a include documente, elemente i alte informaii ntr-un document XML. Se pot construi astfel documente XML din compunerea mai multor documente i fragmente de documente XML. n exemplul urmtor un capitol, Gestiunea memoriei cap. 3, este compus pe baza coninutului mai multor fiiere incluse ntr-un document principal.
<?xml version="1.0"?> <capitol xmlns:xi="http://www.w3.org/2001/XInclude"> <title>Gestiunea memoriei</title> <xi:include href="http://www.unSite/cursSO/cap3/xpath.xml"/> <xi:include href="http://www.unSite/cursSO/cap3/stylesheets.xml"/> <xi:include href="http://www.unSite/cursSO/cap3/xquery.xml"/> <xi:include href="http://www.unSite/cursSO/cap3/xlink.xml"/> </capitol>
Exemplul urmtor este mai complex i ilustreaz modul n care se poate beneficia de faciliti mai puternice oferite de Xinclude, care permit includere de coninut non-XML ca i de poriuni din alte documente. De asemenea, dac nu este disponibil una din componentele incluse astfel, se utilizeaz definiiile elementului fallback, special prevzut pentru astfel de cazuri.
<?xml version= '1.0'?> <document xmlns:xi="http://www.w3.org/2001/XInclude"> <P>Coninut ilustrativ:</P> <quotation> <-- utilizarea unei expresii Xpointer pentru a include o poriune din alt document. <xi:include href="sursa.xml#xpointer (string-range (capitol/p [1], 'Paragraf 2')/ range-to (string-range (capitol/p[2]/i, '3. ',1,2)))" > <xi:fallback> <xi:include href="eroare.xml"/> </xi:fallback> </xi:include> </quotation>
99
<P>Cod Java pentru testare:</P> <code> <-- includerea unui cod text dintr-un fiier surs Java, care este document non-XML <xi:include parse="text" href="code/Test.java"> <xi:fallback> Cod indisponibil in acest moment ! </xi:fallback> </xi:include> </code> </document>
4.7.8
XML Base
XML Base permite autorilor s specifice n mod explicit URI-ul baz al unui document54 pentru a fi folosit la rezolvarea URI-urilor relative. Acestea pot referi imagini externe, applet-uri, programe pentru procesarea formelor, foi de stil i alte resurse. Pentru acesta se folosete atributul xml:base care este inserat n documente XML pentru a indica un URI de baz, diferit de cel documentului sau al entitii externe. Dac utilizm XML Base, exemplul folosit pentru XInclude se simplific astfel:
<?xml version="1.0"?> <chapter xmlns:xi="http://www.w3.org/2001/XInclude" xml:base="http://www.unSite/cursSO/cap3"> <title>Gestiunea memoriei</title> <xi:include href="xpath.xml"/> <xi:include href="stylesheets.xml"/> <xi:include href="xquery.xml"/> <xi:include href="xlink.xml"/> </chapter>
Exemplul urmtor ilustreaz utilizarea XML Base n asociere cu XLink pentru a oferi baza referinelor URI relative din atributele xlink:href, ct i posibilitatea de a modifica baza pe parcursul aceluiai document XML.
<?xml version="1.0"?> <doc xml:base="http://www.unSite/cursuri/" xmlns:xlink="http://www.w3.org/1999/xlink"> <head> <title>Documentatii</title> </head> <body> <paragraph>Vezi <link xlink:type="simple" xlink:href="FundamenteSO.xml">Concepte fundamentale ale sistemelor de operare</link></paragraph> <paragraph>Aplicatii</paragraph> <olist xml:base="/Aplicatii/">
54
Similar cu elementul <base> din HTML 100
<item> <link xlink:type="simple" xlink:href="LaboratorSO.xml">Aplicatii pentru laborator SO </link> </item> <item> <link xlink:type="simple" xlink:href="ExercitiiSO.xml">Teme de rezolvat SO </link> </item> <item> <link xlink:type="simple" xlink:href="Test.xml">Teste grila de control </link> </item> </olist> </body> </doc>
Referinele xlink:href de mai sus se rezolv astfel:

Concepte fundamentale ale sistemelor de operare Aplicatii pentru laborator SO Teme de rezolvat SO
http://www.unSite/curs/FundamenteSO.xml http://www.unSite/Aplicatii/LaboratorSO .xml http://www.unSite/Aplicatii/ExercitiiSO .xml 4.7.9 XHTML
XHTML este o reformulare n XML a limbajului HTML. Motivaia este dat de slaba structurare a HTML care nu permite interpretarea documentelor de ctre main. XHTML este structurat i extensibil i permite includerea altor limbaje bazate XML, prin spaiile lor de nume. XHTML simplific schimbul de informaii ntre mainile din Web ca i interpretarea documentelor de ctre agenii utilizator. Argumentul pentru extensibilitatea XHTML este faptul c acesta suport introducerea de noi elemente, adugate schemei, prin utilizarea modulelor XHTML abstracte. Prin modularizare sunt specificate seturi bine definite de elemente XHTML care pot fi combinate i extinse. XHTML, XForms i XEvents sunt tratate n detaliu ntr-un capitol special. 4.7.10 SVG Scalable Vactor Graphics (SVG) este un limbaj pentru descrierea n XML a reprezentrilor grafice 2D. Acesta este folosit pentru gruparea, aplicarea de stiluri i transformarea vectorilor grafici, a imaginilor i a textului. Cu ajutorului lui se pot defini i declana efecte de filtrare, transformri incluse i animaie. Pentru a realiza de animaie avansat i grafice dinamice, autorii utilizeaz limbaje de scripting cu care acceseaz DOM pentru SVG.
101
Exemplul urmtor55 este un fiier simplu cu definiii n SVG. Acesta conine definiia unei element grafic de tip elips i punerea lui n coresponden cu o hiperlegtur la http://www.w3.org. Pentru acesta SVG utilizeaz mecanismul oferit de XLink.
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"> <svg width="5cm" height="3cm" viewBox="0 0 5 3" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <desc>Example link01 - a link on an ellipse</desc> <rect x=".01" y=".01" width="4.98" height="2.98" fill="none" stroke="blue" stroke-width=".03"/> <a xlink:href="http://www.w3.org"> <ellipse cx="2.5" cy="1.5" rx="2" ry="1" fill="red" /> </a> </svg>
SVG este adoptat de actori importani n dezvoltarea de aplicaii Web. Deoarece este XML nativ, el poate fi folosit de serviciile Web pentru a genera coninut grafic bogat. Astfel, SVG poate fi consderat o tehnologie important, parte a unui Web orientat pe servicii.
55
Extras din recomandarea SVG de la W3C. 102
5. ARHITECTURI PENTRU EXTINDERE FUNCIONALITATE LA SERVER

Acest capitol surprinde caracteristicile fundamentale ale extinderii funcionalitii clasice a serverelor Web. Este prezentat arhitectura general pentru extinderea funcionalitii la server i detaliate elementele acesteia. Sunt descrise i exemplificate sugestiv interfaa standard CGI i tehnologiile de scripting la server ASP i PHP. Aceste tehnologii sunt orientate obiect, se conecteaz prin obiecte specializate la interfaa cu serverul Web i ofer performane mai bune prin gestionarea aplicaiilor i sesiunilor clienilor. De asemenea, este tratat accesul modulelor cu cod de scripting la date persistente aflate n fiiere sau n baze de date. Sunt prezentate operaiile de acces la fiiere i etapele accesului la bazele de date precum i modaliti concrete de realizare a acestora n limbajele de scripting exemplificate. De asemenea, sunt descrise caracteristicile fundamentale ale tehnologiilor Java Servlet i JSP utilizate n extinderea funcionalitii serverelor Web, iar n final sunt prezentate cteva arhitecturi utile n proiectarea aplicaiilor ce utilizeaz JSP.
5.1 CONTAINER-ul WEB

Extinderea funcionalitii la server se face prin includerea de cod definit de programator i care se va executa asupra resurselor aflate la server, pentru a genera pagini Web ce vor fi transmise la client. Aceste pagini au coninut dinamic, creat n momentul solicitrii, de ctre o aplicaie ce se execut la server. Pentru aceasta, pe lng intefeele cu clientul i cu sistemul de fiiere, serverul Web conine i o interfa la care se conecteaz aplicaii.
WebServer Browser client cerere rspuns Interfa client Interfa aplicaii Motor servlet
CONTAINER WEB
Interfa cu sistemul de fiiere
CGI parser
Motor SSJS
aplicaie
JSP Servlet
Script Java
Interfee de acces la baze de date (JDBC, ODBC)
Fiiere *.html, *.css, *.js, *.class
Fig.6.1 Arhitectur pentru extindere a funcionalitii la SERVER
103
Serverul Web dotat cu acest sistem de interfee reprezint un container, containerul Web, n care se conecteaz toate componentele ce formeaz site-ul Web. Putem considera c avem de a face cu un container Web particular i n cazul arhitecturilor fr extinderea funcionalitii la server, caz n care componenta conectat este reprezentat doar de sistemul de fiiere. n figura 6.1 este reprezentat o arhitectur Web pentru extinderea funcionalitii la server, orientat pe tehnologii Java. n general, interfaa cu aplicaiile conine instrumentele de lansare, de execuie a aplicaiilor i de comunicare de informaii cu acestea. Lansarea aplicaiilor se face sub controlul interpretorului corespunztor tipului lor. Astfel, o aplicaie n C este deja compilat i va fi executat de sistemul de operare al mainii gazd. O aplicaie n limbaj de scripting va fi executat de interpretorul corespunztor limbajului. Limbajul poate fi shell-ul sistemului de operare sau un limbaj specializat pentru programare n Web (Perl, PHP, SSJS, JSP, ASP, etc). Comunicarea de informaii se face, conform unor specificaii standard de interfa (CGI) prin parametri, extrai din irul de interogare coninut n cererea clientului. CGI-parser este un exemplu de component care realizeaz extragerea acestor parametri. Limbajele specializate pentru programare n Web conin obiecte predefinite care modeleaz cererea clientului i rspunsul serverului, informaiile fiind n acest caz obinute din proprietile corespunztoare ale obiectelor respective.
5.2 CGI (Common Gateway Interface)

CGI este o interfa cu server-ul Web implementat de programe scrise n limbaj C, de componente ActiveX (coninute n fiiere .dll i .exe), de script-uri (shell SO, Pearl), n vederea comunicrii de informaii cu serverul Web. Specificaia CGI se refer la componentele cererii i rspunsului. Referitor la cerere, interfaa CGI definete o form de identificare a elementelor din cererea clientului. Despre rspuns se precizeaz c este scris la ieirea standard i este formatat conform protocolului HTTP Elementele din cererea clientului sunt reprezentate de valorile pe care le iau controalele formularelor. Conform specificaiilor CGI, un control cu numele tip al formei de dialog cu utilizatorul este identificat cu $FORM_tip i se obine n urma prelucrrii irului QUERY_STRING cu utilitarul cgiparse. La server se creaz un proces ce rspunde acestei cereri, prin lansarea aplicaiei definit ca valoare a atributului ACTION al formei de culegere a informaiilor de la utilizator. Utiliznd CGI se creaz cte un proces pentru fiecare cerere. Aceasta conduce la performane sczute n raport cu alte tehnologii de programare la server. Contextul de la server conine un set de variabile disponibile aplicaiilor Web. Setul acestor variabile este urmtorul:
{SERVER_SOFTWARE, SERVER_NAME, GATEWAY_INTERFACE, SERVER_PROTOCOL, SERVER_PORT, PATH_INFO, PATH_TRANSLATED, AUTH_TYPE, CONTENT_TYPE, CONTENT_LENGTH, HTTP_ACCEPT, HTTP_USER_AGENT, HTTP_COOKIES, REQUEST_METHOD, SCRIPT_NAME, QUERY_STRING, REMOTE_HOST, REMOTE_USER, REMOTE_IDENT}
104
Utiliznd aceste variabile aplicaiile pot afla, de exemplu numele i versiunea serverului Web(SERVER_SOFTWARE), versiunea specificaiei CGI folosit (SERVER_PROTOCOL), cile virtuale pentru scripturile CGI (PATH_INFO), corespondena cale virtual:cale real (PATH_TRANSLATED). De asemenea, programele C conectate la CGI utilizeaz funcia getenv() din biblioteca stdlib pentru a prelua i prelucra variabila QUERY_STRING, n cazul specificrii n cerere a metodei GET. Scriptul CGI genereaz raspunsul n format HTML, pe care l trimite la serverul Web utiliznd fiierul stdout. n cazul specificrii metodei POST, datele transferate scriptului sunt preluate din fiierul stdout, iar lungimea irului n octei din variabila CONTENT_LENGTH. n urmtorul exemplu este prezentat un script, n limbaj Perl, pentru generarea unei pagini Web n care sunt afiate variabilele de context. Variabila ENV este reprezentat sub forma unui tablou asociativ de corespondene ntre numele i valorile variabilelor de context.
#!usr/bin/perl print Content type: text/plain\n\n; print Content : text/plain\n\n; foreach $key (keys %ENV) { printf %16s = %s \n, $key, %ENV{%key};
Un alt exemplu prezint un formular HTML pentru nregistrarea participanilor la o conferin i un script n shell Linux pentru stocarea ntr-un fiier a valorilor preluate n form.
<form action=httpd://alien/cgi-bin/register.cgi method=GET> Va rugam sa va inregistrati! Numele si prenumele: <input type=text name=name> Universitatea: <input type=text name=univ> Departamentul: <input type=text name=depart> Titlul lucrarii: <input type=text name=paper> <p> <input type=submit value=inregistrare> Formularul HTML </form>
Scriptul n shell Linux #!bin//bash echo Content type: text/html; echo echo <html> echo <body><h1>Multumiri</h1> eval /home/httpd/cgi-bin/cgiparse form echo Bine ai venit, $FORM_name ! echo <p> printf %s, %s, $s, $s,\n $FORM_name\ $FORM_univ $FORM_depart \ $FORM_paper >> /home/httpd/conference/participants echo </body></html>
105
Server side includes (SSI) este o tehnologie simpl pentru extinderea funcionalitii serverului Web. Aceasta permite includerea direct n HTML a unor comenzi ctre maina pe care se afl serverul Web. Sintaxa pentru lansarea unei comenzi suportate de specificaia SSI este urmtoarea:  Pentru interpretorul HTML aceast linie reprezint un comentariu, n timp ce pentru server reprezint o comand de executat. Rezultatul execuiei va nlocui comentariul n pagina HTML. Un astfel de fiier HTML trebuie s aib extensia .shtml.
5.3 Tehnologii de scripting la server

5.3.1 Tehnologia ASP (Active Server Pages) ISAPI este acronimul pentru Internet Server Application Programming Interface i reprezint o interfa de programare a aplicaiilor Web pentru serverul IIS Microsoft. Ea este accesibil prin instruciuni VBScript sau JScript. Interpretorul este orientat pe limbajele VBScript i Jscript, dar poate suporta i REXX sau Perl. Interfaa include funcii de conectivitate la baze de date i de execuie de componente ActiveX.
Container WEB Interpretor VBS browser Web server Interpretor JS
Obiecte ActiveX (.dll, .exe) SGBD *.asp
Fig.6.2 Platforma Microsoft pentru extindere funcionalitate la serverul Web IIS
O caracteristic important este posibilitatea de lucru n regim tranzacional la nivel de pagin Web. O pagin ASP este definit ntr-un fiier *.asp. Ea conine mai multe tipuri de cod: cod (D)HTML i cod scripting executat la server (JScript sau VBScript). Prin intermediul obiectelor create la server, se transmite cod specific ctre alte componente de tip ActiveX sau ctre sisteme de gestiune a bazelor de date. Aceste obiecte create la server sunt instane ale componentelor ActiveX utilizate sau obiecte ce modeleaz diferite servicii cum ar fi cele de acces la baze de date (ADODB). Coninutul unei pagini ASP este interpretat de motorul aflat n fiierul Asp.dll (pe calea %WINDIR%\System32\inetsv). Cnd primete o cerere ce conine un URL al unui fisier *.asp, containerul Web lanseaza interpretorul Asp.dll care execut codul din pagina solicitat. Aceast operaie genereaz dinamic una sau mai multe pagini HTML. S ne
106
amintim c o cerere ce conine un URL al unui fiier *.html este servit prin transmiterea continuului, static, definit n fiierul *.html. Limbajele VBScript i JScript sunt subseturi ale limbajelor VisualBasic i Java, cu sintax mai puin restrictiv i cu obiecte predefinite pentru arhitectura clientserver corespunztoare tehnologiei Web Limbajul folosit este precizat la nceputul fiierului cu directiva <%@ LANGUAGE=lang %>, unde lang poate lua una din valorile VBScript sau JScript. Codul de scripting din fiierul ASP este delimitat de marcatorii <%...%> . Acest cod nu este vizibil la utilizator deoarece, spre deosebire de codul de scripting marcat cu <SCRIPT> sau de codul corespunztor unui applet, nu ajunge la browser ci este executat direct pe server. La agentul utilizator ajunge doar rezultatul execuiei acestuia, sub forma de pagini (D)HTML. Exemplificm n continuare cteva variante sintactice de cod ASP. 1. <% = expresie %> Cod pentru definirea unei expresii al crei rezultat este inclus direct n pagin. 2. <%call f( )%> Cod pentru apelul unei funcii. 3. <% set C1 = Sever.CreateObject(nume_Serv.nume_obiect) Cod pentru crearea unui obiect de tip nume_obiect furnizat de un serviciu identificat prin nume_Serv. 4. <OBJECT RUNAT = Server Id = C2 PROGID = nume_Serv.nume_obiect> Cod pentru instanierea unui obiect de tip nume_obiect furnizat de un serviciu identificat prin nume_Serv. 5. <OBJECT RUNAT = Server Id = C2 CLASSID=clsid:nr-unic-obiect> Cod pentru instanierea unui obiect de tip identificat cu identificatorul numeric al clasei. De asemenea, se poate importa cod aflat n fiier extern, prin utilizarea clauzei #include astfel:  Aciuni standard Toate containerele JSP (indiferent de implementare) realizeaz o serie de aciuni standard care afecteaz comportamentul paginii la momentul execuiei i rspunsul returnat clientului. O aciune standard este descris cu un tag special. La momentul compilrii paginii n servlet, containerul nlocuiete tag-ul cu codul Java predefinit pentru acesta. Tipurile de acini standard 1. <jsp:useBean>
138
Separarea ntre cod i prezentare se face, n general, nglobnd codul ntr-un obiect Java de tip JavaBean. Aciune specificat prin <jsp:useBean> instaniaz sau localizeaz o instan JavaBean. Aceast instan se identific cu un Id, identificare valabil n cadrul unui domeniu (scope) specificat. Obiectul este ulterior referit din JSP-ul curent sau din alt JSP, funcie de domeniu, utiliznd Id-ul asociat. Sintaxa general este dat de: <jsp:useBean id=nume scope=numeDomeniu detalii_bean /> unde scope poate fi: page, request, session, application, iar detalii_bean este una din urmtoarele combinaii: class=nume_clasa class=nume_clasa type=nume_tip beanName=nume_bean type=nume_tip type=nume_tip
2. <jsp:setProperty>
Aceast aciune este utilizat n conjuncie cu aciunea jsp:useBean pentru a seta valoarea proprietilor bean-ului. Proprietile pot fi simple sau indexate. Ele pot fi setate n una din urmtoarele trei variante: la apariia cererii i utiliznd parametrii din obiectul request, la apariia cererii setarea fcndu-se ca urmare a evalurii unei expresii, sau setare de proprieti pe baza unui String specificat. Sintaxa general este: <jsp:setProperty name=nume_bean detalii_prop /> unde detalii_prop este una din urmtoarele: property=* property=nume_prop property=nume_prop param=nume_param property=nume_prop value=valoare_prop
3. <jsp:getProperty>
Aceast aciune este complementar cu precedenta. Prin ea se acceseaz valoarea unei proprieti, are loc convertirea acesteia n ir de caractere i tiprirea irului n fluxul de ieire ctre client. <jsp:getProperty name=nume property=nume_prop />
4. <jsp:param>
139
Utilizarea acestei aciunii permite crearea unui set de perechi nume :valoare pentru a fi folosite de alte tag-uri. <jsp:param name=nume_param value=valoare_param />
5. <jsp:include>
Aceast aciune realizeaz includerea, la momentul execuiei, a unei resurse dinamice specificat prin URL: <jsp:include page=URL flush=true /> sau cu parametri: <jsp:include page=URL flush=true> <jsp:param name=nume_p value=valoare_p /> ... </jsp:include> Aciunea include poate fi static sau dinamic. Ea este realizat la momentul execuiei, nu este analizat lexical ci este inclus in_line i este destinat utilizrii pentru resurse ce se modific frecvent. Spre deosebire de aceasta, directiva include este static, realizat la compilare, analizat lexical de ctre container i utilizat pentru resurse ce nu se modific frecvent.
6. <jsp:forward>
Aciunea specific dirijarea cererii ctre o alt pagin JSP i permite transferul de parametri, dac e necesar. Sintaxa general este urmtoarea: <jsp:forward page=URL />
7. <jsp:plugin>
Este o aciune utilizat pentru a genera tag-uri HTML <OBJECT> sau <EMBED>, specifice fiecrui tip de navigator. Prezena acestor tag-uri determin executarea obiectului (applet-ului sau a JavaBean) specificat n tag, execuie precedat, dac e necesar, de descrcarea unui software ce va fi conectat la agentul utilizator (Java plug-in).
<jsp:plugin type=bean|applet code=objectCode codebase=objectCodebase align=alignment archive=archiveList height=height hspace=hspace jreversion=jreversion name=componentName vspace=vspace width=width nspluginurl=url iepluginurl=url> <jsp:params> <jsp: param name=nume value=val /> ... </jsp:params> <jsp:fallback> Text de afisat </jsp:fallback> </jsp:plugin>
140
Obiecte implicite Ca i celelalte tehnologii de programare la server studiate, tehnologia JSP ofer un set de obiecte implicite specifice programrii Web. Aceste obiecte sunt derivate din servlet API. Obiectul Request conine cererea i are ca domeniu de vizibilitate (scope) cererea. Obiectul Response conine rspunsul la cerere i are ca domeniu de vizibilitate pagina. Obiectul predefinit PageContext ofer acces la atributele partajate ale paginii i are ca domeniu de vizibilitate pagina. Obiectul Session reprezint sesiunea creat automat n urma unei cereri client. El are ca domeniu de vizibilitate o sesiune client. Obiectul Aplication reprezint contextul servlet-ului. El este obinut de la obiectul de configurare a servletului i are ca domeniu de vizibilitate aplicaia. Obiectul Out este obiectul care scrie n fluxul de ieire ctre client. Obiectul predefinit Config reprezint ServletConfig pentru pagina JSP i are ca domeniu de vizibilitate pagina. Page este obiectul care reprezin instana servletului care implementeaz pagina i care proceseaz cererea curent. Acesta are pagina ca domeniu de vizibilitate i este echivalent cu this. Proiectarea aplicaiilor care utilizeaz JSP Aplicaiile utilizeaz JSP n scopul realizrii separrii ntre logica aplicaiei i prezentare datelor pentru client. Exist dou abordri principale n proiectarea aplicaiilor care utilizeaz JSP.
Abordarea client-server, orientat pagin
Paginile JSP sau servleturile acceseaz resursele (ex. baz de date) n mod direct sau prin intermediul unei componente JavaBean i genereaz ele nsele rspunsul. Avantajul acestei abordri este simplitatea n programare. Dezavantajele abordrii sunt lipsa unei bune scalabiliti i poriuni mari de cod Java inclus n pagina JSP.
Browser la client Server
JSP sau Servlet-s Browser la client cerere/raspuns Intercepie cereri client
<<uses or instantiates>> Browser la client Enterprise JavaBeans BD
Fig.6.7 Arhitectura client-server orientat pagin a unei aplicaii JSP
141
n continuare sunt prezentate dou variante arhitecturale acestei abordri. Page-View n aceast variant tot codul Java este inclus n interiorul HTML. Cererile sunt adresate direct la o pagin JSP care conine cod Java inclus i tag-uri care genereaz coninut dinamic pentru a fi substituit n pagina HTML.
Cerere Rspuns JSP Procesare business
Fig.6.8 Varianta Page-View a arhitecturii client-server orientat pagin a unei aplicaii JSP
Page-View cu component (Bean) Aceasta este o variant mai complex n care majoritatea codului pentru logica aplicaiei i pentru accesul la date migreaz la o alt component, numit Worker. n pagina JSP rmn, n special, tag-urile destinate formatrii informaiilor i specificrii componentelor pentru prelucrarea datelor. Varianta prezint avantajele partajrii componentei de ctre mai multe pagini JSP i posibilitii modificrii independente de pagini a componentei care implementeaz logica aplicaiei.
Cerere JSP Rspuns Worker bean
Procesare business
Fig.6.9 Varianta Page-View cu component Bean, a arhitecturii client-server orientat pagin a unei aplicaii JSP
Abordarea dispecer
Abordare dispecer distribuie codul pe mai multe straturi. Un servlet sau o pagin JSP are funcie de mediator sau controller. Acesta este responsabil cu delegarea cererilor ctre alte pagini JSP sau ctre componente Java (JavaBeans). Aceast abordare poate fi realizat ntr-una din urmtoarele trei variante arhitecturale. Mediator-View Conform arhitecturii din figura 6.10, mediatorul execut o serie de operaii comune (ex. autentificare), apoi solicit diferite servicii pentru realizarea unei cereri complexe. Fiecare serviciu este parionat n cte dou componente, componenta de prezentare i componenta de execuie (Worker).
142
Cerere JSP mediator
serviciu JSP prezentare Worker bean Dele gare Procesare business
aspun
Rspuns
serviciu JSP prezentare serviciu JSP prezentare Worker bean
Fig.6.10 Varianta Mediator-View a arhitecturii orientat dispecer pentru aplicaii JSP
Mediator-Composite View Aceast arhitectur are un grad sporit de complexitate pentru a realiza separarea unui ablon HTML static dar cu modificri frecvente, care astfel pot fi fcute independent de restul aplicaiei. Arhitectura permite utilizarea de pagini JSP incluse pe mai multe nivele.
JSP Cerere JSP mediator Antet Raspuns Coninut Subsol Static HTML template Cu modificri frecvente
erere
Antet
aspun
Coninut Subsol
Fig.6.11 Varianta Mediator-Composite-View a arhitecturii orientat dispecer pentru aplcaii JSP
Component Worker bean
Component pentru delegare operaii
EJBs
Resurs back-end
143
Service to Workers Aceast arhitectur se suprapune peste arhitectura MVC separnd n mod clar componentele acesteia.
Cerere SERVICIU
CONTROLLER
JSP mediator
Fig.6.12 Varianta Service-to-Workers a arhitecturii orientat dispecer pentru aplicaii JSP
Delegare business VIEW JSP Etapa 2 MODEL Etapa 1
Rspuns
WORKERS Resurse EJB Etapa 3 JavaBean
JSP mediator reprezint controller-ul care primete cererea ce conine gesturile utilizatorului i apeleaz componentele WORKERS (Etapa 1) care sunt responsabile cu actualizarea modelului prin intermediul componentei de delegare business. Starea modelului este, de asemenea, pstrat n componentele JavaBean. Dupa realizarea operatiilor de actualizare a modelului de ctre componentele din WORKERS, controllerul (JSP mediator) notific componenta (Etapa 2) view reprezentat de pagina JSP, care transmite rspunsul la client. Aceast component construiete rspunsul pe baza informaiilor pe care le solicit de la componenta WORKERS (Etapa 3).
144

Tehnologii WEB Decrypted

Uploaded by

Copyright:

Available Formats

You might also like

Tehnologii WEB Decrypted

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tehnologii WEB Decrypted

Uploaded by

Copyright:

Available Formats

TEHNOLOGII WEB

SUPORT CURS An universitar 2006-2007

Conf. dr. Cristina Mndru

1. CONCEPTELE DE BAZ ALE ARHITECTURII WEB................................ 5

3. ARHITECTURI PENTRU EXTINDERE FUNCIONALITATE LA CLIENT 43

4. XML I TEHNOLOGII ASOCIATE ............................................................ 60

5. ARHITECTURI PENTRU EXTINDERE FUNCIONALITATE LA SERVER ............................................................................................................................... 103

1. CONCEPTELE DE BAZ ALE ARHITECTURII WEB

1.1 Arhitecturi pentru INTERNET

Fig.1.1 Arhitectur hardware pentru Internet

Fig.1.2 Comunicare logic n Internet

Fig.1.3 Comunicare utiliznd furnizori de servicii Internet

Fig.1.4 Paradigma client/server

Fig.1.5 Arhitectura cu un server i mai muli clieni

Interfaa client Interfaa cu site-ul Web

Fig.1.7 Arhitectura Web clasic

Fisiere *.html aflate n sistemul de fiiere al mainii gazd

Fig.1.8 Arhitectura MVC

Graphic User Interface. 9

1.2 Comunicarea in Web

Semnificaie Comanda de executat asupra resursei:

Uniform Resource Locator. 11

Antet (header) Linie liber Coninut (body)

Informaii despre cerere i client Separator obligatoriu Date de transferat

ANTET Meta-informaii (informaii despre pagin)

Fig.1.11 Relaia ntre bazele arhitecturale ale Web-ului

Nu nseamn c sunt periculoase i pot fi acceptate ca atare. 19

1.3 Formate de date

Separarea ntre coninut, prezentare i interaciune

1.4 Principiile generale ale arhitecturii Web

Resource Description Framework (v. cap. 9). 24

2.1 Modelul DOM-HTML

Fig.2.1 DOM ca arbore de noduri

Fig.2.2 DOM ca arbore de subclase

i reprezentarea sa conform modelului DOM HTML:

Fig.2.3 Reprezentarea DOM HTML a unui document HTML 29

elements anchors applets objects frames images links plugins

text textarea radio

checkbox select button options

Fig.2.4 Ierarhii de obiecte DOM-HTML

all P DIV SPAN H1, H2, H6 etc

all nume tag-uri

Fig.2.5 Ierarhii de obiecte DOM-HTML pentru foi de stil

2.2 HTML (HyperText Markup Language)

<HTML> obiectul document </HTML>

atribut1=val1 atribut2=val2 atributn=valn>

Restul atributelor iau valori implicite.

NAME=nume_forma ACTION=url METHOD=POST>

Sunt asemntoare unor ferestre distincte. 34

sau dac se folosete incluziunea seturilor de cadre ca n exemplul urmtor:

Fig.2.6 Zonele unei entiti document considerate n aplicarea foilor de stil

Ea se aplic elementelor ol din urmtorului fragment de document:

dar nu se aplic n urmtorul caz:

Particularizri ale utilizrii stilului pentru un anumit tag

3. ARHITECTURI PENTRU EXTINDERE FUNCIONALITATE LA CLIENT

Nivel interpretoare cod

Fig.3.1 Extinderea funcionalitii la CLIENT

3.2 OBIECTE N PAGINI WEB

Fiiere .html, .css, .js, .class