Sunteți pe pagina 1din 68

Modelare software. UML şi XML

XML(1)

1.3. XML. Scurt istoric

XML a apărut prin munca a 11 oameni care au fost sprijiniţi de către un grup de 150 de membri interesati de dezvoltarea unui altfel de limbaj. XML a apărut din nevoia de a rezolva problemele pe care le aduceau SGML-ul (Standard Generalized Markup Language) şi HTML-ul (HyperText Markup Language), acestea fiind uneori prea restrictive. Grupul de lucru XML a reusit dezvoltarea acestuia prin intalniri saptămânale, telefonice şi emailuri, fără a se intâlni vreodată fizic pentru a discuta anumite probleme apărute în implementarea limbajului. Baza acestuia a fost pusă în 20 de săptămâni de muncă (iulie-noiembrie 1996), apoi a fost publicată prima specificaţie a XML-ului. Astfel, la 10 Februarie 1998, XML 1.0 a devenit o recomandare a W3C (Word Wide Web Consortium). Lucrul uimitor este faptul că oameni care lucrau la firme diferite au uitat de orice rivalitate şi au reuşit să realizeze un open-standard care se adresează în totalitate nevoilor utilizatorului. Au fost urmărite următoarele aspecte:

o

Extensibilitate - să se poată defini noi taguri atunci când este nevoie.

o

Structurare - să se poată modela datele la orice nivel de complexitate.

o

Validare - cercetarea datelor pentu corectitudine structurală.

o

Independenţa de mediu - publicarea conţinutului în format multiplu.

o Independenţă de platforma şi producător - capacitea de a procesa orice document folosind software comercial standard şi unelte simple pentru text. Ideea de baza este următoarea: XML este o tehnologie care permite crearea unui număr nelimitat de diferite limbaje de mark-up pentru diverse scopuri. Motivul pentru care ii creste popularitatea este faptul că poate fi parsat de un procesor suficient de mic suportat in fiecare Web Browser. XML poate să facă pentru date ceea ce Java a făcut pentru programare: să facă datele atât independente faţă de platforma, cât şi de producător. Există două versiuni curente: XML 1.0 (cea care a apărut în 1998) şi XML 1.1 (apăruta în 2004). Aceste 2 versiuni diferă în cerinţele pe care le au pentru numele de atribute şi de elemente, dar nu semnificativ.

1.4. XML şi HTML

XML este un limbaj cu etichete şi atribute asemănător cu HTML, dar un HTML transformat atât de mult, încât nu mai poate fi recunoscut. XML este mult mai structurat decât HTML. În timp ce procesoarele HTML acceptă în mod curent cod incorect şi diform şi încearcă să îi dea sens pe ecran, XML trebuie să se oprească atunci când găseşte o eroare fatală, care poate fi aproape orice tip de eroare. Aceasta este într-un fel o întoarcere la primele zile ale prelucrării datelor, când orice eroare din cod era pedepsită cu o golire de memorie (core dump). Totuşi pe lângă acest comportament, XML este cu mult mai puternic. În timp ce HTML se mulţumeşte cu aproximativ 77 de etichete, în funcţie de cine le-a numărat, XML are un număr de etichete aproape infinit, structurate în aproape orice fel se doreşte. De fapt, într- un fel aţi scris cod XML încă din timpul utilizării anterioare a HTML. Nu numai că un HTML bine făcut este foarte aproape de XHTML – un înlocuitor al HTML care respectă XML – dar un cod HTML 4.0 curat este destul de lizibil ca XHTML 1.0. Deoarece HTML a fost structurat ca o aplicaţie SGML, iar XML este o submulţime a SGML, acest lucru este logic. Diferenţele sintactice minore dintre XHTML, un vocabular XML, şi HTML, un vocabular SGML, pot fi ajustate automat dacă este nevoie. Autorul unui document XML oferă de obicei un manual de creare sau codare (sau o foaie, pentru DTD-uri mici) descriind etichetele utilizate în aplicaţia XML, atributele lor, valorile posibile şi modul lor de imbricare. Urmărirea unui astfel de manual de codare nu este mai dificilă decât reţinerea faptului că o linie de tablou <tr> trebuie să fie imbricată în interiorul unui tablou <table> şi nu are, sau nu ar trebui să aibă,

sens în afara acelui context. Pentru majoritatea situaţiilor, acest lucru este suficient. Autorii XML nu trebuie să fie nişte guru ai tehnicii are să poată extrapola instantaneu structura şi scopul unei aplicaţii aruncând doar o privire DTD-ului, la fel cum proprietarul unui automobil nu trebuie să fie expert în mecanica auto. XML este capabil să ofere autorilor suficient ajutor în învăţarea modului de utilizare a unei anumite aplicaţii, deoarece aceştia sunt încurajaţi să dea etichetor nume sugestive, care să fie uşor de reţinut. Autorul unei aplicaţii ar trebui să furnizeze un manual de creare care să explice în termeni simpli modul de utilizare a aplicaţiei. Teoria este că orice viitor informatician va putea studia codul dumneavoastră XML şi îşi va da seama ce este şi cum este structurat, fără a fi nevoit să recurgă la documentaţia de proiectare originală (probabil pierdută în praful istoriei), bazându-se numai pe structură şi numele elementelor. Cu toate că orice procesor XML vă poate spune despre codul dumneavoastră dacă este sau nu construit corect, iar un manual vă poate ajuta să construiţi un document valid, DTD-ul vă permite să verificaţi fără ambiguităţi munca dumneavoastră.Totuşi, în funcţie de tipul de creare utilizat, acesta poate fi un pas diferit de procesul de editare. Codul dumneavoastră îndeplineşte acest ideal în funcţie de utilizarea pe care o daţi numelor etichetelor, totuşi între anumite limite:

Numele de etichete care încep cu şirul “xml”, indiferent de tipul literelor, sunt rezervate; adică, indiferent de situaţie, nu vă este permis să le creaţi. Nu le inventaţi după voia dumneavoastră. Dacă simţiţi că trebuie să aveţi un astfel de nume de etichetă, propuneţi-l la W3C ca parte a unei “Propuneri de membru” (presupunând, evident, că sunteţi un membru) şi vedeţi ce se întâmplă.

Numele de etichete care conţin caracterul două puncte pot fi interpretate ca identificatori având asociată o zonă de nume, deci utilizarea celor două puncte în numele etichetelor este puternic combătută şi poate fi chiar interzisă.

Un nume de etichetă trebuie să înceapă cu o “literă”, care în acest context este orice

literă sau ideogramă Unicode/ISO/IEC 10646, sau cu o liniuţă de subliniere (sau cu două puncte, pe care ştiţi deja că este bine să le evitaţi pentru a preveni confuzia cu zonele de nume). În continuare, numele unei etichete poate conţine orice “literă”, ideogramă sau cifră Unicode/ISO/IEC 10646, caractere de combinare, caractere de extindere, puncte, cratime, spaţii sau două puncte. De altfel, puţine limbi de pe glob au caractere cu care să nu poată începe un nume corect în limba respectivă. Aceste caractere sunt excluse din lista de caractere dacă se află într-o poziţie în care pot fi văzute ca “primele” după o cratimă sau un alt separator logic de cuvinte. Dar în cazul în care cunoaşteţi limba, acest lucru va fi evident. Poate că vă trebuie doar să scăpaţi de unele deprinderi rele pentru a deveni un autor XML priceput, aşa că aici vă veţi concentra asupra diferenţelor dintre XML şi HTML. Acest subiect evidenţiază mulţimea de deprinderi necesare pentru XML şi clarifică numeroasele asemănări sintre XML şi HTML:

XML este sensibil la tipul literelor deoarece majusculele nu reprezintă un concept universal – Dacă aţi trata literele mari şi mici ca fiind echivalente, ar trebui să faceţi la fel pentru mii de alte variante de litere în alte limbi, o operaţie împovărătoare. Unele limbi nici nu au tipuri de litere. De exemplu, în limba ebraică nu există litere mici, iar limba arabă nu face distincţie între forma iniţială, de mijloc şi finală a literelor. Pentru cei care preferă să scrie etichetele cu majuscule şi atributele cu litere mici, pentru a le evidenţia, aceasta este o ştire teribilă. Dar editoarele de cod moderne nu mai acordă o importanţă aşa de mare acestui lucru ca înainte. De exemplu, precizarea anumitor culori pentru a marca etichete este un lucru obişnuit, deci utilizarea majusculelor este întrucâtva un anacronism istoric, asemenea numerelor de linii în COBOL.

XML este foarte precis cu privire la imbricarea corectă a etichetelor – Etichetele nu se pot încheia într-un context diferit de cel de început. Deci, dacă doriţi <bold><italics>, trebuie să închideţi fraza evidenţiată cu </italics></bold>, pentru a evita o eroare fatală. Deoarece XML poate referi şi include documente XML şi fragmente de documente oriunde pe Web unde dumneavoastră nu aveţi control,

fiecare document XML trebuie să se supună aceloraşi reguli pentru a nu strica alte documente.

XML nu este bine protejat împotriva recursivităţii – Cu toate că este posibil să stabiliţi excluderi explicite la un anumit nivel, la o structură complexă a unui document este dificil să menţineţi acele excluderi la un nivel redus, mai ales atunci când utilizaţi etichete care pot fi aplicate la orice nivel. Deci, interdicţia HTML referitoare la includerea unei etichete ancoră <a> în interiorul altei etichete ancoră există şi în XML, dar nu este impusă dincolo de includerea directă.

XML vă obligă să închideţi fiecare etichetă, chiar şi etichetele vide – Deoarece este posibil să creaţi un document XML care să nu utilizeze un DTD, un procesor XML nu are de unde să ştie dacă o etichetă este sau nu vidă. Deoarece toate documentele XML trebuie să fie construite corect, dumneavoastră trebuie să marcaţi etichetele vide cu o sintaxă specială care spune unui procesor XML că eticheta este vidă şi închisă. Acest lucru îl realizaţi plasând un spaţiu şi un caracter slash la sfârşitul etichetei, astfel:

<break /> Există o sintaxă alternativă, care este la fel de bună pentru procesoarele XML reale, dar blochează frecvent browserele Web atunci când este utilizată cu XHTML; aceasta cere ca o etichetă vidă, cum ar fi <br>, să fie închisă cu </br>, astfel:

<br></br> Comportamentul exact poate diferi în funcţie de poziţia în cod şi de eticheta vidă care se închide. Pe scurt, această sintaxă este predispusă la erori şi ar trebui evitată.

XML necesită încadrarea valorilor atributelor fie între apostrofuri, fie între ghilimele – Acolo unde HTML este indulgent, mai ales în ceea ce priveşte numerele şi aproape orice şir fără spaţii în interior, XML tratează totul ca şir de caractere şi lasă aplicaţia să îşi dea seama singură de toate acestea.

XML recunoaşte mai multe limbi – Spre deosebire de HTML, seturile de caractere

extinse utilizate în multe limbi europene nu sunt pe deplin recunoscute în mod prestabilit. Există un mecanism simplu pentru includerea acestora, precum şi a întregului set de caractere Unicode (cunoscut, de asemenea, şi ca ISO/IEC 10646) care are peste un milion de caractere, deci suportul pentru chineză, arabă şi multe alte limbi mai exotice ale lumii este un lucru uşor. În afară de diferenţele menţionate în această listă, XML este foarte asemănător cu HTML din punctul de vedere al marcării etichetelor, al argumentării atributelor şi al trecerii conţinutului între perechi de etichete. Dacă scrieţi HTML curat, atunci conversia HTML-ului dumneavoastră la XHTML-ul bazat pe XML este atât de simplă încât este posibil să lăsaţi un calculator să facă acest lucru în locul dumneavoastră. Desigur, XML nu se limitează la limbaje care seamănă cu HTML, deci structura documentului dumneavoastră este limitat numai de structura arborescentă necesară şi de propria dumneavoastră imaginaţie. Folosind deprinderile pe care probabil că le aveţi azi, puteţi începe realizarea de documente XML simple chiar după câteva ore de exersare. Limbajul a fost proiectat astfel încât să fie transparent la utilizare pentru a putea fi înţeles şi utlizat cu uşurinţă. Descrierile XML succinte sau complicate din majoritatea documentelor sunt greu de înţeles în efortul de a fi explicit într-un mod în care programatorii să îl poată translata cu uşurinţă în aplicaţii care să funcţioneze. Înainte de a începe dezmembrarea limbajului, ar trebui să priviţi documentul XML ca întreg.

2.1 Definirea unui document XML ca întreg

Un document XML este o colecţie de entităţi care pot fi sau nu analizate. Datele care nu sunt înţelese de un procesor XML, date binare sau date care au sens numai pentru alte

aplicaţii, reprezintă date neanalizate. Datele înţelese de XML, fie ca şi caractere fie ca marcaje, sunt date analizate. Un document XML trebuie să fie construit corect. În Recomandarea XML 1.0 a W3C, citată cu exactitate, această situaţie este descrisă concis prin următoarele cerinţe:

Luat ca întreg, corespunde producţiei etichetate ca document.

Satisface toate constrângerile de construire corectă din această specificaţie (Recomandarea XML 1.0 şi apoi 1.1)

Fiecare entitate analizată, referită direct sau indirect în cadrul documentului, este

construită corect. Prima constrângere spune că pentru a fi construit corect, un document XML trebuia să respecte toate regulile care descriu un document în Recomandarea XML 1.0. Acele reguli spun în primul rând că un document XML trebuie să conţină un prolog şi un singur element care formează elementul rădăcină al documentului, împreună cu comentarii opţionale şi instrucţiuni de prelucrare la sfârşitul documentului, dar, din păcate, analizorul XML nu are cum să spună dacă aceste comentarii şi instrucţiuni de prelucrare ataşate sunt sau nu ataşate documentului. Deoarece ele pot sa fie plasate după eticheta de încheiere, un analizor XML nu poate să spună nici dacă instrucţiunile de prelucrare şi comentariile ataşate au fost sau nu recepţionate. Aceasta constravine regulii generale din XML care spune că un analizor trebuie să fie capabil să indice dacă un document este sau nu complet. Dacă utilizaţi instrucţiuni de prelucrare sau comentarii, treceţi-le în prolog unde sunt mult mai în siguranţă şi nu se pot pierde.

Cea de a doua constrângere spune că documentul respectă constrângerile construirii corecte descrise în document. Una din constrângerile construrii corecte este că entităţile analizate recursiv sunt interzise. Recursivitatea din această interdicţie se referă la formarea unei bucle de entităţi în care o entitate se încorporează pe ea însăşi sau o altă entitate care se încorporează pe ea însăşi indiferent de nivelul de indirectare. Aceasta mai înseamnă şi că un document nu se poate referi la el însuşi, nici măcar indirect printr-o entitate externă. El se poate referi la o entitate externă numai dacă aceasta nu se referă la ea însăşi, chiar şi indirect. Este posibil ca analizoarele care nu validează să nu depisteze această eroare, dar aceasta este totuşi o eroare. Din punct de vedere logic este evident că dacă documentul A conţine documentul B, definindu-l pe B ca şi când l-ar conţine pe A se generează o buclă infinită. Bucla infinită este interzisă. În termeni XML, construcţia corectă este o altă modalitate de a spune că un document XML formează un arbore, sau o ramură a unui arbore, adică este complet. Acest lucru este necesar deoarece XML vă permite să construiţi documente mai mari din unele mai mici şi reprezintă o cheie a posibilităţii de utilizare a XML pe Web. Deşi construirea corectă poate fi considerată suficientă deoarece un document construit corect are un DTD care îl descrie, pot fi construite un număr infinit de DTD-uri care, de asemenea, să îl descrie. Deci, pentru validitate totală, un DTD asociat este necesar. Producţia documentului este definită în numai două afirmaţii, preluate din nou din Recomandarea XML 1.0:

Conţine unul sau mai multe elemente.

Există un singur element, numit rădăcină sau element document, care să nu aibă nici o

parte a sa în conţinutul oricărui alt element. Pentru toate celelalte elemente, dacă eticheta de pornire se află în conţinutul unui alt element, atunci şi eticheta de încheiere se află în conţinutul aceluiaşi element. Exprimat mai simplu, elemente delimitate de etichete de pornire şi încheiere sunt imbricate corect unele în altele. Prima afirmaţie spune că într-un document trebuie să existe cel puţin un element sau, altfel spus, un document construit corect nu poate fi vid. Cea de a doua afirmaţie spune că, într-un sens restrâns, un document trebuie să fie un arbore. El nu poate fi o reţea conectată arbitrar sau să aibă orice altă topologie care nu se reduce la un arbore simplu. El trebuie să fie complet pentru a putea vedea diferenţa dintre o descărcare reuşită şi una parţială.

2.2. Prologul:declaraţia XML

Fiecare document XML, ar trebui să înceapă cu o declaraţie XML care identifică fişierul ca fiind un fişier XML şi identifică, de asemenea, versiunea XML utilizată în documentul respectiv. Caracterul opţional este datorat numai faptului că pe Web există multe fişiere HTML şi SGML care corespund perfect unui document XML construit corect. De asemenea, declaraţia XML este locul unde este declarată codificarea dumneavoastră şi dacă documentul este sau nu autonom. Ordinea din fragmentul următor este obligatorie cu toate că atributele encoding şi standalone sunt ambele opţionale.

<?xml version='1.0' encoding='character encoding' standalone='yes|no'?>

Codificările vă permit să identificaţi pe care dintre multiplele seturi de caractere intenţionaţi să le utilizaţi în document. Acest lucru este important deoarece, spre deosebire de HTML, care implică ASCII, şi vă obligă să folosiţi nume ASCII, XML permite vorbitorilor de Hindi, de exemplu, să utilizeze codificarea lor şi să facă textul şi mediul de editare lizibil şi pentru persoanele obişnuite care pot fi autori XML. Sau, un autor chinez poate să prefere caracterele chinezeşti în etichete şi în conţinut cu câteva limitări bazate pe regulile limbajului în sine, puteţi utiliza moduri de scriere şi ideograme atât în numele etichetelor cât şi în conţinut. Ca un exemplu simplu referitor la tipurile de limitări bazate pe regulile limbajului, gândiţi-vă la literele indice superior din limba engleză “st”, din cvasi-abrevierea “1 st ”. Literele modifică de fapt pe “1” astfel încât dumneavoastră să ştiţi că trebuie să pronunţaţi “first” (primul). Nu există în limba engleză (sau într-o altă limbă europeană) situaţie în care să aveţi voie să folosiţi această construcţie la începutul unui “cuvânt”. Recomandarea XML defineşte câteva posibile valori pentru atributul encoding: UTF-8, UTF-16, ISO-10646-UCS-2, şi ISO-10646- UCS-4, care se referă la codificările Unicode/ISO-10646. În conformitate cu Recomandarea XML 1.0 a W3C, “Documentele autonome nu au declaraţii de marcare externe care să afecteze informaţia XML transferată de procesorul XML unei aplicaţii”. Acesta este un mod extraordinar de succint şi obscur de a spune că standalone=”yes” înseamnă că:

într-un DTD extern nu există valori prestabilite declarate ale atributelor care să nu fie setate explicit în document.

nu sunt utilizate alte entităţi în afară de &amp;, &lt;, &gt;, &apos;, şi &quot;, care nu au fost declarate local sau poate citite prin referinţă dintr-un fişier.

nu există elemente care să aibă ca şi conţinut numai spatii albe de orice natură.

nu există atribute externe care trebuie normalizate, deci conţinutul atributelor nu poate

conţine spaţii albe, caractere sau referinţe la entităţi. Aceasta nu înseamnă că documentul nu are nimic extern. Aceasta înseamnă în special că, indiferent de locul în care un procesor XML care nu validează se opreşte din citirea documentelor externe, se opreşte prelucrarea tuturor declaraţiilor. Toate aceste lucruri le puteţi face dacă şi numai dacă le puneţi în submulţimea DTD-ului intern. Datele externe care nu sunt marcaje nu fac subiectul acestei afirmaţii. Deci, puteţi avea fişiere grafice, fişiere text incluse şi orice altceva, atât timp cât ele nu sunt marcaje şi le-aţi declarat în submulţimea DTD-ului intern. În mod fundamental, proiectantul DTD-ului trebuie să descifreze dacă

documentul creat utilizând acel DTD poate fi sau nu autonom şi să comunice acest lucru oamenilor inclusiv autorilor. Autorii care ştiu că DTD a fost proiectat pentru a fi autonom sau cei care au convertit un document care nu a fost proiectat să fie autonom în acest format, pot insera standalone=”yes” în declaraţia lor XML ca o documentaţie a acelui fapt Atributul standalone are valoarea implicită “no”, deci foarte rar veţi întâlni în documentele XML o astfel de sintaxă. Mai jos sunt date câteva exemple de definire a declaraţiei XML:

<?xml version='1.0' ?> <?xml version='1.0' encoding='US-ASCII' standalone='yes' ?> <?xml version='1.0' encoding='UTF-16' ?> <?xml version='1.0' encoding='ISO-10646-UCS-2' ?> <?xml version='1.0' encoding='ISO-8859-1' ?>

2.3. Construirea prologului unui document XML: Declaraţia tipului documentului (Document Type Declaration)

Prologul unui document XML conţine mai multe instrucţiuni. Prima, declaraţia XML, afirmă că documentul următor este XML. Cea de a doua, declaraţia tipului documentului (Document Type Declaration), este metoda pe care o utilizaţi pentru a identifica definiţia tipului documentului (Document Type Definition - DTD) folosită de un anumit document. Faptul că acronimul DTD poate fi aplicat la Document Type Declaration este o coincidenţă nefericită. DTD se referă numai la Document Type Definition. Într-un document XML poate exista o singură declaraţie a tipului documentului, deci este introdusă chiar în instanţa documentului. Deoarece pot fi combinate mai multe DTD-uri pentru a forma un singur document, aceasta permite controlul încărcării DTD-urilor în fiecare document. Declaraţia tipului documentului (DOCTYPE) are două părţi, ambele opţionale. Prima se referă la un DTD extern, şi utilizează cuvinte cheie PUBLIC sau SYSTEM pentru a identifica o intrare dintr-un catalog, respectiv un URI. În cazul în care cataloagele nu sunt

implementate în procesorul dumneavoastră XML, puteţi specifica ambele părţi deodată, fără cel de al doilea cuvânt cheie:

<!DOCTYPE nume-document PUBLIC “{catalog id}”> <!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}”> <!DOCTYPE nume-document SYSTEM “{uri}”>

Cea de a doua parte opţională a declaraţiei DOCTYPE vă permite să introduceţi submulţimea internă a unui DTD direct în documentul dumneavoastră. Există restricţii severe cu privire la genul de informaţie pe care o puteţi introduce DTD-ul intern, dar oricum puteţi face destul de multe. Submulţimea internă a unui DTD este încadrată între paranteze drepte, astfel:

<!DOCTYPE nume-document [ {declaraţiile DTD-ului intern} ]>

De asemenea, cele două pot fi combinate, permitându-vă să adaugaţi anumite tipuri de declaraţii şi entităţi aproape în orice mod:

<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}” [ {declaraţiile DTD-ului intern} ]>

Pentru claritate, submulţimea internă este evidenţiată ca mai jos:

<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}” [ {declaraţiile DTD-ului intern} ]>

Declaraţia DOCTYPE trebuie să utilizeze numele elementului rădăcină al DTD-ului fie acesta intern sau extern, ca fiind câmpul etichetat nume-document din exemplele anterioare. Deci dacă numele elementului rădăcină al DTD-ului dumneavoastră este Dave, declaraţia dumneavoastră DOCTYPE ar trebui să înceapă astfel:

<!DOCTYPE Dave …>

Manualul dumneavoastră de codare vă indică ce să treceţi în DOCTYPE dacă sunteţi un autor. Dacă sunteţi un proiectant DTD, atunci ar trebui să furnizaţi un astfel de document sau o foaie de codare fiecărui autor. De asemenea, puteţi crea un DTD master care apelează părţile DTD de care aveţi nevoie, lucru care seamănă cu comenzile dintr-un meniu. Atunci când aveţi o combinaţie de funcţionalităţi care vă permite să creaţi structura documentului de care aveţi nevoie, puteţi publica DTD-ul rezultat şi să scăpaţi de neplăcerea de a-l face iar şi iar pentru fiecare document nou.

2.4.

Crearea corpului documentului

Un document XML este alcătuit din text, care de obicei este format dintr-un amestec de marcaje şi date caracter. Prologul conţine numai marcaje, dar nu aceasta este partea interesantă, deoarece dumnevoastră aveţi nevoie de date care să însoţească marcajele care, altfel, nu ar fi decât nişte cutii goale ce aşteaptă să fie umplute. Corpul documentului dumneavoastră conţine aproape tot ceea ce contează din perspectiva unei aplicaţii împrăştiate generos în cadrul marcajelor. Un DTD poate declara multe tipuri de date care să poată fi utilizate în documentul dumneavoastră, dar tipul de date prestabilit este întotdeauna CDATA, pentru date obişnuite de tip caracter. Foaia sau manualul de codare vă indică ce tip de dată poate fi introdus în fiecare atribut sau câmp cu conţinut element. Presupunând că tipul de date este CDATA, în câmp puteţi pune aproape orice doriţi atât timp cât nu conţine un marcaj în afara unei secvenţe escape.

Este posibil să construiţi un DTD care să nu conţină text în interiorul elementelor. În schimb, puteţi pune datele semnificative în interiorul atributelor asociate fiecărui element, care pot fi toate declarate ca fiind vide sau având numai conţinut element. Acest lucru se face uneori pentru a converti un document utilizând un standard de codificare cum ar fi MARC, care este în esenţă un format binar, la XML. Marcajul este format din ansamblu de date non-caracter dintr-un fişier XML. Diversele forme pe care le poate lua un marcaj sunt prezentate în tabelul următor:

Tabel 1

Sintaxa marcajului XML

Tipul marcajului

Sintaxa marcajului

etichete de pornire

<numeElement [atribute] > …

etichete de încheiere

… </numeElement>

etichete element vid

<numeElement [atribute] />

referinţe entitate

&numeEntitate; sau %parametruNumeentitate

referinţe caracter

&#numărZecimal; sau &#xnumărHexa;

comentarii

<!-- comentariu -->

delimitaoarele secţiunii CDATA

<![CDATA[ informaţii

cdata

]]>

declaraţiile tipului documentului

<!DOCTYPE nume Idextern? [informaţiiDTD]>

instrucţiuni de prelucrare

<?Idprocesor date ?>

declaraţia XML

<?xml version encoding standalone

?>

Toate celelalte sunt date de tip caracter. Marcajul începe întotdeauna fie cu caracterul <, caz în care se încheie întotdeauna cu caracterul >, fie cu caracterul &, caz în care se încheie întotdeauna cu caracterul ;. În continuare vor fi studiate diferitele tipuri de marcaje:

2.5. Formarea structurilor logice în XML

Imbricarea elementelor este singurul mecanism utilizat pentru a arăta structura logică dintr-un document XML. Etichetele de pornire şi încheiere din fluxul de text spun procesorului XML că a fost întâlnit un nod. Dacă procesorul XML întâlneşte o altă etichetă de pornire înainte de eticheta de încheiere corespunzătoare, atunci procesorul ştie că acesta este

fie un nod nou în arbore, fie o frunză. Dacă nu gaseşte o nouă etichetă de pornire şi întâlneşte

o etichetă de încheiere, atunci procesorul ştie că aceasta este o frunză şi că poate acţiona

iterativ la acel nivel al arborelui până când întâlneşte o altă etichetă de pornire sau de încheiere. Prelucrarea acţionează treptat, bazându-se pe această regulă simplă. Dacă procesorul validează documentul, atunci fiecărui nod i se poate asocia o regulă care să determine ce tip de conţinut poate apărea în el. O etichetă vidă este, prin definiţie, o frunză, deoarece nu poate avea nici un conţinut. Majoritatea structurilor de date conţinute într-un document XML pot fi accesate secvenţial fără a construi structura în memorie. O etichetă de pornire începe un nod sau o frunză, iar eticheta de încheiere corespunzătoare îl(o) încheie. Orice etichete întâlnite între o etichetă de încheiere corespunzătoare ei încep un nod sau o frunză nouă. Acest principiu reprezintă baza lui SAX şi a altor procesoare XML conduse prin evenimente. Restul structurii logice a documentului este definit prin atributele asociate fiecărui

element. În plus, structura logică poate diferi în funcţie de conţinutul secţiunilor condiţionale din cadrul documentului sau al componentelor sale. Imbricarea entităţilor este singurul mecanism utilizat pentru a arăta structura fizică dintr-un document XML. Definiţiile de entităţi întâlnite în fluxul de text îi comunică procesorului XML că a fost găsită o altă entitate. Există multe tipuri de entităţi, de la entităţile mici care formează caractere individuale, până la entităţile externe care vă permit să incorporaţi în documentul dumneavoastră porţiuni din alte documente XML sau să includeţi într-un document referinţe la date neanalizate, cum

ar fi fişiere multimedia pentru redarea ulterioară de către un agent utilizator. Un document XML este o colecţie de astfel de entităţi. Fiecare din aceste subentităţi trebuie să fie completă în sine. Aceasta înseamnă că, deoarece structura documentului ca întreg trebuie să fie un arbore simplu, fiecare subentitate trebuie să fie un singur nod sau trebuie să fie, de asemenea, un arbore simplu. Structuri mai mari puteţi construi prin adăugarea nodurilor sau a arborilor subentitate ca porţiuni ale arborelui mai mare. Dacă documentele dumneavoastră conţin mai mulţi subarbori în fişiere diferite, fiecare fişier subarbore trebuie să fie un document arbore document XML complet în sine.

2.6. Elementele XML

Majoritatea conţinutului unui document XML este format din elemente. Fiecare document XML are un element top-level, cunoscut ca elementul document. Definirea unui element constă într-o pereche de taguri: unul de deschidere şî unul de închidere. Exemplele următoare sunt concludente:

<tagname></tagname>

<tagname/>

<tagname>copil</tagname>

In primele două cazuri sunt definite elemente vide în timp ce ultimul este un element cu un

copil. Numele elementelor în XML sunt case sensitive şi trebuie să înceapă cu o literă sau cu

caracterul

Un element definit cu mai mulţi copii este următorul:

<Persoana> <nume>Adrian</nume>

<varsta>21</varsta>

</Persoana>

Din cauză că XML permite programatorilor să-şi aleagă propriile nume de taguri, este posibil ca 2 programatori să aleagă acelaşî nume pentru unul sau pentru mai multe taguri. Spaţiile de nume XML oferă o cale pentru distingerea elementelor XML care au acelaşi nume dar de fapt fac parte din vocabulare diferite. Aceasta este posibil prin asocierea unui element cu un spaţiu de nume. Conform specificaţiilor, pentru declararea spaţiilor de nume este folosit atributul xmlns, iar valoarea acestuia este un URI. Prin intermediul acestei construcţii se asociază un vocabular, denumit spaţiu de nume pentru elementele în cauză. Numele unui element sau atribut este precedat de un prefix al spaţiului de nume specificat. Forma prefix:nume este definită ca nume calificat. In exemplele următoare vom clarifica câteva posibilităţi de utilizare a spaţiilor de nume:

<pre:Persoana xmlns:pre='urn:upt.ro' > <nume>Adrian</nume>

<varsta>21</varsta>

</pre:Persoana>

Elementul cu numele local persoana este mapat spaţiului de nume precizat în xmlns. Ambii copii, adică elementele nume şi varsta nu sunt asociaţi cu nici un spaţiu de nume. O declaraţie similară este următoarea:

<Persoana xmlns:pre='urn:upt.ro' > <nume xmlns=’’>Adrian</nume> <varsta xmlns=’’>21</varsta> </pre:Persoana> In acest caz, spaţiul de nume ar fi fost atribuit şî copiilor dacă nu aveam atribuirea xmlns=’’ care în fapt ne precizează că nu este asociat nici un spaţiu de nume. Dacă vroiam ca spaţiul de nume precizat în prima declaraţie să fie atribuit şi copiilor aveam:

<Persoana xmlns:pre='urn:upt.ro' > <nume >Adrian</nume> <varsta >21</varsta> </pre:Persoana>

O declaraţie similară cu aceasta, dar folosind prefixe este următoarea:

<pre:Persoana xmlns:pre='urn:upt.ro' > <pre:nume>Adrian</pre:nume>

<pre:varsta>21</pre:varsta>

</pre:Persoana>

Elementele pot avea atribute în definire. Acestea oferă date suplimentare despre conţinutul unui element la care apar. Procesarea instrucţiunilor este utilizată pentru oferirea de informaţii aplicaţiei care foloseşte documentul XML. Procesarea instrucţiunilor are 2 părţi, având următoarea sintaxă:

<?target data?> <?display table-view?> <?sort alpha-ascending?>

După cum se poate observa din exemplele de mai sus, în prima parte trebuie specificată ţinta sau numele instrucţiunii de procesare iar în partea a doua datele asupra cărora se aplică. Comentariile sunt reprezentate de următorul tag:

<!-- comment text -->

O altă secvenţă caracteristică documentelor XML sunt secvenţele escape:

<![CDATA[ textul poate conţine caracterele < sau & ]]>

Acestea sunt folosite în cazurile în care dorim să utilizăm caractere care nu pot fi utilizate în mod normal cum sunt cele din exemplu.

In final, voi prezenta un fişier XML definit corect:

<?xml version='1.0' encoding='UTF-8' ?> <p:Persoana xmlns:p='urn:upt.ro' > <nume>Adrian</nume> <!—Un student voios -->

<varsta>21</varsta>

<inaltime unitate='metri' >1.80</inaltime> </p:Persoana>

Modelare software. UML şi XML

XML(2,3)

3.1. DTD (Document Type Definitions)

DTD deserveşte 2 scopuri principale: oferă sintaxa care descrie structura logică a documentului şi alcătuieşte un document logic pentru entitătile fizice. Primul scop este deservit sintactic de DOCTYPE, ENTITY, NOTATION, ELEMENT, ATTLIST, ENTITY, şi NOTATION în timp ce al doilea de ELEMENT şî ATTLIST. Declaraţie DOCTYPE a fost prezentată deja în cursul anterior. Sintaxa ei poate fi uşor sintetizată în figura următoare:

ei poate fi u ş or sintetizat ă în figura urm ă toare: Figura 3.1. Sintaxa

Figura 3.1. Sintaxa DOCTYPE

Declaraţia ELEMENT Defineşte un element cu numele specificat în cadrul declaraţiei şi cu copiii care pot fi întâlniţi:

<!ELEMENT nume conţinut>

Sintaxa conţinutului poate fi declarată folosind următoarele variante:

- ANY - este permis orice copil pentru elementul declarat;

- EMPTY – nu este permis niciun copil pentru respectivul element;

- (copil1, copil2,….) – doar copiii specificaţi în ordinea dată sunt permişi;

- (copil1|copil2|

- (#PCDATA) – este permis doar text în element.

)

– doar unul dintre copiii specificaţi sunt permişî într-un element;

Sintaxa poate avea şi anumiţi operatori cum ar fi: * care precizează că grupul de copii poate apărea de mai multe ori sau deloc, + trebuie să apară cel puţin o dată iar în cazul ? poate să apară o dată sau deloc. Pentru exemplificare am folosit următorul exemplu:

<!-- person.dtd --> <!ELEMENT person (name, age, children?)> <!ELEMENT name (fname, (mi|mname)?, lname)?> <!ELEMENT fname (#PCDATA)>

<!ELEMENT lname (#PCDATA)> <!ELEMENT mi (#PCDATA)> <!ELEMENT mname (#PCDATA)> <!ELEMENT age (#PCDATA)> <!ELEMENT children (person*)>

<!-- person.xml --> <!DOCTYPE person SYSTEM "person.dtd"> <person> <name>

<fname>Prenume1</fname>

<lname>Nume1</lname>

</name>

<age>43</age>

<children> <person> <name/>

<age>1</age>

</person> <person> <name>

<fname>Prenume2</fname>

<mi>P</mi>

<lname>Nume2</lname>

</name>

<age>15</age>

</person>

</children>

</person>

Declaraţia ATTLIST

Defineşte setul de attribute care este permis în cazul unui element. Fiecare atribut are un nume, un tip şi o declarare implicită. Declararea implicită poate fi:

- #REQUIRED – atributul este cerut pentru elementul specificat;

- #IMPLIED – atributul este opţional pentru elemental respective;

- #FIXED valoare – atributul va avea valoarea fixă specificată;

- valoare – este valoarea implicită a atributului. Dintre tipurile pe care le poate avea un atribut putem aminti:

- CDATA – date de tip caracter, arbitrare;

- ID – un identificator unic în cadrul documentului;

- IDREF(S) – o referinţă spre o valoare ID din document;

- NMTOKEN(S) – un nume valid XML;

- ENTITY – numele unei entităţi declarate în DTD. Pentru exemplificare vom considera exemplul următor:

<!-- emp.dtd --> <!ELEMENT employees (employee*)> <!ELEMENT employee (#PCDATA)>

<!ATTLIST

employee name CDATA #REQUIRED species NMTOKEN #FIXED "uman" id ID #REQUIRED mgr IDREF #IMPLIED manage IDREFS #IMPLIED>

<!-- emp.xml --> <!DOCTYPE employees SYSTEM "emp.dtd"> <employees> <employee name="Nume1" id="e100" manage="e101 e102"/> <employee name="Nume2" id="e101" mgr="e100"/> <employee name="Nume3" id="e102" mgr="e100"

manage="e103"species="uman"/>

<employee name="Nume4" id="e103" mgr="e102"/> <employee name="Nume5" id="e104"/> </employees>

Declaraţia ENTITY Declaraţia ENTITY este una dintre cele mai simple, în ciuda faptului că există atât de multe tipuri de entităţi. Lista restricţiilor referitoare la entităţi este oricum confuză şi este descrisă atât de succint în Recomandarea XML 1.0. În cazul în care consideraţi un document XML ca fiind o colecţie de entităţi care sunt în linii mari, obiecte, în sensul orientării spre obiecte, declaraţia unei entităţi este o metodă de a indica o instanţă a unui anumit obiect. Nu există multe opţiuni şi declaraţia nu este foarte greu de învăţat. Formatul declaraţiei este următorul:

de înv ăţ at. Formatul declara ţ iei este urm ă torul: Figura 3.2. Sintaxa ENTITY

Figura 3.2. Sintaxa ENTITY

Partea name are două opţiuni,după cum se poate observa, una fără modificator, şi una cu un semn procent (%) care precedă numele urmat de un spaţiu care marchează o entitate parametru. Partea valoare are trei opţiuni de bază: fie un şir încadrat între ghilimele, un

identificator care indică o intrare din catalog sau o locaţie externă fişierului, fie o referinţă de notaţie. În continuare sunt prezentate câteva variante pentru definire entităţi:

<!ENTITY % name "value"> <!ENTITY % name SYSTEM "systemId"> <!ENTITY name "value"> <!ENTITY name SYSTEM "systemId">

<!ENTITY name SYSTEM "systemId" NDATA nname>

<!—entitate parametru intern --> <!—entitate parametru extern --> <!—entitate internă generală --> <!—entitate externă-->

Entităţile parametru interne sunt utilizate pentru parametrizarea anumitor porţiuni ala DTD- ului. Entităţile parametru interne sunt întotdeauna parsuite. In continuare am prezentat câteva exemple:

1. definire internă:

<!DOCTYPE person [ <!ELEMENT person (name)> <!ENTITY % nameDecl "<!ELEMENT name (#PCDATA)>"> %nameDecl;

]> <person><name>Popescu Ioan</name></person>

2. definire externă

<!-- persoana.dtd --> <!ENTITY % person-content "name, age"> <!ELEMENT person (%person-content;)> <!ELEMENT name (#PCDATA)> <!ELEMENT age (#PCDATA)>

<!-- persoana1.xml --> <!DOCTYPE person SYSTEM "persoana.dtd"> <person> <name>Popescu Ioan</name>

<age>36</age>

</person>

<!-- persoana2.xml --> <!DOCTYPE person SYSTEM "person.dtd" [ <!—schimbă person-content --> <!ENTITY % person-content "age, name">

]> <person>

<age>25</age>

<name>Popescu George</name> </person>

Pentru o entitate parametru externă putem da exemplul următor:

<!-- person-decls.dtd --> <!ELEMENT person (name, age)> <!ELEMENT name (#PCDATA)> <!ELEMENT age (#PCDATA)>

<!-- person.xml --> <!DOCTYPE person [ <!ENTITY % decls SYSTEM "person-decls.dtd"> %decls;

]> <person> <name>Ionescu George</name>

<age>30</age>

</person>

In acest exemplu utilizăm entitatea externă decls.

Declaraţia NOTATION

O notaţie este orice lucru care nu poate fi înţeles şi analizat de un procesor XML (notaţiile se

mai numesc şi entităţi neanalizate). Cu toate că aceasta evocă ideea de date binare, notaţia

poate fi şi un text care nu este înţeles de XML. Un fragment de JavaScript, de exemplu, poate

fi păstrat într-un fişier extern şi să fie referit ca o notaţie.

Notaţiile pot referi doar fişiere externe. Nu există nici o metodă de a ascunde informaţii în interiorul unui document şi a le transfera unui agent utilizator pentru o prelucrare

specială, decât dacă le puneţi în interiorul unei etichete XML şi instruiţi agentul să facă ceva cu conţinutul etichetei. Dacă doriţi să includeţi în document date de tip text conţinând caractere speciale, ar trebui să le treceţi în interiorul unui element CDATA. Problema cu notaţiile este că ele necesită acces la DTD pentru a putea fi utilizate. Sintaxa NOTATION este simplă:

<! NOTATION nume identificator “asistent” >

Identificatorul este o intrare din catalog, aşa cum se utilizează în SGML. Multe procesoare XML sunt procesoare SGML reciclate, deci suportă un catalog în mod prestabilit. Este un pic mai sigur decât indicarea spre o aplicaţie de asistenţă care este posibil să nu se găsească în acel loc, dar XML cere ca aplicaţia de asistenţă să fie totuşi referită, fapt care poate duce la comportamente contradictorii. Puteţi să referiţi Adobe Photoshop, de exemplu, ca aplicaţie de asistenţă pentru realizarea unei imagini GIF, dar este foarte probabil că browserul ştie şi singur să afişeze GIF-uri. De asemenea, este mult mai probabil că browserul este capabil să integreze corect imaginea în documentul redat pe un dispozitiv de afişare sau

la imprimantă, o operaţie pe care Adobe Photoshop nu prea poate să o facă. Utilizarea atât a

identificatorului cât şi a “numelui” asistentului vă permite să faceţi un compromis între comunicarea către agentul utilizator a tipului de fişier care va fi transferat şi comunicarea

explicită a modului de afişare a fişierului, neştiind nimic despre mediul în care va fi afişat documentul. O conduită mai sigură este să introduceţi atât întreaga intrare din catalog, cât şi secvenţa identificatorului. Această metodă oferă o sugestie mai puternică, despre ce poate fi făcut cu acest fişier, aplicaţiei care va lucra cu fişierul XML prelucrat, dar nu prelucrează efectiv referinţa notaţiei. Identificatorul sistem “gif” funcţionează pe sisteme Windows, deoarece Windows cunoaşte GIF-urile. Dar un dispozitiv portabil sau chiar un calculator care utilizează un alt sistem de operare este posibil să nu aibă la îndemână informaţii despre manevrarea imaginilor GIF. Deci ar fi mai bine să refaceţi referinţa prezentată anterior, astfel:

<!NOTATION gif89a PUBLIC “-//CompuServe//NOTATION Graphics Interchange Format 89a//EN” “gif” >

Notaţiile nu pot fi folosite izolat. Ele trebuie declarate şi într-o entitate. O secvenţă de declaraţii completă poate arăta astfel:

<!NOTATION gif89a PUBLIC “-//CompuServe//NOTATION Graphics Interchange Format 89a//EN” “gif” > <!ENTITY gif89a SYSTEM “gif89a.gif” NDATA gif89a> <!ELEMENT image EMPTY> <!ATTLIST image source CDATA #REQUIRED

3.2 XML Schema

alt

CDATA #IMPLIED

type

NDATA gif89a>

XML Schema a inceput ca o initiativa a companiei Microsoft. Intre timp insa, consortiul W3C a preluat aceasta initiativa si a dezvoltat un set mai larg de cerinţe şi caracteristici pentru documente care descriu tipuri de documente. Acestea sunt reunite sub numele de Document Content Description şi informatii despre acest proiect sunt disponibile la http://w3.org/TR/NOTE-dcd. XML Schema a devenit o recomandare W3C pe data de 02 Mai 2001. Spre deosebire de (sau în plus faţă de) DTD-uri, XML Schema permite definirea regulilor şi relaţiilor între elemente şi atribute folosind un fisier XML (cu alte cuvinte, o schemă XML este descrisă într-un fisier XML). In plus, se adaugă support pentru spaţii de nume (namespaces), tipuri de date şi caracteristici mai avansate cum ar fi constrângerile (constraints). XML Schema este o alternativa la DTD care este bazată pe standardul XML. Ca şi DTD, XML Schema este folosită pentru a descrie structura documentelor XML. Acest standard mai este cunoscut si sub numele de XML Schema Definition (XSD).

XML Schema vs. DTD Incă de la primele utilizări ale XML-ului în aplicaţii, a devenit evident că adeseori definirea tipurilor de documente folosind fişiere DTD are câteva neajunsuri, dintre care enumerăm:

limbajul DTD foloseşte o altă sintaxa nu cea de XML Schema ceea ce presupune ca utilizatorii să înveţe două “limbaje” (deşi nici unul nu este dificil) şi aplicaţiile care folosesc validarea DTD să conţină componente separate de procesare a DTD-urilor;

sintaxa DTD este relativ restrânsă. In cadrul DTD ar fi dificil, de exemplu, să declarăm un tip de document XML care conţine rapoarte organizate pe luni şi zile. Astfel, o regulă evidentă ar fi că un element luna ar trebui sa conţină între 28 şi 31 de elemente de tip zi, lucru care se poate specifica în DTD înşiruind de 28 de ori zi şi apoi definindu-le pe restul ca fiind opţionale. Un alt exemplu este acela de verificare a corectitudinii structurii CNP-urilor (numere alcatuite din 13 cifre). XML Schema face ca astfel de structuri să poată fi definite mult mai uşor;

DTD-urile au o capacitate foarte limitată de tipuri de date (suportă doar 10 tipuri de date). Pentru a exemplifica, în DTD nu putem spune că un atribut este de tip intreg pozitiv, ci doar il putem defini ca şir de caractere, identificator sau fragment de nume;

DTD-urile suportă atribute identificatori şi referinţe către aceştia (ID şi IDREF). Nu se pot însă trasa relaţii clare cum ar fi: atributul zi_ref este o referinţă către un atribut de tip identificator din elementul zi.

DTD-urile nu suportă spaţii de nume (namespaces).

Aceste neajunsuri au condus la apariţia XML Schema care prezintă următoarele avantaje:

sunt scrise folosind aceeasi sintaxa ca şi fisierele pe care le descrie, ceea ce presupune mai puţină sintaxă de memorat;

suportă peste 44 de tipuri de date şi permite, de asemenea, definirea propriilor tipuri de date;

sunt orientate pe obiecte (se poate restricţiona sau extinde un anumit tip, derivând un nou tip pe baza unuia vechi);

se pot defini mai multe elemente care să aibă acelaşi nume dar conţinut diferit;

suportă spaţii de nume (namespaces);

sunt extensibile ceea ce permite utilizarea unei Scheme în cadrul alteia, se pot referi mai multe scheme în cadrul aceluiaşi document şi se pot crea tipuri de date proprii derivate din tipurile standard.

Sintaxă Pentru o mai uşoară înţelegere a XML Schema, vom utiliza un document XML pe care vom arăta cum se defineşte şi utilizează o Schemă:

<?xml version="1.0"?> <student> <nume>Popescu</nume> <prenume>Ioan</prenume> <adresa>Timisoara</adresa>

<grupa>3.1</grupa>

</student> Pentru a putea referi o XML Schema într-un document XML se adaugă câteva atribute elementului rădăcină a documentului:

<student xmlns="http://www.aut.upt.ro/"

xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"

xs:schemaLocation="http://www.aut.upt.ro/ student.xsd">

Aceste atribute au următoarea semnificaţie:

xmlns="http://www.aut.upt.ro/" – defineşte namespace-ul default, specificând validatorului că toate elementele folosite în documentul XML sunt declarate în spaţiul de nume de la adresa respectivă;

xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" – instanţa Schemei utilizate pentru respectivul namespace;

xs:schemaLocation="http://www.aut.upt.ro/ student.xsd" – defineşte namespace-ul

utilizat (http://www.aut.upt.ro/) şi locaţia XML Schemei ce va fi folosită pentru spaţiul de nume respectiv (student.xsd) Orice XML Schema are ca rădăcină elementul <schema> care poate să conţină nişte atribute:

<?xml version="1.0"?> <xs:schema

xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.aut.upt.ro/"

xmlns="http://www.aut.upt.ro/"

elementFormDefault="qualified">

</xs:schema>

Aceste atribute au următoarea semnificaţie:

xmlns:xs="http://www.w3.org/2001/XMLSchema" – indică faptul că elementele şi tipurile de date utilizate în Schema provin din spaţiul de nume definit la adresa respectivă. Totodată, se menţionează şi faptul că pentru a folosi elementele şi tipurile de date din acest spaţiu de nume, ele trebuiesc prefixate cu xs;

targetNamespace="http://www.aut.upt.ro/" – indică faptul că elementele definite de această Schema (student, nume, prenume, adresă, grupă) provin din spaţiul de nume de la adresa respectivă;

xmlns="http://www.aut.upt.ro/" – indică faptul că spaţiul de nume implicit e cel de la adresa specificată;

elementFormDefault="qualified" – indică faptul că fiecare element utilizat în documentul XML şi care a fost definit în Schema trebuie să fie calificat de spaţiul de nume respectiv.

Spaţiul de nume implicit este cel care nu are asociat nici un sufix.

In continuare vom prezenta întreaga schemă a documentului XML definit mai sus şi vom continua discuţia pe baza acestei scheme:

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.aut.upt.ro/" xmlns="http://www.aut.upt.ro/" elementFormDefault="qualified"> <xs:element name="student"> <xs:complexType> <xs:sequence> <xs:element name="nume" type="xs:string"/> <xs:element name="prenume" type="xs:string"/> <xs:element name="adresa" type="xs:string"/> <xs:element name="grupa" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

Elementul student este definit ca având un tip complex deoarece conţine alte elemente. Celelalte elemente (nume, prenume, adresă, grupă) au tipul simplu pentru că nu conţin alte elemente în interiorul lor. Acestea pot conţine numai text în interiorul lor, dar acest text poate fi de unul dintre tipurile existente în XML Schema sau poate fi de un tip definit de utilizator şi i se pot impune anumite restricţii sau se poate specifica faptul că datele trebuie să respecte un anumit pattern. Definirea elementelor simple se face folosind structura:

<element name="nume_element" type="tip_element"/>

In cazul în care spaţiul de nume implicit este “http://www.w3.org/2001/XMLSchema” sau <xs: element name="xxx" type="yyy"/> în cazul în care acest spaţiu de nume este definit ca în schema de mai sus. Nume_element este numele elementului din documentul XML iar tip_element poate fi unul dintre tipurile definite în XML Schema (ex: string, decimal, integer, boolean, date, time). Dacă “http://www.w3.org/2001/XMLSchema” nu este spaţiul de nume implicit, tipurile de date trebuiesc prefixate cu prefixul specific acestui spaţiu de nume (ex: xs:string, xs:decimal, xs:integer, xs:boolean, xs:date, xs:time). Elementele pot avea valori implicite sau fixate:

<xs:element name="color" type="xs:string" default="red"/> <xs:element name="color" type="xs:string" fixed="red"/>

In primul caz, dacă lipseşte conţinutul elementului, acesta va fi adăugat automat ca fiind “red”. In cel de-al doilea caz, dacă există conţinutul şi este diferit de “red”, se va furniza o eroare, iar dacă nu există, se va adăuga automat ca fiind “red”. Elementele simple nu pot să

conţină elemente. Dacă un element are atribute, atunci acesta trebuie să fie definit ca un element complex. In schimb, atributele sunt tot timpul definite ca fiind atribute simple.

aceleaşi

Definirea

semnificaţii:

atributelor

se

face

similar

cu

definirea

elementelor

simple,

având

<attribute name="nume_atribut" type="tip_atribut"/>

De asemenea, se pot asocia valori implicite sau fixate:

<xs:attribute name="lang" type="xs:string" default="EN"/> <xs:attribute name="lang" type="xs:string" fixed="EN"/>

In plus faţă de elemente, se poate specifica şi dacă respectivul atribut poate sau nu să lipsească. In mod implicit, atributul este opţional, adică atributul poate sa lipsească. Pentru a specifica faptul că atributul este obligatoriu, se adaugă atributul use:

<xs:attribute name="lang" type="xs:string" use="required"/>

In momentul în care se specifică un anumit tip de date pentru un element sau pentru un atribut din XML, se impune o restricţie asupra conţinutului acestuia (de exemplu, dacă tipul este „date”, se va genera o eroare în momentul în care se găseşte informaţia „Hello”). De asemenea, se pot adăuga restricţii suplimentare asupra elementelor sau atributelor, restricţii care se numesc faţete (facets). Restricţiile sunt folosite pentru a defini forme acceptate pentru elementele şi atributele XML. Restricţiile pot fi de mai multe feluri:

restricţii asupra valorilor conţinute în interiorul tagurilor. In tabel sunt reprezentate 2 exemple echivalente din punct de vedere ar definirii elementului de tip varsta. Se impune ca acesta să aibă valorile cuprinse între 0 şi 80. In cazul celei de-a doua forme, tipul „tip_v” poate fi refolosit în cadrul altor elemente sau extins/restricţionat, deoarece nu este o parte a elementului varsta ca în primul caz:

Folosind tipuri implicite

Folosind tipuri explicite

<xs:element name="varsta"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="80"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="varsta" type="tip_v"> <xs:simpleType name="tip_v"> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="80"/> </xs:restriction> </xs:simpleType> </xs:element>

restricţii asupra seturilor de valori posibile în interiorul tagurilor. In tabelul de mai jos sunt reprezentate cazurile în care elemental de tip vârstă poate lua doar valorile 20, 30, 40. Diferenţa dintre tipurile implicite şi cele explicite este aceiaşi:

Folosind tipuri implicite

Folosind tipuri explicite

<xs:element name="varsta">

<xs:element name="varsta" type="tip_v">

<xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="20"/> <xs:enumeration value="30"/> <xs:enumeration value="40"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:simpleType name="tip_v"> <xs:restriction base="xs:string"> <xs:enumeration value="20"/> <xs:enumeration value="30"/> <xs:enumeration value="40"/> </xs:restriction> </xs:simpleType> </xs:element>

restrictii asupra seriilor de valori – folosind şabloane

Folosind tipuri implicite

Folosind tipuri explicite

<xs:element name="cifra"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:pattern value="[0-9]"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="cifra" type="tip_c"> <xs:simpleType name="tip_c"> <xs:restriction base="xs:integer"> <xs:pattern value="[0-9]"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="numar"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:pattern value="0|[1-9]([0-9])*"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="numar" type="tip_n"> <xs:simpleType name="tip_n"> <xs:restriction base="xs:integer"> <xs:pattern value="[1-9]([0-9])*"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="CNP"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:pattern value="(1|2)[0-9]{12}"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="CNP" type="tip_cnp"> <xs:simpleType name="tip_cnp"> <xs:restriction base="xs:integer"> <xs:pattern value="(1|2)[0-9]{12}"/> </xs:restriction> </xs:simpleType> </xs:element>

restricţii asupra caracterelor „whitespace” – pentru a specifica modul în care sunt interpretate caracterele “whitespace” se foloseste restrictia whiteSpace. Aceasta poate lua 3 valori posibile: preserve, replace si collapse. In primul caz, caracterele whitespace (line feed, tab, space, si carriage return) sunt afişate aşa cum sunt întâlnite. In cazul replace, acestea sunt inlocuite cu spaţii, iar în ultimul caz caracterele whitespace sunt inlocuite cu un singur caracter spatiu.

Preserve

Replace

Collapse

<xs:element name = "address" > <xs:simpleType> <xs:restriction base = "xs:

<xs:element name= "address" > <xs:simpleType> <xs:restriction base= "xs:string">

<xs:element name= "address"> <xs:simpleType> <xs:restriction base= "xs:string">

string">

<xs:whiteSpace value= "preserve"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:whiteSpace value= "replace"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:whiteSpace

value=

"collapse"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

restricţii supra lungimii – pentru a limita lungimea valorii conţinutului unui element, se vor folosi restricţiile: length, maxLength, si minLength. In cazul restricţiei length, lungimea conţinutului este exact cea specificată de valoarea dată lui length. In cazul maxLength/minLength, lungimea conţinutului textului trebuie să fie mai mare/mică decât valoarea specificată.

Sintaxa

Explicaţie

<xs:element name="password"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="8"/> </xs:restriction> </xs:simpleType> </xs:element>

cămpul “password” trebuie să aibă exact 8 caractere

<xs:element name="password"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="5"/> <xs:maxLength value="8"/> </xs:restriction> </xs:simpleType> </xs:element>

câmpul “password” trebuie să aibă între 5 şi 8 caractere

restricţii pentru tipurile de date:

Constrângere

Descriere

enumeration

defineşte o listă de valori ce pot fi acceptate

fractionDigits

specifică numărul maxim de decimale permise. Trebuie sa fie mai mare sau egal cu zero

length

specifică numărul exact de caractere sau de itemuri dintr-o lista. Trebuie să fie mai mare sau egal cu zero.

maxExclusive

specifică limita superioară pentru valorile numerice. Valoarea trebuie să fie strict mai mică decât valoarea specificată astfel.

maxInclusive

specifica limita superioara pentru valorile numerice. Valoarea trebuie sa fie mai mică sau egala cu valoarea specificată astfel.

maxLength

specifică numărul maxim de caractere sau de itemuri dintr-o listă. Trebuie să fie mai mare sau egal cu zero.

minExclusive

specifică limita inferioară pentru valorile numerice. Valoarea trebuie să fie strict mai

 

mare decat valoarea specificată astfel.

 

minInclusive

specifică limita inferioară pentru valorile numerice. Valoarea trebuie să fie mai mare sau egală cu valoarea specificată astfel.

minLength

specifică numărul minim de caractere sau de itemuri dintr-o listă. Trebuie să fie mai mare sau egal cu zero.

pattern

specifică un pattern pe care trebuie să îl respecte datele respective

totalDigits

specifică numărul exact de digiţi permişi. Trebuie să fie mai mare sau egal cu zero

whiteSpace

specifică

felul

în

care

sunt

tratate

whitespaceurile

 

Inainte de a arăta cum se definesc elemente complexe trebuie mai întâi să specificăm ce sunt acestea. Un element complex este un element complex care conţine alte elemente sau/şi atribute. Sunt 4 tipuri de elemente complexe şi oricare din aceste tipuri poate să aibă şi atribute:

elemente ce conţin numai alte elemente în interiorul lor – au numai copii, fără text (ex:

<employee><firstname>Ioan</firstname><lastname>Popescu</lastname></emplo yee>)

elemente vide – ce nu conţin nimic în interiorul lor (ex: <product pid="123"/>)

elemente

care

conţin

în

interiorul

lor

numai

text

(ex:

<mâncare

tip="desert">tort</mancare>)

elemente mixte – care conţin în interiorul lor atât elemente cât şi text (ex:

<scrisoare>Stimate Domnule<nume>Ion</nume>, Scrisoarea dumneavoastra din data de <data>25 martie</data> va ajunge pe data <data>30 martie</data>.</scrisoare>)

Definirea elementelor complexe:

elemente ce au doar copii in componenţa lor

Folosind tipuri implicite

Folosind tipuri explicite

Explicatie

<xs:element

<xs:element

Se specifica faptul că elementul employee are doar doi copii (firstname şi lastname) care trebuie să apară strict în această ordine datorită indicatorului <xs:sequence>. Folosirea tipului implicit îl face inutilizat în altă parte spre deosebire de folosirea tipurilor explicite care permite refolosirea acestuia precum şi crearea de noi elemente complexe pe baza acestuia

name="employee">

name="employee"

<xs:complexType>

type="personinfo"/>

<xs:sequence>

<xs:complexType

<xs:element

name="personinfo">

name="firstname"

<xs:sequence>

type="xs:string"/>

<xs:element

<xs:element

name="firstname"

name="lastname"

type="xs:string"/>

type="xs:string"/>

<xs:element

</xs:sequence>

name="lastname"

</xs:complexType>

type="xs:string"/>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

Exemplu de refolosire si extindere a tipului explicit „personinfo”: Sintax ă   Explica ţ ie
Exemplu de refolosire si extindere a tipului explicit „personinfo”: Sintax ă   Explica ţ ie
Exemplu de refolosire si extindere a tipului explicit „personinfo”: Sintax ă   Explica ţ ie

Exemplu de refolosire si extindere a tipului explicit „personinfo”:

Sintaxă

 

Explicaţie

<xs:element name="employee" type= "personinfo" /> <xs:element name="student" type="personinfo"/> <xs:element name="member" type="personinfo"/> <xs:complexType name="fullpersoninfo"> <xs:complexContent> <xs:extension base="personinfo"> <xs:sequence>

Tipul personinfo este utilizat atât la definirea elementului employee cât şi la definirea elementelor student şi member. In acest fel s-a definit tipul fullpersoninfo care are un conţinut complex (<xs:complexContent>) şi porneşte de la tipul personinfo extinzându-l (<xs:extension base="personinfo">) cu o secvenţă de alte elemente (<xs:sequence>… </xs:sequence>)

 

<xs:element

name="address"

type="xs:string

"/>

 

<xs:element name="city" type="xs:string"/> <xs:element name="country" type="xs:string"

/>

 

</xs:sequence>

</xs:extension>

 

</xs:complexContent>

 

</xs:complexType>

 

elemente vide (ex: <product pid="1345"/>) – pentru a defini un tip vid, trebuie să definim un tip care să conţină numai elemente in interiorul sau, dar caruia sa nu ii adaugam, de fapt, nici un element. Astfel, el este definit ca fiind un tip complex, cu un conţinut complex, ceea ce arată faptul că intenţionăm să extindem sau să restrângem conţinutul unui element de tip complex.

Sintaxa

Sintaxa simplificata

Sintaxa simplificată folosind tipuri explicite

<xs:element

<xs:element

name=

<xs:element name="product" type="prodtype"/> <xs:complexType name="prodtype"> <xs:attribute "prodid"type= "xs:positiveInteger"/> </xs:complexType>

name=

name="product">

"product">

<xs:complexType>

<xs:complexType>

<xs:complexContent>

<xs:attribute

name=

<xs:restriction

"prodid"type=

base="xs:integer">

"xs:positiveInteger"/>

<xs:attribute

name=

</xs:complexType>

"prodid"type=

</xs:element>

"xs:positiveInteger"/>

 

</xs:restriction>

</xs:complexContent>

</xs:complexType>

</xs:element>

text (ex: <mancare

elemente

tip="desert">tort</mancare>) – acest tip conţine numai text simplu (text sau/şi

care

conţin

în

interiorul

lor

numai

atribute). Pentru a defini un astfel de tip, se foloseşte „simpleContent” şi trebuie utilizată o extensie sau o restricţie.

elemente mixte;

Sunt şapte indicatori grupaţi în 3 categorii:

indicatori de ordine (Order indicators): all, choice, sequence – sunt utilizaţi pentru a specifica ordinea elementelor: All – toţi copii trebuie să apară o singura dată în cadrul elementului parinte, dar pot apărea în orice ordine; choice – orice copil poate sa apară în cadrul elementului parinte; sequence – toţi copiii trebuie să apară în cadrul elementului părinte în ordinea specificată:

All

Choice

Sequence

<xs:element name="person"> <xs:complexType> <xs:all> <xs:element name= "firstname"type= "xs:string"/> <xs:element name= "lastname" type= "xs:string"/> </xs:all> </xs:complexType> </xs:element>

<xs:element name="person"> <xs:complexType> <xs:choice> <xs:element name= "employee" type= "employee"/> <xs:element name= "member" type= "member"/> </xs:choice> </xs:complexType> </xs:element>

<xs:element name= "person"> <xs:complexType> <xs:sequence> <xs:element name= "firstname" type= "xs:string"/> <xs:element name= "lastname" type= "xs:string"/> </xs:sequence> </xs:complexType> </xs:element>

indicatori de apariţie (Occurrence indicators): maxOccurs, minOccurs – sunt utilizaţi pentru a specifica de câte ori poate să apară un element copil în cadrul părintelui său:

maxOccurs – specifică numărul maxim de apariţii a respectivului element, minOccurs – specifică numărul minim de apariţii a respectivului element:

Sintaxa

Explicatie

<xs:element name="persoana"> <xs:complexType> <xs:sequence> <xs:element name="liceu" type="xs:string"/> <xs:element name="facultate" type="xs:string" maxOccurs="5"

Sintaxa defineşte un element „persoana” care are 2 tipuri de copii: un copil „liceu” </xs:sequence> </xs:complexType> </xs:element> şi un copil „facultate” care poate să apară de un număr de ori cuprins între 0 şi 5

minOccurs="0"/>

Observaţii:

1) Pentru toti ceilalti indicatori (de ordine sau de grup), valorile implicite pentru maxOccurs si minOccurs sunt 1. 2) Pentru a permite unui element să apară de oricâte ori, se foloseşte maxOccurs=”unbounded”.

indicatori de grup (Group indicators): Group name, attributeGroup name – folosite pentru a defini grupuri de elemente/atribute inrudite

In interiorul

grupului trebuie definit unul din indicatorii de ordine. După definirea grupului, acesta poate fi referit în altă structură:

Group name – se defineşte folosind <group name="groupname">

</group>.

Definirea unui grup de elemente

Referirea acestui grup in alt element

<xs:group name="persongroup"> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> <xs:element name="birthday" type="xs:date"/> </xs:sequence> </xs:group>

<xs:element name="person" type="personinfo"/> <xs:complexType name="personinfo"> <xs:sequence> <xs:group ref="persongroup"/> <xs:element name="country" type="xs:string"/> </xs:sequence> </xs:complexType>

Pentru a permite extinderea schemelor XML, sintaxa permite folosirea unor elemente de tip whildcard (<any> si <anyAttribute>) ce permit îmbogăţirea schemelor cu elemente/atribute a căror definiţie nu este dată în schema respectivă.

<xs:element name="person"> <xs:complexType> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> <xs:any minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>

Prin folosirea elementului any, conţinutul elementului „person” poate fi extins cu un alt element, care poate să nu fie declarat în schema curenta. Astfel, dacă se declară un element „child” într-o altă schema şi apoi se specifică în documentul XML că se vor folosi ambele scheme, atunci elementul person poate să conţină ca şi copil şi elemental „child” şi astfel documentul XML sa fie valid. In unele cazuri, se doreşte ca în documentul XML să existe alternative. De exemplu, se poate defini un element adresa în care unul dintre câmpuri să fie judeţul, pentru locuitorii din provincie sau sectorul pentru locuitorii din capitala. Pentru astfel de situaţii, XML Schema pune la dispoziţie atributul substitutionGroup. Astfel se pot defini două elemente în care unul să fie un substitut pentru celălalt:

<xs:element name="judet" type="xs:string"/> <xs:element name="sector" substitutionGroup="judet"/>

Astfel, dacă avem o XML Schema care defineşte o adresă în felul următor:

<xs:element name="judet" type="xs:string"/> <xs:element name="sector" substitutionGroup="judet"/> <xs:complexType name="adresa"> <xs:sequence> <xs:element ref="judet"/> </xs:sequence> </xs:complexType>

atunci, următorul document XML este valid:

<adress book> <adresa><judet>Timis</judet></adresa> <adresa><sector>unu</sector></adresa> </adress book>

Observatii:

1) Tipul elementelor care se doresc a substitui trebuie sa fie acelaşi sau, în cel mai rău caz, derivate din tipul de bază (care se doreşte a putea fi substituit). Dacă tipul este acelaşi, atunci nu mai este nevoie să fie definit tipul elementelor care vor substitui elementul de bază; 2) Pentru a putea folosi substituirea este necesar ca elementele implicate în aceasta să fie declarate global (adică să fie copii direcţi ai elementului „schema”) 3) Este posibilă împiedicarea încercării de substituţie, prin folosirea atributului block care trebuie să aibă valoarea "substitution". Astfel, dacă în exemplul de mai sus, elementului judeţ i se asociază block="substitution", atunci documentul XML nu mai e valid:

<xs:element name="judet" type="xs:string" block="substitution"/>

In prezent, există o serie de unelte dezvoltate pentru XML Schema: XMLSpy/Altova, Stylus Studio 2007, oXygen XML, Xerces-C++ 2.8.0, xnsdoc 1.2 - XML Schema documentation generator şamd. O listă mai completă se gaseşte la adresa: http://www.w3.org/XML/Schema. In general, aceste instrumente oferă posibilitatea validării Schemei XML, validarea documentului XML cu Schema asociata, generarea automată a XML Schema pe baza unui XML, precum şi conversia DTD-urilor în XML Schema.

In figurile următoare sunt reprezentate principalele tipuri de date utilizate în XML Schema:

Figura 3.3 Ierarhia tipurilor string în XML Schema Figura 3.4. Ierarhia tipurilor numerice în XML

Figura 3.3 Ierarhia tipurilor string în XML Schema

Figura 3.3 Ierarhia tipurilor string în XML Schema Figura 3.4. Ierarhia tipurilor numerice în XML Schema

Figura 3.4. Ierarhia tipurilor numerice în XML Schema

3.3 Procesarea documentului XML

Procesarea reprezintă procesul prin care o aplicaţie interpretează informaţiile conţinute de un document XML. Pentru a putea procesa un document, o aplicaţie trebuie mai întâi să îl poată analiza. Analiza este un proces care implică împărţirea textului unui document XML în porţiuni mici de identificatori, numite noduri. Nodurile pot fi etichete, atribute, comentarii, text ¸samd. Acestea sunt transmise aplicaţiei prin intermediul unui API predefinit. Există patru modele de analiză utilizate în mod normal:

Pull Parsing (Analiză prin tragere). Aplicaţia are ca rol extragerea, pe rând, a fiecărui element din documentul XML. Incă nu este definit un API standard pentru acest model de analiză.

Push Parsing (Analiză prin împingere). Analizorul trimite notificări aplicaţiei despre tipurile de noduri pe care le întâlneşte în procesul de analiză. Standardul de facto pentru acest tip de analiză este denumit SAX (Simple API for XML) .

One Step Parsing (Analiză într-un pas). Analizorul citeşte întregul document XML şi generează o structură de date (arbore de analiză) care descrie întregul lui conţinut. Standardul utilizat pentru acest model de analiză este DOM (Document Object Model). De asemenea se lucrează la particularizarea API-ului DOM pentru Java (JDOM).

Hybrid Parsing (Analiză hibridă). Acest tip de analiza combină tehnologiile prezentate

mai sus pentru a optimiza, pentru anumite cazuri particulare, accesul la informaţia conţinută în documentul XML. Nu există o tehnologie optimă pentru procesare. Totul se rezumă la a alege tipul de analiză optimă în funcţie de problema ce trebuie rezolvată. Astfel, dacă este vorba de procesarea unui

document în timp cât mai scurt şi cu resurse minime de memorie, API-ul SAX este recomandat. In cazul procesării complexe a unui document, necesitând posibilitatea de navigare printre noduri, este recomandată folosirea API-ului DOM.

3.4. SOAP