Lenguajes de Marcas

Informàtica i comunicacions
Llenguatges de marques i
sistemes de gestió
d’informació
CFGS.INF.M04/0.12
Administració de sistemes informàtics en xarxa

Desenvolupament d’aplicacions multiplataforma
Desenvolupament d’aplicacions web
Aquesta col·lecció ha estat dissenyada i coordinada des de l’Institut Obert de Catalunya.
Coordinació de continguts
Carles Martí
Redacció de continguts
Xavier Sala
Primera edició: febrer 2012

© Departament d’Ensenyament
Material realitzat per Eureca Media, SL
Dipòsit legal: DL B 25957-2016
Llicenciat Creative Commons BY-NC-SA. (Reconeixement-No comercial-Compartir amb la mateixa llicència 3.0 Espanya).
Podeu veure el text legal complet a
http://creativecommons.org/licenses/by-nc-sa/3.0/es/legalcode.ca
Desenvolupament d’aplicacions web 5 Llenguatges de marques i sistemes de gestió d’informació
Introducció
Aquest mòdul comporta una aproximació als llenguatges de marques, amb es-
pecial incidència en l’XML (acrònim de l’expressió anglesa eXtensible Markup
Language, que podríem traduir com ‘llenguatge de marques extensible’), i també
en altres tecnologies íntimament relacionades amb aquell.
Necessàriament, doncs, la unitat “Llenguatges de marques” proporciona una
introducció als diferents llenguatges de marques, n’ofereix una classificació i
mostra com ha de ser l’estructura d’un document XML ben format.
En definitiva, l’XML és un llenguatge d’etiquetes (com ara l’HTML), desen-
volupat pel World Wide Web Consortium (W3C). Però, a diferència d’altres
llenguatges de marques, l’XML té una potencialitat que li permet definir la
gramàtica d’altres llenguatges específics. Per tant, l’XML no és realment un
llenguatge en particular, sinó una manera de definir llenguatges per a diferents
necessitats.
Per tant, la unitat “Transmissió d’informació a través del Web. Mecanismes
de validació de documents XML” desenvolupa els mecanismes de transmissió
d’informació a través del Web, tot incloent-hi la definició d’esquemes i vocabularis
en XML.
Ara bé, l’XML no ha nascut només per aplicar-lo a Internet, sinó que es proposa
com a estàndard per a l’intercanvi d’informació estructurada entre diferents
plataformes. Es pot utilitzar per a bases de dades, editors de text, fulls de càlcul i
per a moltes altres aplicacions diverses.
Per aquesta raó, la unitat “Àmbits d’aplicació de l’XML” examina diferents possi-
bilitats d’utilització de l’XML, tenint en compte la sindicació de continguts, fent
referència als mètodes de conversió i adaptació de documents XML, i abordant les
bases de dades natives XML i el seu llenguatge de consultes específic, l’XQuery.
Cal dir que l’XML és una tecnologia relativament senzilla que en té entorn
seu d’altres que la complementen i la fan notablement més extensa, a més
de proporcionar-li unes possibilitats molt més grans. Actualment té un paper
molt important, ja que permet la compatibilitat entre sistemes, i fa així possible
compartir informació d’una manera segura, fiable i senzilla.
En conseqüència, la unitat “Sistemes de gestió empresarial” aborda la temàtica
corresponent als sistemes empresarials de gestió d’informació, fent incidència
especial en el programari de gestió integrada, també conegut com a ERP (sigles
de l’expressió anglesa enterprise resource planning), sense oblidar-se de dues
tecnologies de forta implantació: els serveis web i la informàtica en el núvol.
Resultats d’aprenentatge
En acabar aquest mòdul, l’alumne:
• Reconeix les característiques de llenguatges de marques analitzant i inter-

pretant fragments de codi.
• Utilitza llenguatges de marques per a la transmissió d’informació a través

del web analitzant l’estructura dels documents i identificant els seus ele-
ments.
• Estableix mecanismes de validació per a documents XML utilitzant mèto-

des per definir la seva sintaxi i estructura.
• Genera canals de continguts analitzant i utilitzant tecnologies de sindicació.
• Realitza conversions sobre documents XML utilitzant tècniques i eines de

processament.
• Gestiona informació en format XML analitzant i utilitzant tecnologies

d’emmagatzematge i llenguatges de consulta.
• Treballa amb sistemes empresarials de gestió d’informació realitzant tas-

ques d’importació, integració, assegurament i extracció de la informació.
Continguts
Programació amb XML
Unitat 1
Llenguatges de marques
1. Introducció als llenguatges de marques. Classificació.
2. Documents XML
Unitat 2
Transmissió d’informació per mitjà del web. Mecanismes de validació de docu-
ments XML
1. Utilització dels llenguatges de marques en entorns web
2. Definició d’esquemes i vocabularis en XML
Àmbits d’aplicació de l’XML
Unitat 3
Àmbits d’aplicació de l’XML
1. Sindicació de continguts
2. Conversió i adaptació de documents XML
3. Bases de dades natives XML. Llenguatge de consultes (XQuery)
Sistemes de gestió empresarial
Unitat 4
Sistemes de gestió empresarial
1. Sistemes empresarials de gestió d’informació
2. Serveis Web
3. Informàtica en núvol
Llenguatges de marques
Xavier Sala
Llenguatges de marques i sistemes de gestió

d’informació
Llenguatges de marques i sistemes de gestió d’informació Llenguatges de marques
Índex
Introducció 5
Resultats d’aprenentatge 7
1 Introducció als llenguatges de marques. Classificació 9

1.1 Les dades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Característiques de les dades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Emmagatzematge de dades en ordinadors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 Dades binàries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.2 Dades de text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Fitxers de marques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3.1 Les marques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.2 Característiques dels llenguatges de marques . . . . . . . . . . . . . . . . . . . . . . 26
1.3.3 Classificació dels llenguatges de marques . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.4 Història . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2 Documents XML 37
2.1 Metallenguatge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2 Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.1 Etiquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.2 Contingut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.3 Atributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.4 Noms vàlids XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2.5 Comentaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.6 Instruccions de procés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.3 Declaració XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.1 Atributs de la declaració XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.4 Correctesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.4.1 Només hi pot haver un element arrel . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.4.2 Totes les etiquetes que s’obren s’han de tancar . . . . . . . . . . . . . . . . . . . . . . 54
2.4.3 Les etiquetes han d’estar imbricades correctament . . . . . . . . . . . . . . . . . . . 55
2.4.4 Els noms de les etiquetes i dels atributs han de ser correctes . . . . . . . . . . . . . . 56
2.4.5 Els valors dels atributs han d’estar entre cometes . . . . . . . . . . . . . . . . . . . . 57
2.4.6 Processadors XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.5 Estructura dels documents XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.5.1 Representació en forma d’arbre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.5.2 Representació en els navegadors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.6 Creació de documents XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.6.1 Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.6.2 Creació d’un document XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.7 Espais de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Llenguatges de marques i sistemes de gestió d’informació 5 Llenguatges de marques
Introducció
Els llenguatges de marques estan en plena expansió. Recolzant-se en el gran èxit

que han representat les pàgines web han anat apareixent noves tecnologies basades
en llenguatges de marques que permeten als usuaris i als programes aconseguir
resultats amb els quals abans només es podia somiar.
Els nous llenguatges de marques intenten anar una mica més enllà de la simple
representació de dades que oferia HTML, i que eren ideals per a les persones, a
nous sistemes que puguin fer que els programes puguin recuperar la informació
que es troba en els ordinadors i processar-la de manera automàtica.
L’apartat “Introducció als llenguatges de marques. Classificació” mostra què són

els llenguatges de marques, quines són les seves característiques, quina evolució
han sofert i quins són els usos més importants.
L’apartat “Documents XML” entra en profunditat en el llenguatge XML i explica

què són i com es poden crear documents XML, com es pot fer per comprovar
que aquests documents són correctes, i s’hi veuen algunes eines per treballar amb
documents XML.
En acabar aquesta unitat l’alumne:
1. Reconeix les característiques de llenguatges de marques analitzant i inter-

pretant fragments de codi.
• Identifica les característiques generals dels llenguatges de marques.

• Reconeix els avantatges que proporcionen en el tractament de la
informació.
• Classifica els llenguatges de marques i identifica els més rellevants.
• Diferencia els àmbits d’aplicació dels llenguatges de marques.
• Reconeix la necessitat i els àmbits específics d’aplicació d’un llenguat-
ge de marques de propòsit general.
• Analitza les característiques pròpies del llenguatge XML.
• Identifica l’estructura d’un document XML i les seves regles sintàcti-
ques.
• Contrasta la necessitat de crear documents XML ben formats i la
influència pel que fa al processament.
• Identifica els avantatges que aporten els espais de noms.
1. Introducció als llenguatges de marques. Classificació
Una definició poc estricta del que és un ordinador podria ser que “és una màquina
electrònica que rep i processa dades per convertir-les en informació útil”.
Un dels components bàsics en un sistema informàtic són les dades que s’hi
puguin introduir i com ho fa aquest sistema per emmagatzemar-les per usar-
les posteriorment o mostrar-les de nou.
Per tant, una de les tasques bàsiques que fan els ordinadors és emmagatzemar la
informació que els proporcionem per poder ser processada posteriorment. Aques-
ta informació pot ser de molts tipus diferents (text, imatges, vídeos, música...)
però el realment important serà de quina manera l’emmagatzema l’ordinador per
poder-la tractar posteriorment de manera eficient per generar més informació.
1.1 Les dades
Les dades són representacions d’aspectes del món real i se solen recollir per fer
càlculs, mostrar-les, organitzar-les, etc., amb l’objectiu que posteriorment algú en
pugui fer alguna cosa: prendre decisions, generar noves dades...
Si no s’és gaire estricte es podria dir que en un sistema informàtic qualsevol les
úniques tasques que es desenvolupen consisteixen a emmagatzemar dades per
processar-les per mitjà d’un programa que o bé aportarà algun tipus d’informació
o bé es faran servir de nou per generar noves dades.
1.1.1 Característiques de les dades
Entre les característiques interessants sobre les dades en destaquen sobretot tres
aspectes:
• A qui van dirigides
• La possibilitat de reutilitzar-les
• Que es puguin compartir

Destinatari de dades
Si s’intenta ser una mica més pràctic es veurà que realment les dades tindran una
forma o una altra en funció del destinatari a qui vagin dirigides:
1. Dades destinades als humans: generalment les dades destinades al humans

requeriran que tinguin alguna estructura concreta, amb uns formats determi-
nats, amb textos decorats d’alguna manera. Hi apareixeran títols, caràcters
en negreta, etc. Generalment no cal conèixer quin significat tenen les dades,
ja que la interpretació es deixa al lector.
2. Dades destinades als programes: els programes generalment no necessi-

ten que les dades tinguin informació sobre com s’han de representar, sinó
que n’hi ha prou que siguin fàcilment identificables, que quedi clar de quin
tipus són i que hi hagi alguna manera de determinar què signifiquen per
poder-les tractar automàticament.
Reutilització de les dades
Molt sovint les dades es voldran reutilitzar per poder fer tasques diferents. Un
error corrent sol ser emmagatzemar-les específicament per fer una tasca concreta,
ja que això pot provocar que posteriorment sigui molt més complicat fer-les servir
per fer altres tasques.
Per tant, és bàsic disposar d’un sistema d’emmagatzematge que permeti aconse-
guir que les dades puguin ser reutilitzades fàcilment i si pot ser que puguin ser
reutilitzades tant per les persones com pels programes.
Compartició de les dades
En el passat, amb els ordinadors centrals la informació es generava i es processava

en el mateix lloc. Però l’aparició dels ordinadors personals, l’eclosió de les xarxes
i, sobretot, l’èxit d’Internet, ha creat tota una sèrie de problemàtiques que fins al
moment no existien: les dades generades en un lloc ara poden ser consumides en
un lloc totalment diferent, com ara:
• en sistemes operatius totalment diferents.
• en màquines que poden funcionar de maneres molt diverses.
Per tant, en un sistema informàtic modern s’ha de tenir en compte aquesta

possibilitat a l’hora d’emmagatzemar dades. Hi ha la possibilitat que aquestes
dades siguin compartides i, per tant, cal emmagatzemar-les d’alguna manera que
no tingui problemes per usar-les en sistemes diferents.
1.2 Emmagatzematge de dades en ordinadors
Atesa la seva arquitectura, els ordinadors emmagatzemen la informació en binari i,

per tant, tota la informació que s’hi pot emmagatzemar sempre es representarà en
uns i zeros (1, 0). Això fa que per representar qualsevol tipus de dades (imatges,
vídeos, text...) calgui fer algun tipus de procés que converteixi les dades a una
representació en format binari.
Tradicionalment en els ordinadors les dades s’organitzen de dues maneres:
• Dades de text
• Dades binàries
1.2.1 Dades binàries
Emmagatzemar les dades de manera binària és la manera natural d’emmagatzemar

dades en ordinadors. Estrictament parlant, les dades binàries estan en el format
que fa servir l’ordinador, ja que només són una tira de bits un rere l’altre. Per tant,
normalment, un ordinador no haurà fer cap procés especial per emmagatzemar i
llegir dades binàries.
Les dades en format binari tenen una sèrie de característiques que les fan ideals
per als ordinadors:
• Generalment estan optimitzades per ocupar l’espai necessari.
• Els ordinadors les llegeixen fàcilment.
• Poden tenir estructura.
• És relativament fàcil afegir-hi metadades.
Si un programa vol usar les dades binàries normalment només necessitarà conèixer
la mida en bits i, sobretot, conèixer de quina manera s’hi ha emmagatzemat la
informació.
Per emmagatzemar el nombre 150 només cal convertir aquest valor decimal a la
seva representació en binari i emmagatzemar-lo. És trivial comprovar que pot ser
emmagatzemat en un sol byte (8 bits) com es pot veure a la taula 1.1.
Taul a 1 .1. Representació del nombre 150 en binari
valor decimal valor binari
150 10010110
Un avantatge afegit de la representació de nombres en binari és que ja estan

disponibles immediatament per fer càlculs numèrics, ja que realment es tracta
de nombres. No caldrà fer cap transformació per poder usar aquest nombre en
qualsevol càlcul.
Metadades
Molt sovint no s’emmagatzemen directament les dades tal com estan sinó que
es processen per optimitzar-les, com ara emmagatzemant informació sobre el seu
contingut o aplicant-hi procediments d’optimització. Aquestes optimitzacions són
transparents per l’usuari final, que visualitzarà les dades normalment.
Una de les maneres més senzilles de representar una imatge en un ordinador

consisteix a representar cada un dels punts de color que la formen. O sigui, que
només cal dir de quin color serà cada un dels punts per poder emmagatzemar la
imatge en un fitxer (figura 1.1).
F ig u ra 1 . 1. Representació d’un gràfic en

un ordinador
Podem fer servir un mètode senzill per representar la imatge anterior, com podria
ser definir si cada un dels punts és de color blanc (0) o negre (1). La imatge podrà
ser representada d’aquesta manera:
1 001100
2 010010
3 010010
4 011110
5 010010
6 010010
En realitat un ordinador no emmagatzemarà la informació d’aquesta manera sinó

de manera lineal, ignorant els salts de línia. Una representació més propera a com
ho faria realment un ordinador seria aquesta:
1 001100010010010010011110010010010010
Representar la informació d’aquesta manera fa que les imatges ocupin molt

d’espai i per aquest motiu normalment es fan servir mètodes per optimitzar-ne
l’emmagatzematge.
Una de les maneres d’optimitzar l’espai ocupat per la imatge podria ser adonar-
se’n que hi han diverses repeticions dels colors. De manera que es podria intentar
aprofitar aquesta característica per aconseguir un fitxer binari més petit.
Es podria fer que en comptes d’especificar els punts un per un si hi ha una repetició
es pogués especificar el nombre de vegades que es repeteix el color. D’aquesta
manera un punt blanc aïllat es representarà normalment, però si es troben quatre
punts blancs, en comptes d’emmagatzemar 0000 es pot representar amb 40 (4
blancs)
El resultat d’aplicar aquest procediment a la mateixa imatge ens donarà:
1 202130120120120120412012012012010
Aquest procediment té l’avantatge afegit que amb el nou sistema les dades ocupen
un 10% menys d’espai (33 caràcters) que abans (36 caràcters).
A pesar que amb el nou sistema no s’emmagatzemen tots els punts un programa
pot aconseguir fàcilment representar-los en pantalla seguint les especificacions.
Es pot veure que en la representació binària hi ha tota una sèrie de valors que
estrictament no són dades de la imatge (els nombres 2, 3 i 4) sinó que són dades
que fan referència a la manera com s’han emmagatzemat les dades. Aquestes dades
s’anomenen “metadades”.
Les metadades són dades sobre les dades.
L’ús de metadades optimitza l’emmagatzematge d’informació però alhora fa que

la compartició de la informació continguda en el fitxer sigui molt més complexa.
Però això sí, cal que el programa que vulgui recuperar la informació conegui el
procediment que s’ha fet servir o no obtindrà les dades correctes.
Dades estructurades
Les dades en la manera com les generem els humans no estan en un format que en
faciliti el tractament automàtic per part d’un ordinador. Per aquest motiu sovint les
dades que han de ser processades pels ordinadors es converteixen a algun format
que sigui més idoni per al tractament. El més corrent és tractar les dades per tal
que tinguin algun tipus d’estructura.
Els tipus de dades estructurats són agrupacions d’altres tipus de dades

(normalment tipus més senzills).
La manera més corrent d’estructurar dades binàries sol ser tenir-les agrupades
en registres que contenen la informació repetitiva d’una dada en concret. És
habitual que els llenguatges de programació tinguin alguna manera de definir
dades estructurades. Per exemple, per a aquestes tasques el llenguatge C fa servir
els struct.
1 struct alumne {
2 char nom[10];
3 char cognom[10];
4 int nota;
5 }
Si es pot accedir a cada un dels registres del fitxer es pot accedir de cop a les
dades d’un alumne, es pot identificar ràpidament la part de les dades que és el
nom, cognom o nota, i a més sabem si les dades han de ser interpretades com a
nombres o com a text.
En l’exemple de la figura 1.2 podeu veure que es pot identificar a quina dada
correspòn cada un dels caràcters. Els deu primers són el nom, els 10 següents
són el cognom i els quatre següents són el número enter (32 bits).
Fig u ra 1 . 2 . Representació de dades en una estructura fent servir caràcters
Generalment aquestes dades estructurades s’emmagatzemen en forma de llistes o

conjunts de registres, de manera que el desenvolupador del programa podrà accedir
a les dades de tots els alumnes simplement recorrent els diferents registres un per
un.
Les dades estructurades facilitaran que les aplicacions les puguin tractar de manera
automàtica.
Problemes
Les dades binàries també tenen problemes associats a l’hora de ser compartides,
ja que en el món modern les dades s’han de compartir en màquines en què no han
estat generades, que poden tenir sistemes operatius diferents, poden ser màquines
totalment diferents, etc. Les dades binàries optimitzades per al sistema en què es
generen no sempre seran ben enteses pels altres sistemes.
Estructura de les dades

Un dels problemes de donar estructura a les dades és que aquesta estructura només
l’entendran els programes que tinguin informació sobre l’estructura. En definir
quines són les dades que farà servir el programa es defineix quina mida tindrà
cada camp i de quina manera es desaran les dades dins del fitxer binari.
Si agafem l’exemple que hem vist en la figura 1.1, perquè un programa pugui
representar la imatge de manera correcta cal que tingui prou informació per fer-
ho:
• Primer cal que conegui que el que hi ha representat és una imatge.
• També ha de saber que es desa cada punt de color amb un sol caràcter.
• És bàsic que conegui l’equivalència de colors que hem fet: 0 és blanc, 1 és

negre.
• I necessita saber que la imatge és de 6 caràcters de llargada per 6 caràcters

d’amplada o el resultat serà molt diferent del que era inicialment (figura 1.3)
• Si s’ha representat la imatge fent servir el sistema optimitzat cal que conegui
que els valors numèrics superiors a 1 indiquen que aquest valor no és un
color sinó que són el nombre de repeticions del color següent.
Fig ur a 1 . 3 . Intents de representar el gràfic sense

conèixer-ne les dimensions
Totes aquestes coses són les que cal conèixer per poder usar les dades d’un exemple
senzill; per tant, podeu imaginar-vos què passaria amb un exemple més complex.
Forma de lectura del processador

De la mateixa manera que en els llenguatges humans hi ha idiomes que s’escriuen
d’esquerra a dreta i d’altres de dreta a esquerra, tots els processadors no emmagat-
zemen la informació de la mateixa manera (tècnicament es fa referència a l’ordre
de lectura en les adreces de memòria).
Hi ha dos grans sistemes per emmagatzemar la informació en ordinadors:
• Big endian: les dades s’escriuen en l’ordre en què es creen. Així, per
escriure hola en l’ordinador s’emmagatzemaria h, o, l, a. Aquest sistema
és el que fan servir els processadors de Motorola.
• Little endian: les dades es desen de menys rellevant a més rellevant: a, l,

o, h. Aquest sistema és el que fan servir els processadors d’Intel.
El més habitual és que els ordinadors només facin servir un dels dos sistemes, tot
i que n’hi ha que poden funcionar amb tots dos indistintament (ARM, PowerPC,
PA-RISC...).
Això no és important quan les dades es passen entre ordinadors que funcionen amb
el mateix tipus, però és un aspecte vital que cal tenir en compte si els ordinadors
que es passen la informació són de tipus diferents, ja que les dades binàries
passades d’un sistema a l’altre poden ser totalment malinterpretades per culpa
que s’emmagatzemen internament de manera diferent.
Lectura per humans

Un problema diferent és que les dades en format binari estan pensades per ser
llegides per màquines (figura 1.4) però no per humans, de manera que són ideals
per ser emmagatzemades en màquines, van bé per a la comunicació d’informació
entre màquines, però en canvi perquè un humà les pugui fer servir caldrà tenir
un programa específic per llegir-les.
F igu r a 1. 4 . El format binari no està pensat per ser llegit per humans
Formats binaris estàndards
S’han definit alguns estàndards I a més, no serveix qualsevol programa, sinó que cal que el programa entengui
de fitxers binaris, cosa que
permet que qualsevol pugui fer l’estructura de les dades que conté el fitxer. Per exemple, les dades generades pel
programes que puguin
interpretar aquests fitxers. Microsoft Word no poden ser obertes amb el programa de dibuix Gimp perquè no
Això és el que passa per exemple,
està preparat per entendre-les.
amb els fitxers d’imatges JPG,
PNG, GIF..., que poden ser
llegits per diferents programes
Si qui ha desenvolupat el programa no ha fet pública de quina manera es desen les
perquè la seva especificació és
pública.
dades binàries que es generen serà molt difícil compartir dades amb altres usuaris
si no disposen del mateix programa.
• JPG - Estàndard
ISO/IEC 10918
• GIF - Especificació del

W3C gif89a
• PNG - Estàndard 1.2.2 Dades de text

ISO/IEC 15948
Per solucionar el problema que calgui recórrer a programes específics per recupe-
rar les dades que hi ha en un fitxer una possibilitat és fer el més obvi, fer el mateix
que han fet els humans durant segles. Els humans en escriure ja estan fent servir
una codificació i, per tant, si es fa servir la mateixa codificació tindrem les dades
en un format fàcil de fer servir i entendre que no tindrà problemes per ser llegit
En fitxers binaris el pels programes.
component d’informació
més petit era el bit, en
fitxers de text el component
més petit eś el caràcter.
Els fitxers de text emmagatzemen la informació lletra per lletra d’una manera
similar a com ho faria un humà en escriure. Això fa que s’estigui generant una
informació que es podrà llegir de la mateixa manera que es llegeix un document
de paper.
Per a un ordinador no hi ha gaire diferència a l’hora d’emmagatzemar els fitxers

de text o els fitxers binaris, ja que els fitxers de text també són tires de bits. La
diferència és que aquest cop els bits estan agrupats d’una manera estàndard i
coneguda: un codi de caràcters.
Codis de caràcters
Representar les dades en un ordinador en forma de text implica que per poder
representar una paraula qualsevol a l’ordinador prèviament haurà de ser codificada
per fer que pugui ser representada en binari (recordem que els ordinadors només
poden representar dades en binari). Aquesta codificació sol consistir a determinar
una quantitat de bits predefinida per marcar un caràcter i posteriorment s’associa
un valor numèric a cada un dels caràcters. Observeu que per a un
ordinador l’espai en blanc
és un caràcter més.
L’equivalència entre els caràcters i els seus valors numèrics no es pot fer de
manera aleatòria, ja que s’estaria creant el mateix problema que hi ha amb les
dades binàries. Si es vol aconseguir que les dades es puguin llegir en diferents
sistemes cal seguir algun tipus de norma coneguda per tothom. Per aquest motiu
van aparèixer els estàndards de codificació de caràcters.
Problema de la codificació de caràcters
Per exemple, si tinguéssim un idioma que només tingués 5 caràcters (les vocals AEIOU) es
podrien codificar tots els caràcters d’aquest idioma fent servir només 3 bits. Per tant, una
possible codificació de les lletres de l’idioma podria ser la de la taula 1.2.
Taul a 1. 2. Possible codificació de lletres

Caràcter Valor decimal Valor binari
A 0 000
E 1 001
I 2 010
O 3 011
U 4 100
Espai 5 101
Això ens permetria codificar la frase “AI AI AI” d’aquesta manera:
1 000010101000010101000010
Però davant del mateix problema una altra persona podria triar una combinació diferent,
com la de la taula 1.3.
Taul a 1. 3. Alternativa diferent de codificació
Caràcter Valor decimal Valor binari
Espai 0 000
A 1 001
E 2 010
I 3 011
O 4 100
U 5 101
Això provocaria que en comunicar la frase “AI AI AI” generada amb el primer sistema, en el
segon es descodificaria:
1 000 −−> Espai

2 010 −−> E
3 101 −−> U
I interpretaria que el missatge és ” EU EU EU”.
El procediment de tenir una taula amb els valors numèrics associats i simplement
fer la conversió és el procediment més habitual però també es donen casos en què
la codificació hagi de complir algun tipus de regles o restriccions a l’hora de fer
la conversió.
ASCII
Un dels primers estàndards que va ser adoptat majoritàriament va ser ASCII
(American standard code for information interchange), que es pot veure a la taula
1.4. ASCII codifica cada un dels caràcters amb set bits i defineix a quin valor
numèric es correspon cada un dels caràcters de la llengua anglesa.
Taul a 1. 4. Caràcters imprimibles de l’ASCII
Caràcter Valor Caràcter Valor Caràcter Valor Caràcter Valor Caràcter Valor
deci- deci- deci- deci- deci-
mal mal mal mal mal
32 3 51 F 70 Y 89 l 108
! 33 4 52 G 71 Z 90 m 109
” 34 5 53 H 72 [ 91 n 110
# 35 6 54 I 73 \ 92 o 111
$ 36 7 55 J 74 ] 93 p 112
% 37 8 56 K 75 ˆ 94 q 113
_
& 38 9 57 L 76 95 r 114
’ 39 : 58 M 77 ` 96 s 115
( 40 ; 59 N 78 a 97 t 116
) 41 < 60 O 79 b 98 u 117
* 42 = 61 P 80 c 99 v 118
+ 43 > 62 Q 81 d 100 w 119

, e x
44 ? 63 R 82 101 120
- 45 @ 64 S 83 f 102 y 121
. g z
46 A 65 T 84 103 122
/ 47 B 66 U 85 h 104 { 123
0 48 C 67 V 86 i 105 | 124
1 49 D 68 W 87 j 106 } 125
2 50 E 69 X 88 k 107 ˜ 126
La codificació que es fa en ASCII és relativament senzilla: simplement es compara

cada un dels caràcters del text per codificar en la taula i se n’obté el valor numèric
en binari. Per exemple, per codificar la paraula Hola en un ordinador que estigui
funcionant amb el codi ASCII haurem de convertir cada un dels caràcters en el
seu equivalent numèric (taula 1.5).
Taul a 1. 5. Conversió de caràcters a binari fent servir ASCII
Caràcter decimal binari
H 72 1001000
o 111 1101111
l 108 1101100
a 97 1100001
El primer problema que es va trobar per a l’ASCII era que només estava pensat
per l’anglès i, per tant, no es disposava de caràcters d’ús corrent en altres llengües:
ç, à, á, ñ, etc. Per tant, per poder expandir-se a altres zones es va crear un ASCII
expandit, que va incrementar el nombre de de bits a 8, i gràcies a aquest bit extra
s’hi podien especificar els caràcters específics de cada idioma que l’anglès no
tenia. D’aquesta manera es permetia crear textos en altres idiomes que fessin
servir l’alfabet llatí.
Això va fer que apareguessin moltes varietats d’ASCII, especialitzades en un grup

d’idiomes (ISO 8859-1, ISO 8859-2, etc.).
Però com que cada idioma feia servir els valors nous per afegir els seus caràcters
propis la informació representada fent servir un d’aquests “ASCII” no sempre es
veia bé en un altre dels “ASCII”.
A més, ASCII i ASCII expandit només estaven pensats per a idiomes que fessin
servir l’alfabet llatí i, per tant, els idiomes no basats en l’alfabet llatí havien de
recórrer a altres codificacions.
Unicode
Unicode és un intent de substituir els codis de caràcters existents per un de
genèric que serveixi per a totes les llengües, i per tant superi tots els problemes
d’incompatibilitat que es produïen en entorns multilingües i permeti afegir els
caràcters no llatins.
La idea bàsica de Unicode és donar a cada un dels símbols un identificador únic

universal de manera que es puguin fer servir en el mateix document idiomes
diferents sense que això comporti problemes de representació.
L’adopció de Unicode resol d’una vegada tots els problemes de representació de

caràcters en fitxers de text. Malgrat els seus avantatges,
Unicode també va rebre
crítiques de la comunitat
Unicode defineix tres formes de codificació bàsiques UTF (Unicode transformati- anglòfona, perquè feia que
els textos acabessin
on format), que podeu veure a la taula 1.6. ocupant més del doble que
en ASCII.
Taul a 1. 6. Formes de codificació de Unicode

Nom
UTF-8 Sistema basat en un byte amb alguns símbols de

longitud variable
UTF-16 Sistema de longitud variable basada en dos bytes
UTF-32 Sistema de longitud fixa que fa servir 32 bits per cada

caràcter
Unicode ha estat adoptat de manera general per la majoria de sistemes operatius

moderns. Actualment gairebé tots els sistemes operatius fan servir alguna varietat
de Unicode (el Linux sol fer servir UTF-8 i el Windows adapta UTF-16).
Compartició d’informació
Gràcies a l’ús d’estàndards de codis de caràcters la informació en forma de text

és més fàcilment compartida que no pas la informació binària, ja que els codis de
caràcters que fan servir els sistemes per representar el text són coneguts i poden
ser implementats lliurement.
Per tant, emmagatzemar les dades en format de text aporta dos grans avantatges:
• Les poden usar una gran quantitat de programes que ja existeixen (editors
de text, navegadors, etc.).
• Poden llegides per humans.
Amb un dels programes més simples que hi ha, un editor de text, es pot crear un
document que es podrà compartir amb qualsevol persona que entengui l’idioma en
què ha estat escrit. I com que tots els sistemes operatius porten de sèrie programes
capaços de carregar fitxers, si s’envia el fitxer a algú aquest no tindrà cap problema
per interpretar les dades quan les rebi.
Problemes
Generar informació en fitxers de text també té alguns problemes:
• Ocupen més espai al disc que els binaris.
• Hi ha múltiples codis de caràcters diferents.
• La manera com els tracten els diferents sistemes operatius.
• Falta d’estructuració de les dades.
Però a pesar dels problemes, aquests són molt menys importants que els que tenim
per compartir fitxers binaris. Per tant els fitxers de text són la manera més
senzilla d’assegurar-nos que podem compartir la informació que hi ha amb
altres persones.
Espai al disc
Un dels problemes que tenen els fitxers de text és que la informació ocupa molt més
espai del que ocuparia si s’emmagatzemés en format binari. Com podem veure
en la taula (taula 1.7), si volem emmagatzemar el nombre 150 en un ordinador el
resultat serà diferent en funció del format triat.
Taul a 1. 7. Diferència entre emmagatzemar en format de text i binari
Format Representació interna
Format binari 10010110
Format textual 00110001 00110101 00110000
Per emmagatzemar el nombre en format binari simplement es converteix a binari

i es podrà emmagatzemar en un byte (8 bits) mentre que si es vol emmagatzemar
en format de text fent servir ISO-8869-1 s’hauran de desar per separat cada un del
tres caràcters (1, 5 i 0). Amb el segon sistema caldran 3 bytes (24 bits): el triple
d’espai!
Però a més, si la informació desada en format binari cal per fer algun càlcul, ja es
pot fer servir immediatament, ja que s’emmagatzema realment el nombre; mentre
que si tenim el nombre en format de text l’haurem de convertir al seu equivalent
numèric abans de poder fer qualsevol operació matemàtica.
Múltiples codis de caràcters

Tot i que Unicode intenta que aquest problema desaparegui, alguns sistemes ope-
ratius encara fan servir múltiples codis de caràcters i els usuaris tenen informació
antiga desada en codis de caràcters antics. Per tant, la compartició de dades
encara provoca problemes que poden ser des de la simple representació incorrecta
d’algun caràcter fins a corrompre el text o fer que la lectura de la informació sigui
impossible.
F igur a 1. 5. Problema de codificació incorrecta de caràcters
Si l’objectiu és fer que les dades es puguin reutilitzar tant per programes com
per persones, els caràcters erronis s’han d’evitar. Com es veu en la figura 1.5 els
problemes en alguns casos poden ser poc importants si es vol que una persona
entengui el que hi posa, però poden ser un problema molt gran per a un programa,
ja que la seva capacitat d’interpretació és molt inferior.
L’adopció de Unicode en la majoria de sistemes operatius està fent que aquest

problema s’estigui reduint i el fet que la quantitat de codificacions de caràcters
sigui molt inferior a la quantitat de codis binaris fa que les dades en format de
text es considerin fàcilment compartibles.
Si algú hagués emmagatzemat informació durant els anys setanta, i encara es

tingués la capacitat de llegir el suport en el qual es van desar, difícilment es podria
recuperar alguna cosa de les dades binàries que s’hi trobessin, ja que els programes
que les van generar ja no existeixen o no funcionen amb els sistemes operatius
moderns, i en canvi és possible que les dades emmagatzemades en format de text
sí que es poguessin recuperar.
Representació de caràcters no textuals

Un altre problema que hi sol haver en la lectura de dades de text quan es fa en
diferents sistemes operatius sol estar relacionada amb com es fa el tractament dels
caràcters no textuals.
L’exemple més conegut és el diferent tractament que fan dels salts de línia els
sistemes Windows i les diferents varietats de Unix i Linux. Per representar els
salts de línia en el text els sistemes operatius fan servir algun dels caràcters no
imprimibles del codi de caràcters, i per tant, d’aquesta manera tenen una manera
“transparent a l’usuari” de poder representar el text tal com l’ha escrit.
El problema és que dos dels sistemes operatius més populars, Windows i Unix, ho
fan de manera diferent. Mentre que Unix fa servir un sol caràcter per indicar el
salt de línia, LF (line feed), Windows en fa servir dos: CR (carriage Return) i LF
(line feed). El resultat és que en obrir un fitxer generat en un sistema Unix en un
sistema en Windows els salts de línia han desaparegut i en el seu lloc hi apareix
un rectangle que representa el caràcter LF (figura 1.6).
F igu r a 1. 6 . Diferència del tractament en els salts de línia entre Windows i Linux
Actualment molt programes ja detecten aquest problema i el compensen automà-

ticament de manera transparent a l’usuari.
Lectura de dades automatitzada

Els programes d’ordinador encara no són gaire bons interpretant les dades si
són en text narratiu i, per tant, generalment convé que les dades que hauran
de ser tractades per programes d’ordinador estiguin definides amb algun tipus
d’estructura per tal que els siguin més fàcils de tractar.
S’han inventat sistemes per fer que les dades dels fitxers de text puguin ser
estructurades. Un dels formats que s’ha fet servir durant molt de temps per
exportar dades estructurades contingudes en bases de dades o fulls de càlcul a
text ha estat el CSV (comma separated values).
El CSV simplement es limita a separar cada un dels registres de l’estructura en

línies i els camps se separen amb comes. A més, per poder definir els tipus de
dades, envolta de cometes les dades de text, mentre que no es posen cometes en
les numèriques.
1 "Manel", "Puig", "Garcia", 8

2 "Pere", "González", "Puigdevall", 5
3 "Maria", "Pous", "Canadell", 7
CSV és una manera senzilla de desar dades estructurades en format de text

que permet a un programa identificar les diferents dades que conté cada
registre i a més interpretar de quin tipus són.
A més, un avantatge afegit de CSV és que és relativament fàcil afegir més dades a
un fitxer que estigui en format CSV, ja que només cal un editor de text i respectar
les regles de separar les dades amb comes i fer un salt de línia per cada registre.
Per tant un programa pot deduir fàcilment a partir de l’exemple anterior que les
dades són com es veu en la taula 1.8.
Taul a 1. 8. Interpretació del significat del fitxer CSV
Dada Resultat
Manel Dada de text perquè està entre cometes
Puig Dada de text perquè està entre cometes
Garcia Dada de text perquè està entre cometes
8 Dada numèrica
Però els sistemes d’estructurar dades en fitxers de text també tenen problemes. Si
necessitem afegir més dades a cada registre és gairebé segur que obligarà a fer
canvis en el programa que les tractarà. El programa necessita saber quines dades
hi ha en cada una de les columnes per poder treballar i, per tant, si modifiquem les
columnes pot malinterpretar les dades.
Problema d’afegir dades en un CSV
Per exemple, si afegim una dada nova amb tractament de la persona al davant del fitxer
anterior:
1 "Sr", "Manel", "Puig", "Garcia", 8

2 "Sr", "Pere", "González", "Puigdevall", 5

3 "Sra", "Maria", "Pous", "Canadell", 7
Si es fa servir el mateix programa que abans, aquest pot pensar que els noms de les
persones són “Sr” i “Sra” i que les notes són “Garcia”, “Puigdevall”, etc.
Però afegir dades no és l’únic problema que tenim, ja que representar les dades d’aquesta
manera n’arruïna la lectura de la gent que no faci servir els programes específics. Qui pot
saber que el nombre és una nota i no una altra cosa?
A qualsevol de vosaltres se us pot acudir una manera senzilla d’evitar aquest problema,
que consisteix a fer que la primera columna indiqui què és cada una de les dades que s’hi
representen a continuació.
1 "nom", "cognom", "cognom2", "nota"

2 "Manel", "Puig", "Garcia", 8
3 "Pere", "González", "Puigdevall", 5
4 "Maria", "Pous", "Canadell", 7
Desenvolupar un programa que interpreti aquestes dades i que s’asseguri que no

es produeixen errors és bastant complex.
1.3 Fitxers de marques
Es pot dir que els fitxers de marques són una manera diferent d’emmagatzemar
informació en ordinadors que s’afegeix a les maneres d’emmagatzemar la infor-
mació per mitjà de fitxers binaris o fitxers de text. L’objectiu principal dels fitxers
de marques és intentar recollir les millors característiques dels fitxers de text i
binaris i esquivar-ne els problemes.
Els fitxers de marques prenen com a base els fitxers de text per aprofitar-se
de les característiques més interessants d’aquest tipus de fitxers:
• La facilitat de creació i lectura.
• El compliment d’estàndards d’emmagatzematge definits i públics.
Com que els fitxers de text sempre estan emmagatzemats en algun codi de caràcters
conegut (ASCII, UTF-8, etc.) s’aconsegueix que puguin ser transportats i llegits
en qualsevol plataforma, sistema operatiu o programa que pugui interpretar
aquests codis de caràcters. Per tant, els llenguatges de marques s’aprofitaran
d’aquesta característica, en estar basats en el format de text.
A més, de retruc, també tindran l’avantatge que podran ser oberts i creats amb
els programes d’edició de text estàndard. Des d’editors tan simples com el Bloc
de notes dels sistemes Windows o el Gedit de sistemes Unix fins a editors més
complexos com el Microsoft Word, passant per editors especialitzats en XML com
l’Oxygen XML Editor.
Els fitxers de marques, per tant, s’aprofiten d’un dels grans avantatges dels arxius
de text sobre els arxius binaris, ja que aquests darrers requereixen ser oberts amb
un programa específic que en pugui interpretar el format.
Però els fitxers de marques no solament s’intenten aprofitar de les

característiques dels fitxers de text sinó que també intenten aconseguir les
característiques més interessants dels fitxers binaris, com:
• La incorporació de metadades.
• La definició de l’estructura de les dades.
Això fa que els llenguatges de marques adquireixin una de les característiques

més interessants dels fitxers binaris, que és la possibilitat d’incorporar informació
sobre les dades –metadades– però intentant que afecti el mínim possible la
llegibilitat del document.
També permeten definir les dades i la seva estructura de manera que sigui senzill
per un programa poder-les interpretar.
Gràcies als avantatges que ofereixen els llenguatges de marques, aquests s’han
convertit ràpidament en una de les maneres habituals de representar dades i es
poden trobar contínuament en les tasques habituals amb ordinadors:
• L’exponent més popular és Internet –el Web–, que està basat totalment en
els llenguatges de marques.
• Molts dels programes d’ordinador que feu servir habitualment fan servir en
algun moment alguna o altra forma d’algun llenguatge de marques per a
emmagatzemar les seves dades de configuració o de resultats:
– Internament els formats de documents de Microsoft Office o d’Ope-

nOffice.org o LibreOffice estan basats en llenguatges de marques.
– Microsoft Visual Studio desa la seva configuració fent servir llenguat-
ges de marques.
– etc.
1.3.1 Les marques
Les marques són una sèrie de codis que s’incorporen als documents electrònics
per determinar-ne el format, la manera com s’han d’imprimir, l’estructura de les
dades, etc. Per tant, són anotacions que s’incorporen a les dades però que no
en formen part.
Les marques, per tant, han de ser fàcilment distingibles del text normal (per la seva
posició, perquè segueixen algun tipus de sintaxi, etc.). Les marques més usades
són les que estan formades per textos descriptius i estan envoltades dels símbols
de “més petit” (<) i “més gran” (>) i normalment n’hi sol haver una al principi i
una al final:
1 <nom>Manel Puig Garcia</nom>

Aquestes marques poden ser imbricades per indicar estructures de dades:

1 <persona>
2 <nom>Manel Puig Garcia</nom>
3 <nom>Pere González Puigdevall</nom>
4 <nom>Maria Pous Canadell</nom>
5 </persona>
Però hi ha moltes altres formes de marques. Una altra idea consisteix a trobar
alguna combinació de caràcters que surti rarament en el llenguatge habitual. El
TeX fa servir les barres invertides per a indicar l’inici de les marques
1 \section{Persones}
2 \begin{itemize}
3 \item Manel Puig Garcia
4 \item Pere González Puigdevall
5 \item Maria Pous Canadell
6 \end{itemize}
Altres llenguatges de marques fan servir caràcters no habituals en determinades

posicions per indicar que són marques. Per exemple amb Wiki Markup els
caràcters ”=” a la primera posició d’una línia es fan servir per indicar que el text
és un títol d’apartat i el * per les llistes de punts:
1 = Persones =
2 * Manel Puig Garcia
3 * Pere González Puigdevall
4 * Maria Pous Canadell
La idea general és que cal que les marques siguin fàcilment identificables per
poder-nos aprofitar dels avantatges que ofereixen els llenguatges de marques.
1.3.2 Característiques dels llenguatges de marques
Els llenguatges de marques són una manera de codificar un document de text

de manera que per mitjà de les marques (l’equivalent de les metadades dels
fitxers binaris) s’hi incorpora informació relativa a com s’ha de representar
el text, sobre quina estructura tenen les dades que conté, etc.
Els llenguatges de marques han destacat per una sèrie de característiques que els
han convertit en els tipus de llenguatges més usats en la informàtica actual per
emmagatzemar i representar les dades. Entre les característiques més interessants
que ofereixen els llenguatges de marques hi ha:
• Que es basen en el text pla.
• Que permeten fer servir metadades.
• Que són fàcils d’interpretar i processar.
• Que són fàcils de crear i prou flexibles per representar dades molt diverses.
Les aplicacions d’Internet i molts dels programes d’ordinador que es fan servir
habitualment fan servir d’alguna manera o altra algun llenguatge de marques.
Basats en text pla
Els llenguatges de marques es basen en text pla sense format. Aquests caràcters
poden estar codificats en diferents codis de caràcters: ASCII, ISO-8859-1, UTF-8,
etc.
Un dels avantatges que intenten aportar els llenguatges de marques és que es

poden interpretar directament i això només és possible si fem servir el format
de text, ja que els binaris requereixen un programa per interpretar-los. Però a més
tenen l’avantatge que són independents de la plataforma, del sistema operatiu o
del programa.
El fet que estiguin basats en format de text fa que siguin fàcils de crear i de
modificar perquè només requereixen un simple editor de textos.
Ús de metadades
Les marques s’intercalen entre el contingut del document, de manera que general-
ment aquestes etiquetes solen ser descriptives de què és el que indica el contingut
de les dades que contenen.
Aquestes marques són la manera com s’afegeixen les metadades als documents de
text i com s’aconsegueixen superar les limitacions del format de text i aconseguir
alguns dels avantatges dels fitxers binaris.
Facilitat de procés
Els llenguatges de marques permeten que el processament de les dades que con-
tinguin pugui ser automatitzat d’alguna manera, ja que el fitxer conté l’estructura
de les dades que conté.
El fet d’incloure l’estructura permetrà que un programa pugui interpretar cada una
de les dades d’un fitxer de marques per representar-lo o tractar-lo convenientment,
ja que mostren l’estructura de les dades que contenen.
Posteriorment un programa podrà interpretar gràcies a les marques què és el que

significa cada una de les dades del document.
Facilitat de creació i representació de dades diverses
A pesar que van ser pensats per contenir dades de text, els llenguatges de marques
han demostrat que són capaços de contenir dades de molts tipus diferents.
Actualment s’estan fent servir fitxers de marques per representar imatges vecto-
rials, fórmules matemàtiques, crear pàgines web, executar funcions remotes per
mitjà de serveis web, representar música o sons, etc.
I sense importar quin tipus de dades s’hi representin sempre hi haurà la possibilitat
de crear aquests fitxers des d’un editor de text bàsic.
1.3.3 Classificació dels llenguatges de marques
És complicat fer una classificació dels llenguatges de marques que hi ha però

generalment s’accepta que en tenim dos grans grups basant-nos en quin és
l’objectiu bàsic del llenguatge de marques:
• Llenguatges procedimentals i de presentació, orientats a especificar com

s’ha de representar la informació.
• Llenguatges descriptius o semàntics: orientats a descriure l’estructura de

les dades que conté.
Aquesta és la classificació més acceptada però, com molt sovint passa en l’àmbit
de la Informàtica, ens podem trobar llenguatges que tinguin aspectes dels dos
grups i permetin tant definir la manera de presentar la informació com definir-ne
l’estructura.
Procedimentals i de presentació
En aquests llenguatges el que es fa és indicar de quina manera s’ha de fer

la presentació de les dades. Ja sigui per mitjà d’informació per al disseny
(marcar negretes, títols, etc.) o de procediments que ha de fer el programari de
representació. L’exemple més popular d’aquests llenguatges és l’HTML però n’hi
ha molts més: TeX, Wikitext...
En aquests casos els documents ens poden servir per determinar de quina manera
es mostrarà el document a qui el llegeixi.
Si agafem un exemple senzill fent servir el llenguatge de marques lleuger Wiki

markup, que fa servir Mediawiki (programa amb el qual s’ha desenvolupat la
Wikipedia):
1 = Classe =
2
3 == Assignatura: XML ==
4 [[Fitxer:xml.png]]
5
6 ’’’Professor’’’:
7 :* ’’Manel Puig’’
8
9 ’’’Alumnes’’’
10
11 :* Frederic Puig
12 :* Filomeno Garcia
13 :* Manel Puigdevall
Que ens mostrarà el que es veu a la figura 1.7:

Figur a 1. 7. Representació del text en format wikicode
Es pot veure com el programa ha interpretat les marques ”=” o ”==” per mostrar
els diferents nivells dels títols, que els símbols ”:*” indiquen llistes de punts i que
amb la diferent quantitat de cometes s’indiquen negretes o cursiva. Per tant, és un
exemple que indica clarament com ha de ser representada la informació.
Descriptius o semàntics
En aquests llenguatges es descriu quina estructura lògica té el document ignorant

de quina manera serà representada en els programes. Només es posen les marques
amb l’objectiu de definir les parts que donen estructura al document. L’exemple
més important és l’XML però n’hi algun altre que està tenint molt de suport, com
per exemple JSON.
En el document següent tenim un exemple d’un fitxer de marques que dóna

informació sobre persones:
1 <alumnes>
2 <persona>
3 <nom>Pere</nom>
4 <cognom>Puig</cognom>
5 </persona>
6 <persona>
7 <nom>Manel</nom>
8 <cognom>Garcia</cognom>
9 </persona>
10 </alumnes>
Es pot veure clarament que la informació de les marques en el document estableix

quin és el contingut de les dades: una llista d’alumnes. Amb un simple cop d’ull
resulta fàcil determinar que Pere i Manel són noms i que Puig i Garcia són
cognoms. Però per mitjà de la jerarquia de les dades es pot inferir que Pere Puig
i Manel Garcia són alumnes ja que tant nom com cognom estan englobats dins
de la marca alumnes.
Aquest document mostra quina és l’estructura de les dades que conté i a més
aquesta també es pot descobrir tot interpretant les etiquetes el seu contingut
semàntic. A partir dels coneixements que es tinguin es dedueix que Pere és el
nom d’una persona que és un alumne.
Sistema d’etiquetatge
Tant si el sistema és descriptiu com de presentació les marques no han estat

col·locades de qualsevol manera sinó que s’ha anat seguint un sistema determinat.
Sovint les marques envolten el contingut que volem que tingui un significat o
que sigui representat d’una manera determinada. No es poden col·locar les
marques de qualsevol manera, ja que una de les coses que cal evitar són possibles
malinterpretacions.
Per això, a més de definir les marques que s’hi posaran, els llenguatges de marques
defineixen unes regles d’ús que especifiquen com han de ser les marques, en quines
condicions es permet fer-les sevir i a vegades fins i tot què signifiquen.
1.3.4 Història
Es considera que l’origen dels llenguatges de marques està en les modificacions

que els impressors feien amb llapis en manuscrits. Quan algú volia imprimir un
llibre que havia escrit, els impressors, amb un llapis generalment de color blau,
escrivien en el text quines característiques havia de tenir cada part del text, si
s’havia de fer en negreta, si era el títol del llibre, etc. Es creu que aquests són els
antecedents de les marques.
SGML
Al principi dels anys vuitanta a IBM necessitaven alguna manera d’emmagatzemar

i compartir una gran quantitat d’informació entre diferents plataformes i que
permetés integrar les dades en sistemes de dades, editors, etc., i van desenvolupar
GML, que posteriorment va acabar amb el nom SGML en el moment en què va
ser estandarditzat l’any 1986 per l’organització d’estàndards internacional ISO
(International Organitzation for Standardisation). L’especificació es troba sota el
nom ISO-8879.
A pesar que no es considera el primer llenguatge de marques, va ser el primer

llenguatge reconegut com a estàndard ISO.
SGML (standard generalized markup language) és un llenguatge basat en les

dades de text que es pot fer servir per posar metadades a les dades. És un sistema
per organitzar i etiquetar elements d’un document posant èmfasi en els aspectes
de l’estructura d’un document i deixant que sigui l’intèrpret el que s’encarrega de
fer la representació visual d’aquestes dades. Ho fa definint unes regles estrictes
que especifiquen de quina manera es poden fer les etiquetes.
SGML es va dissenyar per ser una manera estàndard d’etiquetar dades genèriques
de manera que no importés si les dades per etiquetar provenien del món de les
matemàtiques o bé eren els resultats financers d’una empresa. Totes les dades es
podien etiquetar amb sentit fent servir SGML. El fet que SGML fos tan
complex no el feia ideal per
intercanviar dades per mitjà
SGML es feia servir sobretot en documents que havien de tenir molts canvis i que d’Internet. Si només un
grup de persones podia
posteriorment s’havien de representar en formats diferents. generar informació el
creixement de l’entorn Web
hauria estat molt inferior.
Per tant, amb SGML tenim els avantatges següents:
• Tenim una manera de reutilitzar les dades.
• Permet un control més gran sobre les dades i en garanteix la integritat.
• És portable.
• És flexible.
• Ens garanteix la perdurabilitat de la informació.
Però no tot són avantatges en l’SGML:
• La majoria dels documents que s’hi creaven només estaven destinats a la

impressió.
• És terriblement complex, de manera que no es fa servir en ordinadors

personals.
HTML
El 1989, Tim Berners-Lee i Anders Berglund, dos investigadors del CERN

(acrònim de Conseil Européen pour la Recherche Nucléaire, Organització Europea
per a la Recerca Nuclear), van crear un llenguatge basat en etiquetes basat en
SGML destinat a compartir informació per Internet: HTML (hypertext markup
language). HTML es basa en la manera de definir i interpretar etiquetes de SGML
però no és totalment compatible amb SGML (algunes de les regles que s’hi han
definit incompleixen les regles SGML).
HTML es concentra a definir un format per descriure la visualització de la

informació en una pàgina web i és molt senzill. La seva senzillesa ha estat un
dels factors que ha portat a la ràpida popularitat del World Wide Web i alhora
d’Internet. És un dels motius pels quals cada dia es generen milions de pàgines
web noves.
El gran èxit de les tecnologies basades en HTML ha fet que no parin d’evolucionar
i, per tant, que HTML hagués d’evolucionar molt ràpidament per adaptar-se cada
vegada a més canvis i a les noves necessitats dels usuaris. Això, sumat al propòsit
de no incrementar la dificultat del llenguatge, ha provocat que no sempre s’hagin
fet les coses de la mateixa manera i que, per tant, la creació d’intèrprets de HTML
(en especial els navegadors) cada vegada sigui més complexa.
A tot això s’hi ha de sumar que, malgrat no estar pensat per representar la infor-
mació, HTML no defineix gaire estrictament algunes de les regles de com s’ha de
visualitzar la informació, i per tant sovint els navegadors han fer interpretacions
que no sempre coincideixen amb les que fan els altres navegadors. És conegut per
tots els dissenyadors de pàgines web que les pàgines no sempre es veuen igual en
tots els navegadors (figura 1.8).
F igu r a 1. 8 . Visualització de pàgines en navegadors
A vegades les diferències són mínimes però en altres casos les diferències poden ser molt importants.
D’altra banda, HTML funciona bé a l’hora de presentar informació als humans

però té uns quants problemes que el fan poc eficient per a les noves aplicacions
actuals: és molt difícil reutilitzar la informació que conté per generar resultats
en formats diferents dels que ha definit el dissenyador i és molt complex per als
programes automàtics interpretar de quin tipus són les dades contingudes en un
document HTML.
Per tant, calia alguna manera de poder fer cerques intel·ligents en els documents
HTML i seleccionar-ne el resultats segons criteris personalitzables.
Calia una manera de buscar, moure, visualitzar i manipular la informació

continguda en els documents HTML.
I per aquest motiu va aparèixer l’XML.
XML
El consorci W3C va desenvolupar una alternativa a l’HTML que pogués satisfer

les necessitats futures del web. El 1996 el consorci W3C es va proposar introduir
el poder i la flexibilitat de l’SGML al web.
SGML oferia tres avantatges que l’HTML no tenia:
• Extensibilitat
• Estructura
• Validació
La versió més usada és la
1.0, ja que la versió 1.1 no
El febrer de 1998 es llença l’especificació 1.0 d’XML aporta gaires novetats
interessants per a la majoria
(www.w3.org/TR/2004/REC-xml-20040204) i posteriorment el 2004 va sortir la d’usos (bàsicament sobre
les versions d’Unicode
versió 1.1 (www.w3.org/TR/xml11). Aquestes especificacions s’han anat revisant posteriors a XML 1.0)
periòdicament.
L’XML és un llenguatge simple de descripció d’informació:
• És un estàndard que permet dissenyar i desenvolupar llenguatges de mar-

ques.
• És un format de text estandarditzat que serveix per representar i transportar

informació estructurada.
Nombre d’etiquetes
A l’HTML li ha anat bé amb un nombre finit d’etiquetes i, per tant, a l’hora de
dissenyar l’XML es van fer diversos intents de crear un nombre finit d’etiquetes.
Però tots els intents de crear un conjunt finit d’etiquetes van fallar perquè restringir
les etiquetes restava flexibilitat al llenguatge.
Es va veure que cada conjunt d’usuaris necessita un subconjunt d’etiquetes

diferent i que sovint eren divergents (els matemàtics en feien servir un, els químics
en necessitaven un altre, etc.), o sigui, que la solució final adoptada va ser la més
lògica: si restringir les etiquetes resta flexibilitat el més fàcil és no restringir-les.
L’XML defineix un nombre infinit d’etiquetes.
Per tant, l’XML permetrà que cada persona pugui definir les etiquetes que li facin
falta per poder representar les dades més adequadament.
Estructura de les dades

Una altra idea que es va tenir en compte a l’hora de desenvolupar l’XML era que
les dades que contingués es poguessin reutilitzar per generar altres resultats i, per
tant, calia que pogués ser interpretat fàcilment per mitjà de programes d’ordinador.
Per tant, les dades contingudes en documents havien de tenir una estructura.
Per tant, l’XML es va dissenyar amb la idea de donar estructura a les dades i
no preocupar-se de com es presentaran les dades als usuaris. Per fer-ho ja es
desenvoluparien altres alternatives: CSS, XML-FO, etc.
Una de les idees més importants d’XML és separar les dades de la

presentació.
Això fa que a l’hora de crear un document XML s’ha de pensar com s’han
d’estructurar les dades i mai especificar res de com s’hauran de representar.
Transport de les dades

El fet que l’XML es concentri en l’estructura de les dades i que, per tant, sigui
relativament fàcil determinar quines dades conté, el fa un sistema ideal per al
transport de dades entre diferents plataformes.
Per tant, si tenim un document XML com aquest:
1 <alumnes>
2 <persona>
3 <nom>Manel</nom>
5 </persona>
6 <persona>
7 <nom>Pere</nom>
8 <cognom>González</nom>
9 </persona>
10 </alumnes>
Podem veure que observant aquest document és relativament senzill respondre les
preguntes:
• Quina informació conté el fitxer?
• Quina és l’estructura de la informació?
• Quines etiquetes s’han creat per descriure’n la informació?
Creació de llenguatges
És evident que la llibertat que dóna tenir un nombre infinit d’etiquetes no és
necessària en la majoria dels àmbits d’actuació. Per aquest motiu, normalment
quan algú vulgui emmagatzemar informació definirà un nombre finit d’etiquetes i
en quin ordre han d’aparèixer.
Per poder solucionar aquests problemes en XML es poden definir fitxers que
defineixin quina serà l’estructura del document, i que, per tant, es pugui comprovar
si el document segueix l’estructura correcta o no. Això alhora permet que si
definim el vocabulari de manera pública qualsevol ens pugui enviar documents
i detectar si estan ben formats o no.
De fet, ja hi ha tota una sèrie de documents basats en XML que s’han convertit
en estàndards públics en diferents àmbits, alguns dels quals els podeu veure en la
taula 1.9.
Taul a 1. 9. Alguns llenguatges estàndard basats en XML
Nom Ús
SVG Pensat per a gràfics vectorials en 2D amb

animacions o sense
MathML Llenguatge per representar fórmules matemàtiques
CML Llenguatge per a l’intercanvi d’informació química
SMIL Tractament d’informació multimèdia
SSML Síntesi de veu
ChessGML Per representar partides d’escacs

Tau l a 1.9 (continuació)
Nom Ús
XFRML Per fer informes financers
SML Usat en la indústria de l’acer
Però no s’acaba aquí, ja que la llista és immensa: SMBXML, CIML, NAML, TML,
SCORM, LMML, OpenMath, PetroXML, ProductionML, GeophysicsML, X3D,
MML, SMDL, BGML, etc.
Extensible
Un altre dels avantatges d’XML és que és fàcilment extensible i adaptable a les
necessitats que tinguem. L’XML permet que es barregin diferents vocabularis en
el mateix document.
Això fa que puguem definir un document XML amb un vocabulari creat per
nosaltres que defineixi una llista d’alumnes i que alhora hi puguem afegir una
imatge amb el logotip de l’escola en format SVG (un estàndard XML de gràfics
vectorials) i alhora definir-hi la presentació en XHTML.
Per tant, tenim prou flexibilitat per representar les dades que ens calguin en cada
moment
Ús d’XML
Actualment els usos d’XML són molt diversos:
• Mostrar el contingut de pàgines web. Un dels llenguatges XML és

l’XHTML, que intenta modificar l’HTML per fer-lo més senzill d’interpre-
tar.
• Comunicar sistemes distribuïts que fins i tot executin sistemes operatius

diferents o estiguin en plataformes totalment diferents.
• En comerç electrònic, en un sistema conegut com a Bussines2Bussines que

permet a les empreses compartir dades de manera automàtica.
• Reduir la càrrega de servidors distribuint-la entre servidors.
Molts programes que feien servir formats binaris per emmagatzemar les seves
dades han passat a algun tipus d’XML:
• Microsoft Office: va passar de desar els documents en binari .DOC a XML

.DOCX (OOXML) en estandaritzar-lo.
• OpenOffice.org: desa els seus documents en un format XML.
Podem veure que molts programes fan servir XML per desar la seva configuració
o les seves dades amb una simple cerca en el sistema operatiu.
Amb una simple cerca podem veure quants fitxers XML tenim en el nostre sistema
operatiu. Per exemple, en Linux podem executar el següent per veure el nombre
de fitxers XML que hi tenim:
1 $ locate .xml | wc −l
En Windows podem fer el mateix amb:
1 c:\> dir /a−d /s *.xml | find /c /v “”
Problemes
A pesar dels múltiples avantatges que ofereix l’XML, també se li han fet crítiques,
com el fet que els fitxers XML tenen la tendència a ser molt grans. Gairebé sempre
ocupen una quantitat molt més gran d’espai en disc que els seus equivalents en
format binari.
El fet de fer servir fitxers molt grans pot tenir un impacte important en el rendiment
dels programes, ja que abans de poder-hi treballar han de carregar el fitxer o
descarregar-lo de la xarxa.
Hi ha gent que considera que el problema de la grandària dels fitxers a vegades és

compensat per:
• La facilitat d’interoperativitat entre programes.
• El preu de l’emmagatzematge és cada vegada més baix i per ara sembla que
la tendència és que encara baixi més.
Però no tothom hi està d’acord, i per aquest motiu han aparegut tota una sèrie
d’alternatives a l’XML que es coneixen com a llenguatges de marques lleugers,
que normalment tenen com a objectiu aconseguir que els fitxers de marques ocupin
molt menys espai:
• En ocupar menys espai estalvien amplada de banda i espai de disc.
• Normalment es poden convertir a XML sense problemes.
• Ocupen menys memòria RAM quan són processats.
Els llenguatges de marques lleugers més usats actualment són JSON (JavaScript
object notation) i els llenguatges de marques dels wikis.
2. Documents XML
Vegeu la recomanació de
l’W3C relativa a l’XML en
la secció “Adreces
d’interès” del web del
XML són les sigles d’extensible markup language (llenguatge d’etiquetatge mòdul.
extensible). És un llenguatge estàndard, una recomanació del World

Wide Web Consortium (W3C, www.w3.org/TR/REC-xml). Està basat en
l’estàndard ISO SGML.
L’XML està tan basat en SGML que qualsevol document XML és un alhora un
document SGML correcte (encara que a l’inrevés no passa).
L’XML va sorgir per intentar superar els problemes que tenia l’HTML a l’hora de
processar automàticament la informació que contenen les pàgines web, però que a
més pogués funcionar de la mateixa manera que es fa servir l’HTML. A més, s’hi
van afegir altres requisits, com que:
• Fos fàcil crear documents XML i que els humans els poguessin llegir i
entendre fàcilment.
• No fos complicat fer programes d’ordinador que treballessin amb XML.
• L’XML es pogués fer servir en el màxim possible de camps d’aplicació i

mantingués la compatibilitat amb SGML.
El resultat ha estat que l’XML:
• Defineix la sintaxi genèrica per marcar les dades amb valors comprensibles
per als humans.
• És una manera de donar format als documents que és prou flexible per
ser personalitzada per a diferents destinacions: web, impressores, bases de
dades, etc.
• Està pensat perquè tothom el pugui fer servir sigui quina sigui la seva àrea
d’interès.
2.1 Metallenguatge
En realitat l’XML no és un llenguatge de marques, sinó que és un llenguatge

que ens permetrà definir els nostres llenguatges de marques propis. Això vol dir
que podrem definir llenguatges de marques específics per a cada un dels camps
d’interès. Si treballem en el món dels gràfics podem definir el nostre llenguatge
específic per definir aquests gràfics, i si treballem en el món de la premsa podrem

definir el nostre llenguatge per representar les notícies.
Per aquest motiu sovint es diu que l’XML és un metallenguatge, ja que ens permet
definir l’estructura i el vocabulari d’altres llenguatges de marques.
L’XML és un llenguatge per crear llenguatges de marques.
Aquesta llibertat a l’hora de definir les marques que ens interessin és un dels punts
forts d’XML, que el fan molt més potent i adaptable a les diferents complexitats
dels entorns en els quals pugui caldre.
2.2 Elements
La base de l’XML són els elements. Un element normalment estarà format per
l’obertura d’una etiqueta –amb atributs o sense–, un contingut –que també pot ser
un grup d’etiquetes–, i el tancament de l’etiqueta.
En aquest exemple podem veure el que acabem de comentar. Definim una etiqueta
nom, després el contingut Pere Martí i posteriorment tanquem l’etiqueta:
1 <nom>Pere Martí</nom>
Aquest és un dels punts forts de l’XML: queda bastant clar que el contingut de
dins de l’etiqueta és un nom.
Es podria fer l’exemple una mica més complex afegint-hi un atribut.
Els atributs s’afegeixen sempre en l’obertura de l’etiqueta.
1 <nom càrrec="director">Pere Marti</nom>
Un altre dels aspectes bàsics de l’XML és que no es preocupa de la presentació

sinó que parteix de la idea que l’important és el contingut de les dades i no la
manera com es visualitzaran. Aquesta característica el fa ideal per presentar la
informació i posteriorment per mitjà d’algun procés convertir la informació en un
format de presentació específic com HTML, PDF, PostScript, etc. A més, aporta
una característica molt interessant des del punt de vista de la informàtica: permet
tenir les dades separades de la manera de representar-les.
L’XML permet separar el contingut de la manera com serà presentat aquest

contingut als usuaris.
2.2.1 Etiquetes
Les etiquetes es defineixen dins del document XML i es defineix un format per
separar-les clarament del contingut de dades. Estrictament parlant hi ha dos tipus
d’etiquetes:
• Les etiquetes d’obertura
• Les etiquetes de tancament
La informació es distribueix entre els dos tipus d’etiquetes. Així s’aconsegueix

una manera senzilla de definir quines parts del document són dades i quines són
estructura.
Les etiquetes d’obertura es defineixen amb els símbols de més petit ”<” i més gran
”>” amb un nom d’etiqueta al mig.
1 <etiqueta>
I les etiquetes de tancament es defineixen igual que les d’obertura però a l’hora de
començar l’etiqueta s’hi especifiquen dos símbols: un símbol de més petit i una
barra ”</”. D’aquesta manera es poden distingir fàcilment els dos tipus d’etiquetes
i queda clar en quin lloc s’ha d’afegir el contingut.
1 <etiqueta>Contingut</etiqueta>
L’XML no defineix cap etiqueta sinó que permet que les defineixi cadascú en
funció del que necessiti representar. Això fa més senzill crear documents XML,
ja que no cal conèixer cap etiqueta per poder començar a treballar i perquè permet
adaptar-se a qualsevol tasca.
A l’hora de definir les etiquetes es pot deixar un espai o un salt de línia darrere
del nom de l’etiqueta però mai abans ni al mig. Per tant aquestes etiquetes serien
correctes:
1 <etiqueta1>
2 <etiqueta >
3 </etiqueta>
4 </etiqueta1 >
5 </etiqueta2
6 >
I en canvi aquestes altres no serien correctes:
1 < etiqueta>
2 <etiqueta 1>
3 < /etiqueta2>
Com s’acaba de veure, l’especificació XML defineix clarament com s’han de

crear les etiquetes en els documents XML, però en canvi no defineix cap tipus
ni significat associat a cap de les etiquetes. Si, per exemple, fem servir en HTML
l’etiqueta <b>, aquesta ens està indicant que el contingut que contindrà s’haurà
de representar en negreta. Això obliga que per fer documents XML s’hagin de
conèixer les etiquetes.
Per a l’XML les etiquetes només són una manera de separar el contingut i definir
l’estructura de les dades que conté. La interpretació de què signifiquen les dades
i com s’han de representar es deixa a qui llegeixi el document (independentment
El tractament d’excepcions que aquest sigui un humà o bé un programa).
que s’ha de fer per
interpretar HTML és una de
les coses que fa més
complexa la tasca de
A pesar de la llibertat a l’hora de deixar que els usuaris triïn les seves pròpies
programar els navegadors etiquetes, l’XML és molt més rigorós que altres llenguatges a l’hora de definir
web actuals.
com s’han d’escriure. L’objectiu de tenir regles d’escriptura està determinat per
la necessitat que els documents XML en un moment o un altre seran processats
per un programa, i els programes es fan més complexos a l’hora de tractar amb
excepcions. Per tant, una de les coses que fa l’XML és evitar les excepcions tant
com sigui possible.
Les etiquetes que s’obrin sempre s’hauran de tancar.
Per evitar les excepcions una de les regles bàsiques d’XML és que qualsevol
etiqueta que s’obri sempre s’ha de tancar. De manera que aquest no seria un
document XML vàlid:
1 <nom>Pere Garcia
I en canvi aquest sí:

1 <nom>Pere Garcia</nom>
A pesar que no hi ha etiquetes definides, ja que l’XML permet crear les etiquetes
que ens facin falta, per un motiu de llegibilitat i d’interpretació de les dades es
recomana que les etiquetes siguin autoexplicatives i pronunciables. Això és
per evitar coses com la de l’exemple següent:
1 <pccc>Figueres</pccc>
Segons aquest segon exemple, com determinem què és “Figueres”? Per a

un programa d’ordinador segurament no seria un problema massa gran perquè
simplement agafaria la dada i la interpretaria tal com l’hagin programat però en
canvi per a un humà un document amb etiquetes com aquesta seria impossible
d’interpretar.
Es recomana triar els noms de les etiquetes de manera que puguin ser
interpretades per qui les llegirà independentment de si les processa una
persona o un programa.
L’exemple anterior serà més fàcil d’interpretar si canviem l’etiqueta:

1 <ciutat>Figueres</ciutat>
2.2.2 Contingut
El contingut d’un element serà tot allò que hi hagi entre les etiquetes d’obertura i
de tancament. En el contingut podem tenir simplement text com aquí:
1 <persona>Pere Martí</persona>
O bé el contingut poden ser altres elements. En l’exemple següent l’element

<persona> conté dos elements més: <nom> i <cognom>, que a més tenen contingut
dins seu:
1 <persona>
2 <nom>Pere</nom>
3 <cognom>Martí</cognom>
4 </persona>
Una tercera possibilitat seria combinar els dos casos anteriors i que el contingut
sigui una mescla de text i elements.
1 <persona>
2 Pere Martí
3 <carrec>Director</carrec>
4 </persona>
També és possible definir etiquetes sense contingut de manera que el seu significat
està determinat pel nom de l’etiqueta.
1 <persona>
2 </persona>
Els elements buits també es poden definir fent servir el símbol /> en tancar
l’etiqueta. De manera que no hi ha cap diferència entre definir <director>
d’aquesta manera:
1 <director/>
o d’aquesta:
1 <director></director>
Els elements buits, encara que es defineixin amb el seu format especial, han de
seguir les mateixes normes que els elements normals. Per tant, serien correctes
les definicions següents:
1 <director />
2 <director
3 />
I no ho serien aquestes:
1 < director/>
2 <director/ >
L’XML no defineix cap restricció a l’hora de definir el contingut dels elements.

Per tant:
• Podem fer servir qualsevol caràcter representable amb el codi de caràcters.
• El contingut pot ser tan llarg com ens faci falta.
• Es pot escriure en qualsevol idioma del món.
• No importa que hi hagi espais en blanc o salts de línia dins del contingut.
Entitats
L’única cosa que s’ha de tenir en compte a l’hora de definir continguts és que
hi ha una sèrie de caràcters que poden provocar que hi hagi confusions a l’hora
d’interpretar el document XML, i per tant s’han declarat il·legals. No cal oblidar
que un dels objectius de l’especificació és “que sigui fàcil escriure programes que
processin els documents”, i per tant s’han d’evitar les interpretacions.
Si passem el codi següent a un programa d’ordinador tindrem un problema
1 <algebra>
2 x<y i y>z
3 </algebra>
Per a un humà això no seria un problema perquè pot interpretar les dades per
mitjà del seu coneixement, però en canvi un programa en llegir el contingut del
document interpretaria que <y i y> és el començament d’una nova etiqueta.
Per evitar aquest problema s’han definit una sèrie de valors, anomenats entitats,
que es fan servir per poder incloure els caràcters problemàtics dins del contingut
Referències de caràcters
de les etiquetes (taula 2.1).
En realitat qualsevol caràcter es
pot representar com una entitat Taul a 2. 1. Entitats definides en XML
fent servir el seu valor numèric
en Unicode, emprant els símbols Símbol Substitució
&# i els tres dígits del seu valor
numèric. Per exemple: &#169 < <
> >
” "
’ '
& &
Seccions CDATA
Es pot donar el cas que el contingut d’un element sigui HTML o bé codi en
algun llenguatge de programació. Això obligaria a substituir per entitats una gran
quantitat de símbols i a més restaria llegibilitat al document. Per evitar-ho l’XML
CDATA és un terme heretat
d’SGML i resumeix el text permet fer servir les seccions CDATA dins del contingut d’un element. Tot el que
character data. estigui dins d’una secció CDATA no serà interpretat per cap programa.
Les seccions CDATA funcionen com les etiquetes normals. Es defineixen

començant per <![CDATA[ abans d’especificar el contingut i s’acaben amb la
combinació de caràcters ]]>. Per tant, podem definir contingut amb símbols
prohibits dins de les seccions CDATA sense problemes.
1 <valor>
2 <![CDATA[
3 if (x <y and y>z)
4 {
5 printf("Correcte!");
6 }
7 ]]>
8 </valor>
A més es pot veure fàcilment que per a un humà és més difícil interpretar això:
1 <titol>Els documents HTML comencen per <html></titol>
Que el seu equivalent amb CDATA:
1 <titol>
2 <![CDATA[
3 Els documents HTML comencen per <HTML>
4 ]]>
5 </titol>
Un altre problema que solucionen les seccions CDATA és que permeten afegir
contingut en un llenguatge de marques que no cal que estigui ben format. Per
exemple, si el contingut té etiquetes que no es tanquen només es poden definir en
una secció CDATA o bé el programa les interpretarà com a etiquetes del document
i donarà un error.
Les seccions CDATA normalment es fan servir per al següent:
• Definir grans fragments de text que requereixin moltes substitucions d’enti-

tats.
• Si s’ha d’incloure contingut en HTML, Javascript o algun llenguatge similar.

La substitució amb entitats li resta llegibilitat.
• Si el contingut està en un llenguatge de marques i no està ben format.
2.2.3 Atributs
Una manera alternativa d’afegir contingut als documents XML és per mitjà dels
atributs. Els atributs són un parell de valors separats per un = que només
s’especifiquen en les etiquetes d’obertura.
El primer valor del parell ens indica quin és el nom del contingut i es farà servir
per interpretar què indiquen les dades que té associades, mentre que el segon ens
definirà el contingut de l’atribut.
1 <nom carrec="professor">Frederic Garcia</nom>
Es pot veure com l’atribut carrec dóna un nivell més d’informació a nom. Ara se
Per especificar els atributs sap que fa referència al nom d’un professor.
es poden fer servir tant les
comentes dobles com les
cometes simples. Això sí,
sempre s’ha de tancar les
A diferència del que passa en altres llenguatges de marques com l’HTML, l’XML
cometes tal com s’han obert. és molt més estricte i obliga que tots els valors dels atributs han d’estar
<corredor posicio=“1”> o
<corredor posicio=‘1’> envoltats per cometes. En altres llenguatges de marques es permet que els valors
però mai <corredor
posicio=“1’> numèrics no vagin entre comentes però en XML no es pot fer. Per tant l’exemple
següent seria incorrecte perquè l’atribut no té cometes.
1 <corredor posicio=1>Manel Roure</corredor>
Si es vol especificar s’ha de posar entre cometes simples:
1 <corredor posicio=’1’>Manel Roure</corredor>
o dobles:
1 <corredor posicio="1">Manel Roure</corredor>
Fins i tot quan els atributs no cal que tinguin cap valor, perquè es considera que
ja se’n pot interpretar el significat pel nom de l’atribut, s’hi ha d’especificar valor
entre cometes. Per tant, l’exemple següent no seria correcte perquè l’atribut no té
valor:
1 <alumne delegat>Jaume Ravent</alumne>
Ho hauríem d’especificar amb la cadena buida:
1 <alumne delegat="">Jaume Ravent</alumne>
O posant-hi algun valor:
1 <alumne delegat="si">Jaume Ravent</alumne>
L’XML permet definir tants atributs com faci falta sense cap tipus de restricció.
Les úniques condicions que hem de seguir és que cada un dels atributs ha d’estar
separat dels altres almenys per un espai.
1 <persona nom="Xavier" cognom="Sala"/>
L’ordre en què apareixen els atributs no té cap importància, de manera que

els dos codis següents serien equivalents:
1 <persona nom="Xavier" cognom="Sala" />
1 <persona cognom="Sala" nom="Xavier" />

Quan s’han de fer servir atributs i quan elements?
Hi ha hagut molts debats sobre quan s’han de fer servir atributs i quan s’han de fer servir
elements sense que s’hagi trobat cap argument totalment acceptat per tothom.
Al final el resultat pràctic és que és virtualment el mateix fer això:
1 <persona nom="Pere" />
Que fer:
1 <persona>
2 <nom>Pere</nom>
3 </persona>
I per tant sempre es pot fer servir el mètode que ens agradi més.
Una altra característica important dels atributs és que no es poden repetir els
noms dels atributs dins d’un mateix element. De manera que no és correcte
especificar dos atributs carrec:
1 <politic carrec="alcalde" carrec="diputat">Jordi Rufi</polític>
Per tant, s’ha de buscar una altra manera d’especificar-ho. Per exemple, amb una
llista de valors:
1 <politic carrec="alcalde diputat">Jordi Rufi</polític>
o bé posant noms d’atributs diferents:
1 <politic alcalde="si" diputat="si">Jordi Rufi</polític>
Atribut xml:lang
L’atribut xml:lang és un atribut predefinit i serveix per especificar l’idioma que

Vegeu les formes
s’ha fet servir per escriure el contingut tant de l’element com dels altres atributs. definides per l’IETF en el
BCP 47 en la secció
“Adreces d’interès” del
El valor de l’atribut xml:lang pot ser buit o bé ha d’estar en una de les formes web del mòdul.
definides per l’IETF en el BCP 47 (www.rfc-editor.org/rfc/bcp/bcp47.txt), que fan
servir els codis ISO que defineixen les regions i els idiomes. Sense entrar-hi en
profunditat això implica que hi podem definir el codi ISO d’un idioma o bé una
combinació de codis ISO que defineixin la regió i l’idioma.
L’atribut xml:lang ens permet definir en quin idioma està el contingut d’un
element o d’un document XML.
Per tant, el valor de l’atribut xml:lang d’aquest exemple seria vàlid perquè el codi
ISO 639 de dues lletres per a la llengua catalana és ca.
1 <missatge xml:lang="ca">Hola</missatge>
Però també seria vàlid fer servir qualsevol de les combinacions de regió i idioma:
1 <missatge xml:lang="ca−ES">Hola</missatge>
2 <missatge xml:lang="ca−AD">Salut</missatge>
L’atribut només fa referència a l’element en què s’ha especificat i al seu contingut,

de manera que aquí:
1 <saludar xml:lang="ca">
2 <arribar>Hola</arribar>
3 <marxar>Adéu</marxar>
4 </saludar>
es pot considerar que els elements arribar i marxar tenen també l’atribut
xml:lang perquè són contingut de <saludar>, i per tant el seu contingut i el
valor dels seus atributs està en català.
Sempre es pot evitar aquesta forma d’herència de l’atribut redefinint l’atribut

xml:lang com en aquest exemple:
1 <saludar xml:lang="ca">
2 <arribar>Hola</arribar>
3 <arribar xml:lang="en">Hello</arribar>
4 </saludar>
S’hi defineixen dos elements arribar, un que té el contingut en català, ja que l’ha
heretat de l’element saludar, que els conté, i l’altre que té el contingut en anglès
perquè se l’hi ha especificat l’idioma explícitament.
L’objectiu de l’atribut xml:lang és permetre que els programes puguin interpretar

l’idioma en el qual hi ha el contingut dels documents o dels elements XML. Hi
ha molts programes que fan servir aquesta característica per poder fer que els
programes adaptin el contingut que han de mostrar en l’idioma del qui els fa servir.
Si es té un programa que vol mostrar missatges per pantalla en l’idioma que faci
servir l’usuari se li podria preparar un fitxer de dades com el següent, que li
permetria fer-ho un cop hagués determinat l’idioma del sistema operatiu:
1 <programa>
2 <missatge xml:lang="ca">Benvingut</missatge>
3 <missatge xml:lang="es">Bienvenido</missatge>
4 <missatge xml:lang="fr">Soyez le bienvenu</missatge>
5 <missatge xml:lang="en">Welcome</missatge>
6 </programa>
L’atribut ”xml:space”
L’atribut xml:space fa referència a com s’han de tractar els espais que hi ha en el

contingut d’un element determinat.
Quan algú edita un document XML és corrent que faci servir espais i salts de línia
perquè el document sigui més “bonic” però realment aquests espais i salts de línia
no formen part del contingut. Amb l’ús de l’atribut xml:space es defineix si
aquests espais són part del contingut o no.
Només hi ha dos valors acceptats per a l’atribut xml:space: default i preserve

(taula 2.2).
Taul a 2. 2. Valors acceptats per a l’atribut ”xml:space”
Valor Significat
default Implica que el document ha de mostrar només un sol

espai de separació entre les paraules. Qualsevol
altra cosa ha de ser suprimida.
preserve Fa que els espais es deixin tal com estan en el

document. Per tant, si hi ha 5 espais després d’una
paraula en el contingut s’han de preservar aquests
espais.
Qualsevol altre valor es considerarà un error lleu i no es tindrà en compte.
Seguint el que hem definit, en el document següent:

1 <missatge xml:space="default">
2 Hola:
3 Com va tot?
4 </missatge>
Com que l’element <missatge> té de paràmetre xml:space=“default”, li

estem especificant que se suprimeixin els espais, o sigui, que seria com tenir:
1 <missatge>Hola: Com va tot?</missatge>
En canvi, si l’atribut hagués estat preserve el valor del contingut de <missatge>

seria interpretat respectant els espais i els salts de línia.
1 <missatge>
2 Hola:
3 Com va tot?
4 </missatge>
Els processadors XML han de passar tots els espais que no siguin etiquetes
al programa que llegeixi el document. Per tant, a pesar del nom per defecte
es fa servir preserve.
2.2.4 Noms vàlids XML
L’XML permet definir les nostres etiquetes i atributs lliurement però no totes les
combinacions possibles són acceptables. Els noms de les etiquetes i dels atributs
han de complir unes regles per ser considerats “correctes”.
Tot i que els dos punts estan
acceptats no es recomana
Les regles per definir noms correctes són senzilles: que es facin servir en la
creació d’etiquetes perquè
es reserven per ser usats
1. Els noms han de començar per una lletra de l’alfabet, el caràcter de subratllat en espais de noms.
(_) o un guió (-). També s’accepta el caràcter de dos punts (:), però està
reservat.
2. Els caràcters en majúscules són diferents dels caràcters en minúscules.
3. No hi pot haver espais enmig del nom.
4. No poden començar per la paraula XML tant si qualsevol de les lletres

està en majúscules o en minúscules. Aquestes paraules es reserven per a
estandarditzacions futures.
Seguint aquestes regles tindrem que l’exemple següent:
1 <Ciutat comarca="Alt Empordà">Figueres</Ciutat>
L’etiqueta <Ciutat> és correcta perquè compleix totes les regles. La primera

lletra del nom comença per un caràcter de l’alfabet, C, no hi ha cap espai enmig
del nom, i no comença per les lletres xml.
Alhora, l’atribut comarca també és correcte perquè comença amb un caràcter de

l’alfabet, c, no té espais i no comença per xml.
En canvi no és correcta l’etiqueta <Alt Empordà> perquè té espais enmig del

nom:
1 <Alt Empordà></Alt Empordà>
Ni ho serien les etiquetes <1aPosicio> i <2aPosicio>, ja que comencen per un

dígit:
1 <carrera>
2 <1aPosicio>Manel Garcia</1aPosicio>
3 <2aPosicio>Pere Pi</2aPosicio>
4 </carrera>
En la taula 2.3 hi ha exemples d’etiquetes correctes i incorrectes.

Taul a 2. 3. Exemples d’etiquetes correctes i incorrectes
Etiquetes correctes Etiquetes incorrectes
<correu1/> <1Correu/>
<correu-electronic/> <correu electronic/>
<element /> < element/>
<_Carai/> <%descompte/>
<svg:rectangle /> <xml-rectangle/>
La versió 1.1 d’XML permet

que siguin vàlids tota una
sèrie de caràcters extra per A pesar d’aquestes restriccions la llibertat que permet l’estàndard és prou impor-
adaptar-se a les noves
versions de Unicode, però tant.
en general no aporten res si
no fem servir algun idioma
asiàtic. Una de les coses que no s’ha d’oblidar mai és que un dels objectius d’XML és
fer que els documents amb XML puguin ser llegits i entesos fàcilment per les
persones i, per tant, es recomana que no es facin servir noms que no tinguin sentit
o que siguin difícilment entesos per una persona.
2.2.5 Comentaris
Sovint en els documents XML s’especifiquen dades extra que realment no formen
part del document. Aquestes dades s’anomenen comentaris i es fan servir per a
moltes coses diverses, com ara:
• Generar documentació sobre el document.
• Indicar a la gent que pugui rebre el document què es volia fer en crear-lo.
• Altres. Els analitzadors XML són

programes que, a partir de
l’estructura dels documents
XML, ens permeten l’accés
Generalment els analitzadors XML simplement solen descartar els comentaris, ja al contingut a partir de les
seves etiquetes.
que l’especificació XML diu que no cal que siguin processats. El més habitual sol ser
processar el document per
generar-ne una sortida que
Els comentaris s’especifiquen encloent-los entre els símbols  i es pugui ser visualitzada més
fàcilment, etc..
poden posar comentaris en qualsevol lloc del document XML excepte dins de les
etiquetes. Com a exemple, en el document següent s’ha inclòs el comentari “Llista
d’alumnes” per a indicar en quin lloc comença la llista d’alumnes:
1 <professors>
2 <nom>Marcel Alaba</nom>
3 </professors>
4 <!−− Llista d’alumnes −−>
5 <alumnes>
6 <nom>Frederic Garcia</nom>
7 <nom>Federicu Pi</nom>
8 </alumnes>
2.2.6 Instruccions de procés
Les instruccions de procés són una manera de donar instruccions als programes
que llegiran el document. Es defineixen dins dels símbols ”<?” i posteriorment
sempre s’hi ha d’especificar a quin programa van dirigides amb l’única restric-
ció que no poden ser les lletres “XML” en qualsevol combinació de majúscules o
minúscules.
Per tant, per afegir informació que vagi destinada a un programa anomenat php
s’han de definir les instruccions de procés amb una instrucció de procés:
1 <?php ... ?>
Aquest sistema permet que en un document XML es puguin afegir instruccions de

procés diferents per a programes diferents:
1 <?programa1 ... ?>

2 <?programa2 ... ?>
El contingut de les dades pot ser qualsevol cosa que tingui sentit per al programa
que les llegirà, i per tant no necessàriament ha de tenir sentit per als processadors
XML. Com que no formen part del document XML en si poden aparèixer en
qualsevol lloc del document excepte en mig d’una etiqueta.
2.3 Declaració XML
L’especificació és una línia que defineix una manera d’identificar que un document
és XML per mitjà d’una etiqueta especial anomenada declaració XML, que serveix
per indicar que un document és XML.
1 <?xml version="1.0"?>
La declaració XML és opcional, tot i que es considera recomanable, ja que

té alguns atributs que poden ajudar als programes a entendre característiques del
document com el codi de caràcters que s’hi fa servir, la versió d’XML que s’ha
usat, etc.
Si la declaració és present s’ha de tenir en compte que:
• La declaració ha d’estar en la primera línia del document i ha de començar

en el primer caràcter del document.
• Ha de tenir obligatòriament l’atribut version, que actualment només pot

ser 1.0 o 1.1.
Per tant, la declaració següent és errònia perquè deixa una línia en blanc, deixa
espais davant de la declaració i no defineix l’atribut version:
1 .
2 <?xml ?>
Com que la declaració és opcional podem trobar documents XML sense aquesta
declaració. Si això passa els programes que llegeixin el document han de suposar
que és tracta d’un document XML versió 1.0.
2.3.1 Atributs de la declaració XML
La declaració XML permet definir tres atributs (taula 2.4).
Taul a 2. 4. Atributs de la declaració XML
Atribut Objectiu Obligatori ?
version Defineix quina versió d’XML s’ha Sí

fet servir per crear el document.
Atribut Objectiu Obligatori ?
encoding Defineix el codi de caràcters que No

fa servir el document.
standalone Serveix per indicar si el document No

no depèn d’altres documents.
Atribut ”version”
L’atribut version serveix per especificar mitjançant quina versió d’XML s’ha
d’interpretar el document. Tot i que la definició XML és opcional, si hi és aquest
atribut esdevé obligatòria.
Per tant, si es carrega el document següent en un programa li estem donant

instruccions que ha de tractar el document segons les especificacions de la versió
1.1.
1 <?xml version="1.1" ?>

Si no s’especifica la definició o bé el valor és incorrecte els programes poden

ignorar el que hi hagi i suposar que la versió és la 1.0. Per tant, els dos documents
següents han de ser interpretats com a 1.0:

Atribut encoding
L’atribut encoding permet definir amb quin codi de caràcters s’han codificat les
dades.
Per defecte tots els programes que llegeixin XML han de poder interpretar els codis
de caràcters que estiguin en UTF-8 i UTF-16 i fins i tot detectar en quina de les
dues codificacions està fet el document. Això implica que si el document està creat
amb alguna d’aquestes codificacions no caldria especificar l’atribut encoding.
Tot i això, per motius de llegibilitat del document sovint s’hi especifica igualment. Com que l’estàndard ASCII
és un subconjunt d’UTF-8
els documents que estiguin
En canvi, si el document segueix alguna altra codificació l’atribut s’ha d’especifi- en ASCII tampoc no
requereixen cap declaració.
car explícitament. Per un document creat fent servir el codi de caràcters ISO-8859-
15 és obligatori tenir definit l’atribut que indiqui el codi de caràcters que s’ha fet
servir:
1 <?xml version="1.0" encoding="ISO−8859−15"?>
Es poden fer servir les abreviacions de codis de caràcters de la taula 2.5.

Taul a 2. 5. abreviacions de codis de caràcters acceptades per l’XML
Tipus Codis de caràcters
Unicode UTF-8, UTF-16, ISO-10646-UCS-2, i

ISO-10646-UCS-4
ASCII i variants ISO-8859-1, ISO-8859-2, ..., ISO-8859-n
JIS X-0208-1997 ISO-2022-JP, Shitf_JIS, EUC-JP

Vegeu la definició de
codificacions de l’IANA en
la secció “Adreces
d’interès” del web del Per a altres codis de caràcters es recomana fer servir els noms que defineix l’IANA
mòdul.
(www.iana.org/assignments/character-sets).
Si a pesar d’això el codi de caràcters que es fa servir no està en la llista s’ha de fer
començar el nom amb x-.
Atribut ”standalone”
Els documents d’esquemes poden fer que algunes de les etiquetes les hagin de
tractar de manera diferent els programes. Per exemple, definint atributs per defecte
en algunes etiquetes i que, per tant, no cal que siguin específicament declarades
en el document XML.
En la definició del vocabulari es pot definir que l’element <persona> té un atribut

versió que per defecte és home. En crear el document es podria definir l’etiqueta
sense especificar-ne l’atribut perquè el seu valor està implícit.
1 <persona>Joan</persona>
Si un programa tracta aquest document ha de tenir en compte aquest valor, i per

tant haurà de llegir el document que declara els atributs per defecte.
Amb l’atribut standalone s’està definint si el document XML es pot entendre

per si sol o bé necessita que sigui interpretat amb l’ajuda d’algun altre document,
i per aquest motiu només té dos valors possibles (taula 2.6).
Taul a 2. 6. Valors possibles de l’atribut standalone
Valor Significat
yes El document és complet, i per tant no li calen altres

documents per ser interpretat.
no El document no es pot entendre per si sol i n’hem de

llegir d’altres per poder-lo entendre.
Si l’atribut no s’especifica es considera que el valor de l’atribut standalone és

no.
2.4 Correctesa
Els programes d’ordinador no tenen la flexibilitat que tenen els documents XML
i necessiten poder treballar amb dades molt pautades, i precisament això és el
que intenten fer les regles, evitar que hi hagi parts del document que puguin
ser malinterpretades. Com que la majoria de les vegades els documents XML
hauran de ser llegits per programes, és molt important tenir alguna manera de
comprovar que aquest document XML estigui ben format, que compleixi les regles
de definició de l’XML.
Comprovar la correctesa d’un document XML és comprovar que no

s’incompleix cap de les regles de definició d’XML.
Es considera que un document és correcte o ben format si compleix amb les regles
bàsiques de creació d’un document XML. En general podem definir aquestes
regles com:
• Només hi pot haver un element arrel.
• Totes les etiquetes que s’obren s’han de tancar.
• Les etiquetes han d’estar imbricades correctament.
• Els noms de les etiquetes han de ser correctes.
• Els valors dels atributs han d’estar entre cometes.
2.4.1 Només hi pot haver un element arrel
En l’exemple següent:
1 <persona>
2 <nom>Pere</nom>
4 </persona>
L’etiqueta que surt en primer lloc, <persona>, i que acaba al final, </persona>,
defineix el que s’anomena element arrel. Que un element sigui arrel vol dir que
no té cap element que el contingui.
En aquest altre exemple, en canvi, hi ha dos elements arrel, <persona> i <gos>:
1 <persona>
3 </persona>
4 <gos>
5 <nom>Rufy</nom>
6 </gos>
Es pot veure que tant <persona> com <gos> no tenen cap element que els
contingui i, per tant, tots dos són elements arrel. Això fa que no sigui un
document XML ben format.
També hi ha dos elements arrel en el cas en què les etiquetes siguin les mateixes.
Per exemple, en el document següent tenim dos elements arrel <persona>. Per
aquest motiu, aquest document tampoc no està ben format.
1 <persona>
2 <nom>Pere</nom>
3 <cognom> Pérez </cognom>
4 </persona>
5 <persona>
6 <nom>Marià</nom>
8 </persona>
Si es volgués convertir el document anterior en un document ben format es podria

posar un element nou que englobés els dos elements arrel. Per exemple, s’hi
s’afegeix un element <persones> i així es crea un document XML ben format:
1 <persones>
2 <persona>
3 <nom>Pere</nom>
4 <cognom> Pérez </cognom>
5 </persona>
6 <persona>
7 <nom>Marià</nom>
9 </persona>
10 </persones>
2.4.2 Totes les etiquetes que s’obren s’han de tancar
A pesar del que passa en altres llenguatges de marques, per exemple HTML, en
l’XML totes les etiquetes que s’obrin han de ser tancades obligatòriament. Per
tant, aquest seria un exemple correcte:
1 <nom>Pere</nom>
Mentre que aquest no seria correcte:
1 <nom>Pere
En alguns moments pot caldre reflectir alguna dada que no requereixi cap valor.
Per exemple si tenim una llista d’alumnes ens podria interessar marcar quin d’ells
és el delegat. Per definir-ho no ens caldria cap dada, ja que simplement l’alumne
que tingui l’etiqueta <delegat> és el delegat. Per tant, per definir que en Frederic
Pi és el delegat podríem estar temptats de fer això:
1 <alumnes>
2 <alumne>
4 </alumne>
5 <alumne>
6 <nom>Frederic Pi</nom>
7 <delegat>
8 </alumne>
9 <alumne>
10 <nom>Maria Puigdevall</nom>
11 </alumne>
12 </alumnes>
Això és incorrecte. Si obrim una etiqueta l’hem de tancar; per tant, hauríem de
fer:
1 ...
2 <alumne>
4 <delegat></delegat>
5 </alumne>
6 ...
O bé fer servir la versió de definició d’etiquetes buides acabant l’etiqueta amb

”/>”:
1 ...
2 <alumne>
4 <delegat/>
5 </alumne>
6 ...
2.4.3 Les etiquetes han d’estar imbricades correctament
Per mantenir la jerarquia, l’XML defineix que les etiquetes no es poden tancar si
encara hi ha alguna etiqueta que forma part del contingut que no ha estat tancada.
Això és perquè no es permet que un element tingui una part del seu contingut en
un element i una altra part en un altre, ja que això trencaria la jerarquia de dades.
Tancament de les etiquetes
desordenat
Per tant, sempre que s’obri una etiqueta dins d’un element aquesta ha de ser Alguns llenguatges de marques
tancada abans d’acabar l’element. Aquest exemple seria correcte perquè l’element sí que permeten obrir i tancar les
etiquetes en qualsevol ordre. Per
<persona> en el seu contingut obre l’etiqueta <nom> però abans d’acabar tanca exemple, les versions anteriors a
la 4.0 d’HTML permetien obrir i
</nom>: tancar etiquetes en l’ordre que
volguéssim sempre que
s’acabessin tancant totes. Però a
1 <persona><nom>Pere</nom></persona> partir de la versió 4.0 ja no
s’accepta, a pesar que la majoria
dels navegadors sí que ho
permeten.
En canvi, si les etiquetes no es tanquen en l’ordre correcte, encara que es compleixi
la regla que s’han de tancar totes les etiquetes, no tenim un document XML ben
format.
1 <persona><nom>Pere</persona></nom>
En l’exemple que acabem de veure s’està creant un bucle, ja que <persona> conté
una part de <nom> i alhora <nom> conté una part de <persona>. Això trenca amb
la idea de jerarquia de les dades que defineix l’XML i, per tant, no és correcte.
Per facilitar l’escriptura de documents XML i minimitzar els possibles errors per
culpa de tancaments desordenats, els documents XML sovint es representen
Sagnia
sagnats.
La sagnia consisteix a escriure
les etiquetes de manera sagnada En l’XML la sagnia es fa en funció del nivell en què es troben les dades. En
en funció del seu nivell dins de
la jerarquia d’elements. A general cada un dels fills fa que s’incrementi la sagnia. Per exemple:
mesura que es van creant nous
elements dins d’altres es van
afegint sagnies. 1 <alumne>
2 <persona>
3 <nom>
4 </nom>
5 </persona>
6 </alumne>
Fent servir la sagnia és més fàcil determinar en quin lloc s’ha produït un error de
tancament d’etiquetes i arreglar-ho. Com podem veure en l’exemple següent, si
les etiquetes de tancament no estan en la mateixa columna que les d’obertura és
que hi ha alguna cosa malament.
1 <institut>
2 <classe>
3 <alumne>Pere</alumne>
4 <alumne>Joan</alumne>
5 </institut>
6 </classe>
En general la sagnia aporta dos avantatges a l’XML:
1. Evita que es cometin errors a l’hora de tancar les etiquetes.
2. Fa que sigui més fàcil veure d’un cop d’ull l’estructura del document.
2.4.4 Els noms de les etiquetes i dels atributs han de ser correctes
L’XML dóna molta llibertat a l’hora de definir els noms dels elements i dels
Vegeu l’apartat “Noms
vàlids XML” en aquest atributs però no tots els noms són acceptats.
apartat.
En general tindrem que:
• No es poden posar noms que no comencin per un caràcter ni que continguin

espais dins seu.
• Les majúscules i les minúscules són caràcters diferents per a XML.
• Els noms que comencin per xml estan reservats.
Per tant, seria incorrecte escriure una etiqueta en minúscules i després tancar-la
en majúscules:
1 <persona>Pere</Persona>
Els noms han d’estar escrits de la mateixa manera:

1 <persona>Pere</persona>
No es poden posar etiquetes ni atributs que comencin per xml perquè estan
reservats per l’estàndard.
En l’exemple següent hi ha un error en el nom de l’atribut xmlpersona:

1 <persona xmlpersona="si">Pere</persona>
De fet, ja hi ha alguns atributs començats per xml que s’accepten perquè estan
definits en l’estàndard i tenen un objectiu clar: xml:lang, xml:space, xmlns...
2.4.5 Els valors dels atributs han d’estar entre cometes
En l’apartat de definició dels atributs ja es comenta que els valors dels atributs
sempre han d’anar entre cometes però podem resumir el més important. Vegeu l’apartat “Atributs”
en aquest apartat.
No importa quines siguin les cometes que fem servir, dobles o simples, sempre
que es facin servir les mateixes en obrir que en tancar.
1 <classe nom="Llenguatges de marques">
2 <alumne delegat=’si’>Pere Garcia</alumne>
3 <alumne>Frederic Pi</alumne>
4 </classe>
Encara que el contingut dels atributs sigui un valor numèric s’ha d’especificar
entre cometes:
1 <alumne nota="10">Maria Puigdevall</nom>
Podem especificar tants atributs com calgui en una etiqueta i l’ordre en què
s’especifiquen no té importància:
1 <alumne nom="Pere" cognom="Garcia" nota="6" />
2.4.6 Processadors XML
L’objectiu principal de totes les regles que defineixen com s’ha d’escriure un
document XML és definir una manera d’escriure documents XML que puguin
ser llegits i interpretats per un programa d’ordinador. Els programes encarregats
de detectar si un document XML està ben format s’anomenen genèricament
processadors d’XML, tot i que sovint es fa servir el nom en anglès, parsers.
Un processador d’XML és un programa que permet llegir un document XML i

accedir-ne a l’estructura i a les dades que conté. Això ho fa llegint tot el document
i determinant quins dels caràcters que hi troba són part de l’estructura i quins són
realment dades.
Vocabularis
XML permet definir etiquetes sense cap restricció però en canvi els programes només
poden funcionar amb les etiquetes per les que han estat programats.
Per aquest motiu els programes defineixen quins conjunts d’etiquetes accepten. La llista
d’etiquetes que s’accepten en un determinat llenguatge s’anomenen vocabularis.
Generalment es classifiquen els processadors en dos grans grups:
• Processadors validadors: comproven que els documents compleixen les

regles i restriccions definides en l’esquema del vocabulari que se li ha
associat i, per tant, a part de la lectura del document XML també han de
llegir l’esquema contra el qual es valida.
• Processadors no validadors: revisen que el document no incompleix cap

de les normes i regles de definició d’XML.
Sempre que no es tingui cap tipus de definició de vocabulari associada a un

document XML es pot comprovar que el document és correcte amb un processador
que no validi. En canvi, si tenim el vocabulari ens caldrà un processador validador
que comprovarà que realment estem posant les etiquetes allà on poden anar.
Les tasques dels processadors XML es fan sempre abans que el programa que ha
de treballar realment amb les dades faci res. Per tant, el procediment sempre serà:
primer passar el document pel processador, i si el processador el dóna per correcte
llavors es passa al programa (figura 2.1).
F igu ra 2 .1 . Pas d’un document XML a un programa
Errors
A part de definir com s’han de crear els fitxers XML l’especificació també defineix
com han de reaccionar els processadors davant dels diferents errors que puguin
detectar en tractar un fitxer XML. Els errors es defineixen en dos grups:
• Errors lleus: els errors lleus són els que incompleixen alguna de les regles
definides com a recomanacions. Si algun document XML incompleix
alguna recomanació l’analitzador pot continuar analitzant el document
intentant recuperar-se de l’error.
• Errors greus: es generen quan s’incompleix alguna de les regles obligatò-

ries de l’especificació. Es defineix que en cas de trobar algun error greu
l’analitzador s’ha d’aturar immediatament i no continuar amb el procés
d’anàlisi. En general qualsevol error que faci que el document no sigui “ben
format” serà un error d’aquest tipus.
Navegadors web
Un cop s’ha creat un document XML normalment caldrà comprovar que aquest
document està ben format segons les regles d’XML fent servir un processador
XML.
La manera més senzilla de comprovar que un document està ben format és carregar-
lo des d’un navegador. La majoria dels navegadors porten un processador XML
incorporat i detecten automàticament que un document és XML i el comproven
(figura 2.2).
Figu ra 2. 2. Document correcte des d’un navegador
En cas de produir-se un error els navegadors mostren quin error s’hi ha produït i
en quina línia es troba l’error (figura 2.3).
F igu ra 2 .3 . En carregar un document XML incorrecte en el navegador

Google Chrome ens mostra els errors.
Processadors XML
En comptes de fer servir un navegador web per comprovar els documents XML
sovint es fa servir un processador. La majoria dels processadors formen part
de biblioteques que els programadors poden usar des dels seus programes per
carregar els documents XML i comprovar-los.
A vegades els processadors porten utilitats que permetran comprovar ràpidament

si un document està ben format o no sense haver de desenvolupar un programa per
fer-ho.
Volem destacar els processadors següents:
• libxml2
• Apache Xerces
• Expat
• MSXML
libxml2
libxml2 forma part del projecte Gnome i és un processador de codi obert que
està escrit en llenguatge C, però que es pot fer servir des de diferents llenguatges
de programació com Perl, Ruby, Python, C#, PHP... i des de diferents sistemes
operatius com Windows, Linux o Mac OS X. Està instal·lat per defecte en moltes
de les distribucions de Linux.
Entre les utilitats que inclou n’hi ha una que funciona des de l’entorn d’ordres,
anomenada xmllint, que és un analitzador i validador de documents XML.
Es pot comprovar si un document està ben format simplement especificant-lo com

a paràmetre. Per validar el document següent:
2 <persona>
3 <nom>Pere</nom>
4 </persona>
Executarem l’ordre:
1 $ xmllint persona.xml
Si el document és correcte mostrarà el document XML per pantalla (es pot evitar
aquest comportament amb el paràmetre –noout):
3 <persona>
4 <nom>Pere</nom>
5 </persona>
En el cas que hi hagi algun error es mostrarà per pantalla i donarà informació sobre
en quin lloc es troba i quin és l’error. Si modifiquem el document XML perquè
tingui un error:
1 <persona>
2 <nom>Pere
3 </persona>
Quan el passem a xmllint, aquest ens informarà que hi ha un error a la línia 3

perquè ha detectat que s’ha tancat <persona> però <nom> no està tancat.
2 persona.xml:3: parser error : Opening and ending tag mismatch: nom line 2 and
persona
3 </persona>
4 ^
5 persona.xml:4: parser error : Premature end of data in tag persona line 1
6 ^
També es pot fer servir xmllint per veure que els processadors intenten arreglar
els errors lleus que hi pugui haver en un document. Si eliminem la declaració
XML del document (no estem provocant cap error, ja que la declaració només és
una recomanació):
1 <persona>
2 <nom>Pere</nom>
3 </persona>
En passar-lo per xmllint es pot veure que ha detectat que la declaració no hi era i
l’ha afegida automàticament:
3 <persona>
4 <nom>Pere</nom>
5 </persona>
Apache Xerces
Sota el nom de Xerces la fundació Apache manté un projecte de desenvolupament
de processadors XML per a Java, C++ i Perl. Es tracta d’una de les biblioteques
més usades per processar XML.
Expat
XML Parser Toolkit són unes biblioteques per fer servir XML des del llenguatge
de programació C i Perl.
El fan servir alguns dels programes d’ús comú, com per exemple el servidor web
Apache HTTP Server, el navegador Mozilla i les biblioteques dels llenguatges de
programació Perl, Python i PHP.
Per exemple, en l’Ubuntu, en instal·lar la biblioteca, també s’instal·la un programa

anomenat xmlwf que permet comprovar si un document està ben format des de la
línia d’ordres. Si no diu res el fitxer està ben format.
1 $ xmlwf persona.xml
En cas d’error mostrarà en quina línia i columna es troba:
1 $ xmlwf persona.xml
2 persona.xml:3:2: mismatched tag
MSXML
Microsoft XML Parser és la biblioteca oficial per processar XML en molts dels
productes de Microsoft. Es tracta d’una biblioteca inclosa en el sistema operatiu, i
per tant s’actualitza via Windows Update. N’han anat sortint versions en què s’han
anat afegint funcions. Es pot fer servir des de diferents llenguatges de programació,
llenguatges de scripts o des de llenguatges basats en .NET
Fan servir MSXML productes com Microsoft Windows, Microsoft Office, Micro-
soft SQL Server, Microsoft Internet Explorer...
Molts dels programes que processen XML en sistemes Windows solen fer servir
aquesta biblioteca (especialment si treballen en .NET).
Com que Internet Explorer fa servir aquesta biblioteca, simplement carregant

un document XML amb Internet Explorer en realitat s’està comprovant amb
l’MSXML (figura 2.4).
F igu r a 2. 4 . L’Internet Explorer ens permet comprovar documents amb l’MSXML

2.5 Estructura dels documents XML
Una de les coses que s’aconsegueixen en forçar que els documents XML segueixin
les seves normes és fer que la informació que conté un document s’organitzi de
manera jeràrquica.
Per exemple, tenim el document XML següent:
1 <?xml versión="1.0" encoding="UTF−8" ?>

2 <classe>
3 <professor>
4 <nom>Marcel</nom>
6 </professor>
7 <alumnes>
8 <alumne>
9 <nom>Filomeno</nom>
11 </alumne>
12 <alumne>
13 <nom>Frederic</nom>
14 <cognom>Pi</cognom>
15 </alumne>
16 <alumne>
17 <nom>Manel</nom>
18 <cognom>Puigdevall</cognom>
19 <delegat/>
20 </alumne>
21 </alumnes>
22 </classe>
Gràcies al fet que les etiquetes tenen noms clars es pot deduir que en aquest
document XML s’estan definint estructuradament una classe amb un professor
i tres alumnes. Hi ha un element arrel anomenat <classe> que engloba tot el
document, i com a contingut té dos elements més, <professor> i <alumnes>.
Els elements que formen part del contingut d’un node s’anomenen fills.
Per tant, <classe> té dos elements fills: <professor> i <alumnes>. Alhora

l’element <professor>, que és un dels fills de <classe>, també té dos fills:
<nom> i <cognom>.
1 ...
2 <professor>
3 <nom>
4 Marcel
5 </nom>
6 <cognom>
7 Puig
8 </cognom>
9 </professor>
10 ...
Per equivalència amb les relacions humanes els fills dels fills d’un element
s’anomenen néts. Per tant, <nom> i <cognom> són fills de <professor> i néts
de classe:
classe -> professor -> nom Els elements <nom> i <cognom> no tenen nodes fills
sinó que contenen les dades del document. En aquest cas dues cadenes de text
Marcel i Puig. Els nodes finals s’anomenen fulles i generalment seran sempre
nodes de dades.
Es pot fer amb l’altre element fill de <classe>, però amb la diferència que té un
nivell més. Ara es té una estructura més llarga:
classe -> alumnes -> alumne -> nom Tots els elements que pengen d’un element
s’anomenen genèricament descendents. Per tant, <alumnes>, <alumne> i <nom>
són descendents de <classe>.
Com podeu veure, és relativament senzill interpretar quines són les dades que
conté un document XML, gràcies al fet que es fan servir noms d’etiqueta que
tenen sentit per a un possible lector, però també es pot deduir quina és l’estructura
de les dades i les relacions que tindran aquestes dades entre si.
El fet de seguir aquest sistema, que és flexible en determinats moments, però

estricte en d’altres, ens permet fer que un programa d’ordinador també pugui de
manera senzilla detectar ràpidament quina part del document són dades i quina
són metadades, però que a més pugui establir quina és la relació entre aquestes
dades.
En cap moment no s’ha especificat res sobre de quina manera s’hauran de

representar les dades, ja que aquesta és una de les bases fonamentals del llenguatge
XML:
L’objectiu de l’XML és representar l’estructura de les dades oblidant-se de

com es farà per presentar-les.
2.5.1 Representació en forma d’arbre
Una de les característiques interessants dels documents XML és que, en tenir les
dades estructurades de manera jeràrquica, aquesta jerarquia fa que els documents
XML puguin ser representats gràficament en forma d’arbre. La representació en
arbre és útil per comprendre millor quina és l’estructura del document.
Per fer la representació en forma d’arbre sempre es parteix del node arrel, que en
aquest cas és classe (figura 2.5).
Fi g ura 2. 5 . Es comença
definint l’element arrel com un
node
A partir del node arrel s’agafen els fills directes que tingui i s’enllacen amb un arc,
que serà el que indicarà la relació que tenen els elements entre ells (figura 2.6).
Fig ur a 2 . 6 . S’hi afegeixen els fills
El mateix es pot fer per als fills de cada un dels nodes. Per exemple, professor
té dos fills més, que són nom i cognom, que s’uniran a professor amb un arc per
indicar que tenen relació pare/fill (figura 2.7). De fet, es fa és més o menys el
mateix que es faria per crear un arbre genealògic.
Fig ur a 2 . 7 . I es va fent el mateix amb els fills de cada

node
Com que ja no hi ha més elements per representar ja es poden pintar els nodes de
dades, que generalment s’acostumen a pintar de color diferent (figura 2.8).
Fig ur a 2 . 8 . Els nodes de dades se solen representar

d’una manera especial
Si se segueix amb el document el resultat serà un arbre que ens representarà

gràficament la relació que tenen els elements entre si (figura 2.9).
Fig u ra 2 . 9 . El resultat és la representació del document en forma d’arbre
2.5.2 Representació en els navegadors
Una representació semblant a la de l’arbre és la que han triat els navegadors per
mostrar els documents XML si no els diem el contrari afegint-hi algun full d’estil.
Quan s’obre un document XML en un navegador automàticament és representa
sagnat i s’hi afegeixen nodes davant dels elements pares que permetran mostrar o
ocultar els fills que conté (figura 2.10).
F igu ra 2 . 1 0 . Representació d’un document XML correcte en el navega-

dor Mozilla Firefox
En la vista d’arbre que ofereixen els navegadors normalment es poden plegar i

desplegar els fills dels nodes per poder personalitzar la visió del document (figura
2.11).
F igur a 2. 11 . El Firefox permet plegar i desplegar els fills dels nodes
2.6 Creació de documents XML
Generalment els documents XML seran creats i llegits des de programes d’or-
dinador, però algunes vegades també es pot donar el cas que s’hagin de crear
manualment.
Crear un document XML manualment és molt més senzill que crear un document
binari, ja que no difereix gaire de crear un document de text. Simplement
necessitem un editor de text que no enriqueixi el text.
2.6.1 Editors
Els documents XML són simples documents de text en què hem afegit algun tipus
de metadades. Això permet que la creació de documents XML sigui realment
senzilla, ja que es pot fer servir l’editor més senzill que trobem en qualsevol
sistema operatiu per poder crear els nostres documents.
A pesar d’això també han aparegut tota una sèrie d’editors pensats per fer l’edició
de documents XML més senzilla. Aquests editors són molt diversos i normalment
ofereixen diferents tipus d’assistència per evitar que es cometin errors en crear el
document: comprovar interactivament que el document sigui correcte, aconsellar
etiquetes, acolorir...
Molts dels editors especialitzats en XML normalment a més ofereixen moltes

altres funcions com generació d’expressions XPath, creació de fulls d’estil,
depurament de transformacions, peticions XQuery...
Editors de text
L’única cosa que cal per crear un document XML és un editor de text normal
i corrent que no enriqueixi el text. Els documents de text que permeten afegir
format, com ara text en negreta, canviar el tipus de lletra, etc., com per exemple
el Microsoft Word, l’OpenOffice.org Writer, el LibreOffice Writer, etc., solen
generar documents de text enriquit que es concentren més en com s’ha de mostrar
el document que no pas en les dades. A més, aquests programes sovint canvien
automàticament alguns caràcters del text que anem escrivint (les cometes solen
ser canviades sistemàticament) per fer-lo més “agradable” a l’hora d’imprimir-lo,
com es pot veure a la figura 2.12.
F igu ra 2 .1 2 . L’OpenOffice.org modifica les cometes per fer-les més

“agradables” a la vista
Per tant, aquests programes no són els més adequats per crear documents XML,
tot i que és possible fer-ho si a l’hora de desar els documents es va amb compte
d’especificar que es volen desar com a “text” (figura 2.13).
F igu r a 2. 1 3 . Es pot fer servir l’OpenOffice.org però anant en compte a l’hora de desar el document
La realitat és que per crear documents XML van molt millor els editors més
senzills (Gedit, Bloc de notes, vi, etc.) que no pas els editors de text enriquit.
En alguns casos aquests editors més senzills fins i tot detecten que s’està editant
un document XML i marquen amb colors diferents les etiquetes i les dades (figura
2.14).
Fi g ura 2 .14 . L’editor Gedit de Gnome fins i tot ofereix acoloriment de text en els fitxers
XML
Editors amb suport d’XML
També hi ha un segon grup d’editors que, tot i no estar especialitzats en XML,

hi poden tenir suport. Aquests editors normalment ofereixen una assistència
mínima en editar XML, com acoloriment de les diferents seccions, comprovació
automàtica del tancament de les etiquetes, o fins i tot se’n poden trobar amb
autocompletament d’etiquetes.
Aquest comportament és típic dels editors pensats per ser usats pels programadors,
com per exemple el Komodo IDE (figura 2.15), l’Eclipse o el Visual Studio.
L’èxit d’XML ha fet que alguns editors hagin incrementat el seu suport per a XML.
Per exemple, les noves versions del Microsoft Visual Studio a més de l’autocom-
pletament d’etiquetes permeten definir esquemes i depurar transformacions des de
l’entorn integrat (figura 2.16).
F igu ra 2 . 1 5 . Molts dels editors dels entorns de programació ofereixen

suport als documents XML. Per exemple, l’editor de codi obert Komodo
Fig u ra 2. 16 . Microsoft ha afegit al Visual Studio suport per a diverses tecnologies XML
Editors especialitzats en XML
Tot i que amb els altres editors es poden crear documents XML, quan es vol fer
un treball professional normalment s’ha d’acabar recorrent a un editor d’XML.
Aquests editors estan dissenyats específicament per crear i editar documents XML
de manera eficient i senzilla minimitzant les possibilitats que es cometin errors
en l’edició. Generalment tots ofereixen un entorn amb un grup de finestres amb
diferents vistes de l’edició per intentar que no es perdi la visió de conjunt del que
s’està creant (figura 2.17).
Fi gura 2.1 7 . L’editor EditiX ens va creant l’arbre XML alhora que anem escrivint el
document XML
A part de la simple edició de documents XML, aquests editors permeten tot un

ampli ventall de tasques amb les tecnologies relacionades amb l’XML com editar
documents XML restringint les etiquetes que s’hi fan servir; definir un esquema;
crear, convertir i depurar esquemes XML, XSLT, XPath, XQuery, WSDL, SOAP...
També ofereixen ajudes per crear documents en vocabularis basats en XML, etc.
Una característica interessant que ofereixen és la possibilitat d’editar documents

XML des de diferents punts de vista. El més corrent sol ser fer-ho per mitjà de
vistes de text o diferents vistes gràfiques destinades a amagar la complexitat dels
documents XML als usuaris que fan servir l’editor.
L’edició en la vista de text (figura 2.18) no sol diferir gaire de l’edició en un editor
normal i corrent però sol oferir alguns avantatges afegits com autocompletament
d’etiquetes, acoloriment del contingut, finestres d’ajuda que mostren l’estructura
del document, etc.
F igur a 2. 18. La vista de text és la ideal per editar els arxius veient clarament el format XML
A part de l’edició de text molts editors també ofereixen vistes que permeten que un
usuari pugui crear dades estructurades de manera gràfica sense que l’usuari ni tant
sols sàpiga que està creant un document XML. Una d’aquestes vistes alternatives
és la vista d’arbre (figura 2.17). La vista d’arbre permet editar el document
visualment a partir de l’estructura jeràrquica, de manera que no cal que el que està
creant l’arbre conegui la sintaxi XML. Mentre l’usuari va creant l’arbre, l’editor
en segon pla va creant el document XML corresponent (figura 2.19 i figura 2.20).
F igu r a 2 . 1 9. L’usuari va creant les dades de manera estructurada i l’editor crea el document XML per
ell
F igu r a 2. 2 0 . La vista d’arbre està pensada per als usuaris que no coneixen el llenguatge XML
Amb la mateixa idea de fer que l’edició dels documents XML sigui més fàcil per
als usuaris no especialitzats, també hi ha la vista de graella (figura 2.21).
F igu r a 2. 2 1 . Vista de graella
La vista de graella està pensada per a usuaris que només es volen preocupar de l’estructura del document i no de com crear-lo.
La popularitat del format XML està fent que el nombre d’editors especialitzats
no pari de créixer i que per tant es faci difícil triar l’editor que s’adapta més bé a
les necessitats que un usuari pugui tenir. Afortunadament la majoria dels editors
comercials ofereixen un temps de prova abans d’obligar a comprar el programa, i
per tant es poden provar diferents editors abans de decidir quin és el que s’adapta
millor a les necessitats que tenim. A més, alguns editors tenen versions limitades
gratuïtes o de codi obert que en molts casos poden ser suficients per satisfer les
necessitats que es puguin tenir.
Entre els editors comercials normalment es destaquen aquests:
• oXygen XML Editor (Windows, Linux, Mac OS X)
• Editix XML Editor (Windows, Linux, Mac OS X)
• Altova XMLSpy XML editor (Windows)
• Stylus Studio (Windows)
• XMLmind (Windows, Linux, Mac OS X)
• XMLwriter (Windows)
• Liquid XML Studio (Windows)
• Serna Enterprise XML Document Editor (Windows, Linux, Mac OS X,

Solaris)
També n’hi ha algun de codi obert però sovint les seves prestacions solen ser molt
inferiors:
• Serna Free Open Source XML Editor (Windows, Linux, Mac OS X,

Solaris)
A pesar que en l’exemple es
fa servir l’oXygen, la majoria
dels editors funcionen d’una
• XML Copy Editor (Linux) manera similar.
Edició d’un document amb un editor d’XML

Si bé és cert que podem crear un document XML amb un editor de text senzill, en
aquest exemple es farà servir un editor especialitzat per veure’n les possibilitats.
L’editor que farem servir per fer l’exemple és l’oXygen XML Editor.
Generalment els editors d’XML divideixen l’espai de treball en finestres en les

quals cada una té una funció específica (figura 2.22).
F igu r a 2. 2 2 . Pantalla inicial de l’oXygen XML Editor, on es veuen els diferents espais
A l’hora de crear un fitxer nou els editors d’XML normalment obren un assistent
(figura 2.23) que permet crear fitxers de diversos tipus, de manera que un cop se
n’ha triat un se li afegiran automàticament les opcions predeterminades del tipus
de document triat.
F i g ura 2 . 2 3 . Assistent de creació d’arxius de l’oXygen
En crear un document XML s’afegeix la capçalera XML automàticament (figura

2.24).
Figur a 2. 24. Document XML creat per l’assistent d’oXygen
En editar, un assistent anirà oferint les possibilitats que consideri adients en cada
punt concret (figura 2.25).
Fig ura 2 . 25 . L’assistent d’edició ens indicarà què podem escriure en cada punt del
document
L’edició no té secrets, ja que el que es fa és simplement editar un arxiu de text amb

un assistent que ofereix ajudes diverses:
• En crear una etiqueta d’obertura es crearà l’etiqueta de tancament.
• Mentre s’edita es van comprovant automàticament els errors que sorgeixin.
• Hi sol haver alguna manera de comprovar si un document està ben format,

i un panell en el qual es poden veure els errors (figura 2.26).
Fi g ura 2 .26 . Els errors en l’edició
Els errors en l’edició són detectats per l’editor en escriure o bé quan li demanem que comprovi si el document
està ben format.
2.6.2 Creació d’un document XML
A l’hora de definir un grup de dades dins d’un document XML caldrà fer tota
una sèrie de passes prèvies que permetin determinar quines són les dades que cal
emmagatzemar i posteriorment definir quina és l’estructura que s’ha de donar a
aquestes dades; així doncs:
1. Determinació de les dades
2. Determinació de l’estructura
Determinació de les dades
És bàsic abans de crear un document XML saber clarament quines són les dades
que s’hi han de posar. Sovint això estarà determinat pel programa que les ha de
processar posteriorment, però també pot ser que el programa encara no existeixi i
per tant la creació estigui determinada per les preferències personals, etc.
Si no s’està restringit per un programa que ja determini l’estructura del document

XML, el que cal és determinar quines dades s’han d’emmagatzemar. Hi ha
molts sistemes per fer-ho però el més senzill és fer una llista amb totes les dades
rellevants.
Document XML per desar les dades d’una biblioteca
Volem crear una biblioteca en què es puguin emmagatzemar les dades dels llibres que
hi ha. Per tant, fem una llista amb les dades que considerem que cal que hi hagi en el
document:
• Títol
• Subtítol
• Autor
• Any de publicació
• Editorial
• Nom de la col·lecció
• Idioma
Determinació de l’estructura
Una altra de les coses bàsiques a l’hora de crear un document XML és definir
quina és l’estructura que hauran de tenir les dades. Aquesta estructura estarà
determinada per les necessitats del programa o de la persona que farà servir el
document XML. De manera que les possibilitats a l’hora de crear una estructura
per a les dades que volem fer servir són moltes: agrupar per autor, agrupar per
llibre, agrupar per editorial, agrupar per tema...
Tria de l’estructura
En una biblioteca podem fer l’estructura des de molts punts de vista. Per exemple, la podem
fer a partir dels autors, com aquesta:
• autor 1
– llibre 1
– llibre 2
• autor 2
– llibre 1
• etc.
O bé podem la fer a partir dels llibres d’aquesta manera:
• llibre 1
– autor 1
• llibre 2
– autor 1
• etc.
La primera opció és la que s’ha triat per desenvolupar en aquest exemple.
Creació del document
Com que s’ha triat una forma d’organització per mitjà dels autors el que queda clar
és que el primer nivell serà una llista d’elements autor més o menys d’aquesta
manera:
1 <biblioteca>
2 <autor></autor>
3 <autor></autor>
4 <autor></autor>
5 ...
6 </biblioteca>
Dins de cada un dels autors les dades per emmagatzemar seran les dades personals
de l’autor (el nom, en el nostre exemple) i la llista dels llibres de l’autor que hi hagi
a la biblioteca:
1 <autor>
2 <nom>Nom de l’autor</nom>
3 <llibres>
4 Llista de llibres
5 </llibres>
6 </autor>
En el darrer nivell es poden posar totes les dades del llibre obviant les que ja
estan implícites perquè estan en etiquetes superiors. En l’exemple, l’autor ja queda
implícit i, per tant, no cal tornar-lo a posar:
1 <llibre>
2 <titol>Titol del llibre</titol>
3 <subtitol>Subtítol</subtitol>
4 <any>Any en què s’ha publicat el llibre</any>
5 <idioma>Idioma en què està escrit</idioma>
6 <editorial>
7 <nom>Nom de l’editorial</nom>
8 <col · lecció>Adreça de l’editorial</col · lecció>
9 </editorial>
10 </llibre>
En qualsevol moment es poden crear nivells nous per agrupar les dades segons
algun sentit que interessi marcar. Per exemple, això és el que s’ha fet amb
l’editorial.
Cal tenir en compte que no cal preocupar-se gaire que en alguns casos les dades
no tinguin sentit o no existeixin, ja que en crear el document simplement es poden
eliminar les etiquetes que no tinguin sentit.
Per tant, el document final podria quedar d’aquesta manera:
1 <biblioteca>
2 <autor>
3 <nom>John Ronald Reuel Tolkien</nom>
4 <llibres>
5 <llibre>
6 <titol>El Hòbbit</titol>
7 <any>2010</any>
8 <idioma>català</idioma>
9 <editorial>
10 <nom>Edicions de la magrana</nom>
11 <col · lecció>L’Esparver</col · lecció>
12 </editorial>
13 </llibre>
14 <llibre>
15 <titol>El senyor dels anells</titol>
16 <subtitol>La germandat de l’anell</subtitol>
17 <any>2002</any>
19 <editorial>
20 <nom>Editorial Vicens Vives</nom>
21 </editorial>
22 </llibre>
23 </llibres>
24 </autor>
25 <autor>
26 <nom>Isaac Asimov</nom>
27 <llibre>
28 <titol>Jo, robot</titol>
29 <any>2001</any>
31 <editorial>
32 <nom>Edicions Proa</nom>
33 <col · lecció>Proa Butxaca</col · lecció>
34 </editorial>
35 </llibre>
36 </autor>
37 </biblioteca>
2.7 Espais de noms
Amb l’XML es poden crear les etiquetes amb el nom que es vulgui en el moment
en què calguin. Per tant, si tenim un document XML en el qual s’especifiquen
habitacions de lloguer podríem tenir un document com aquest:
1 <lloguer>
2 <adreca>
3 <carrer>Escudillers, 23</carrer>
5 <codi_postal>17600</codi_postal>
6 </adreca>
7 <habitacio>
8 <rect>
9 <finestres>2</finestres>
10 <portes>1</portes>
11 </rect>
12 </habitacio>
13 </lloguer>
O sigui, en el darrer document XML estem especificant que hi ha una habitació de

lloguer al carrer Escudillers, 23, de Figueres, que té forma rectangular amb dues
finestres i una porta.
Tot i que teòricament el sistema sembla perfecte, en la pràctica té el problema que

el llenguatge humà és limitat i a més moltes vegades hi ha paraules amb diversos
sentits. Això fa que molta gent pugui triar les mateixes etiquetes per fer coses que
siguin totalment diferents. Això d’entrada no és un problema fins que cal mesclar
documents que vénen de fonts diferents.
En XML hi ha un llenguatge estàndard que serveix per representar gràfics 2D

anomenat SVG (scalable vector gràfics). SVG serveix per definir gràfics vectorials,
o sigui, que en comptes de desar els punts que formen les imatges es desa com
s’han de dibuixar els gràfics fent servir figures geomètriques. Es poden veure
alguns dels elements de SVG a la taula 2.7.
Taul a 2. 7. Etiquetes bàsiques del format SVG per representar gràfics vectorials
Etiqueta Ús
svg L’arrel dels documents SVG.
line Serveix per definir línies d’un punt a un altre.
rect Es fa servir per definir rectangles a partir de quatre

punts.
circle Amb aquesta etiqueta es defineixen cercles a partir

del punt central i el radi.
ellipse Ens permet definir el·lipses a partir del punt central i

els dos radis.
polygon Permet dibuixar polígons a partir d’un grup de punts.
Per tant, algú podria decidir que el document milloraria si s’hi afegeix una
representació gràfica de la planta dels pisos, i que es pot aprofitar el llenguatge
SVG per fer-la.
Com que l’XML permet mesclar diferents vocabularis, simplement s’hi afegeix.
Per fer-ho més estructurat, a més, s’ha definit l’etiqueta <imatge>:
1 <lloguer>
2 <adreca>
6 </adreca>
7 <habitacio>
8 <rect>
11 </rect>
12 </habitacio>
13 <imatge>
14 <svg>
15 <rect x="0" y="0" width="30" height="60" />
16 </svg>
17 </imatge>
18 </lloguer>
Per un a lector humà en llegir-ho no hi hauria cap problema perquè ràpidament pot
detectar que la imatge està dins de l’element <imatge>, però per a un programa,
determinar si l’etiqueta és del vocabulari original o bé d’SVG, és pràcticament
impossible. Això vol dir que cal algun sistema de poder definir a quin vocabulari
pertanyen les etiquetes. Això és el que fan els espais de noms.
Els espais de noms permeten mesclar llenguatges XML en el mateix

document i a més definir clarament a quin vocabulari pertany cada etiqueta.
El que fan els espais de noms és canviar els noms de les etiquetes perquè siguin
únics. En teoria es podria fer servir qualsevol combinació de caràcters, però
com que hi hauria el mateix problema que amb les etiquetes (algú les podria
usar) generalment es fa per mitjà d’una URL (uniform resource locator), que en
principi són úniques. Així es podria definir una URL única al nostre espai de
noms (http://www.ioc.cat/lloguer) i la URL d’SVG (http://www.w3.org/2000/
svg) davant dels elements i el programa ja no tindrà problemes per determinar
a quin vocabulari pertany cada etiqueta:
1 <http://www.ioc.cat/lloguer:lloguer>
2 <http://www.ioc.cat/lloguer:adreça>
3 <http://www.ioc.cat/lloguer:carrer>Escudillers, 23</http://www.ioc.cat/
lloguer:carrer>
4 <http://www.ioc.cat/lloguer:ciutat>Figueres</http://www.ioc.cat/
lloguer:ciutat>
5 <http://www.ioc.cat/lloguer:codi_postal>17600</http://www.ioc.cat/
lloguer:codi_postal>
6 </http://www.ioc.cat/lloguer:adreca>
7 <http://www.ioc.cat/lloguer:habitacio>
8 <http://www.ioc.cat/lloguer:rect>
9 <http://www.ioc.cat/lloguer:finestres>2</http://www.ioc.cat/
lloguer:finestres>
10 <http://www.ioc.cat/lloguer:portes>1</http://www.ioc.cat/
lloguer:portes>
11 </http://www.ioc.cat/lloguer:rect>
12 </http://www.ioc.cat/lloguer:habitacio>
13 <http://www.ioc.cat/lloguer:imatge>
14 <http://www.w3.org/2000/svg:svg>
15 <http://www.w3.org/2000/svg:rect x="0" y="0" width="30" height="60"

/>
16 </http://www.w3.org/2000/svg:svg>
17 </http://www.ioc.cat/lloguer:imatge>
18 </http://www.ioc.cat/lloguer:lloguer>
Com que escriure totes les adreces cada vegada fa que es perdi la llegibilitat del
document, l’XML permet definir àlies per a cada una de les URL. Els àlies es
defineixen per mitjà de l’atribut xmlns dels elements i s’hereten a tot el contingut
de l’element:
1 <element xmlns:alies="http://adreca"/>
Per tant, si es defineix l’atribut en l’arrel del document s’heretaran els àlies a tots
els elements del document.
1 <lloguer xmlns:lloguer="http://www.ioc.cat/lloguer"
2 xmlns:svg="http://www.w3.org/2000/svg" >
3 <lloguer:adreca>
4 <lloguer:carrer>Escudillers, 23</lloguer:carrer>
5 <lloguer:ciutat>Figueres</lloguer:ciutat>
6 <lloguer:codi_postal>17600</lloguer:codi_postal>
7 </lloguer:adreca>
8 <lloguer:habitacio>
9 <lloguer:rect>
10 <lloguer:finestres>2</lloguer:finestres>
11 <lloguer:portes>1</lloguer:portes>
12 </lloguer:rect>
13 </lloguer:habitacio>
14 <lloguer:imatge>
15 <svg:svg>
16 <svg:rect x="0" y="0" width="30" height="60" />
17 </svg>
18 </lloguer:imatge>
19 </lloguer:lloguer>
xmlns també permet un espai de noms per defecte i que, per tant, podrà fer
servir les seves etiquetes sense àlies. Si algun atribut xmlns no defineix àlies
es converteix en l’espai de noms per defecte.
1 <lloguer xmlns="http://www.ioc.cat/lloguer"
2 xmlns:svg="http://www.w3.org/2000/svg" >
3 <adreca>
7 </adreca>
8 <habitacio>
9 <rect>
12 </rect>
13 </habitacio>
14 <imatge>
15 <svg:svg>
16 <svg:rect x="0" y="0" width="30" height="60" />
17 </svg:svg>
18 </imatge>
19 </lloguer>
Com que els espais de noms es poden definir en qualsevol element, una possibilitat
alternativa seria definir els espais de noms en les etiquetes adequades:
1 <lloguer xmlns="http://www.ioc.cat/lloguer">
2 <adreca>
6 </adreca>
7 <habitacio>
8 <rect>
11 </rect>
12 </habitacio>
13 <imatge>
14 <svg xmlns="http://www.w3c.org/2000/svg">
15 <rect x="0" y="0" width="30" height="60" />
16 </svg>
17 </imatge>
18 </lloguer>
D’aquesta manera tots els descendents de l’element <lloguer> segueixen el seu

espai de noms excepte quan s’arriba a l’element <svg>, el qual canvia l’espai de
noms per defecte per a ell i per als seus descendents.
Transmissió d'informació per
mitjà del web. Mecanismes de
validació de documents XML
Xavier Sala

d’informació
Transmissió d'informació per mitjà del web.
Llenguatges de marques i sistemes de gestió d’informació Mecanismes de validació de documents XML
Índex
Introducció 5
1 Utilització dels llenguatges de marques en entorns web 9

1.1 Cascading style sheets (CSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.1 Navegadors web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.2 Associar un full d’estil a un document . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.3 Regles CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.4 Model de caixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.1.5 Propietats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.1.6 Amagar contingut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.1.7 Afegir contingut a l’XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.1.8 Validació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.2 HTML / XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
1.2.1 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1.2.2 Convertir d’HTML a XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.2.3 Eines de disseny web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2 Definició d’esquemes i vocabularis en XML 65

2.1 Validació de documents XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.2 Processadors d’XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.2.1 Biblioteques per validar XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.2.2 Programes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.3 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.3.1 Associar una DTD a un document XML . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.3.2 Definició d’esquemes amb DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.3.3 Limitacions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.3.4 Exemple de creació d’una DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.4 W3C XML Schema Definition Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.4.1 Associar un esquema a un fitxer XML . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.4.2 Definir un fitxer d’esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.4.3 Exemple de creació d’un XSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.5 Conversió entre esquemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
2.5.1 Trang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Llenguatges de marques i sistemes de gestió d’informació 5 Mecanismes de validació de documents XML
Introducció
Els llenguatges basats en XML estan pensats per ser usats per màquines però sense
oblidar que també se n’ha de facilitar la lectura per als humans. En aquesta unitat
es veuran tecnologies destinades a facilitar la visualització de les dades en fitxers
basats en XML i a facilitar-ne l’ús per part dels programes.
Els documents XML no estan pensats per ser visualitzats pels humans però algunes
tecnologies en faciliten la visualització. L’apartat “Utilització dels llenguatges de
marques en entorns web” consistirà a mostrar sistemes per a la representació de
documents en formats més “amigables” per als humans, com són CSS i XHTML.
En l’apartat “Definició d’esquemes i vocabularis en XML” veureu que a pesar de

la llibertat que donen els llenguatges de marques a l’hora de crear elements perquè
puguin ser usats per programes caldrà restringir-los d’alguna manera. Veureu els
dos vocabularis més importants destinats a restringir quines són les etiquetes que
s’hi poden fer servir: DTD i XML Schemas.
En acabar aquesta unitat, l’alumne:
1. Utilitza llenguatges de marques per a la transmissió d’informació per mitjà

del Web analitzant l’estructura dels documents i identificant-ne els elements
• Identifica i classifica els llenguatges de marques relacionats amb el

Web i les seves versions diferents.
• Analitza l’estructura d’un document HTML i identifica les seccions
que el componen.
• Reconeix la funcionalitat de les principals etiquetes i atributs del
llenguatge HTML.
• Estableix les semblances i diferències entre els llenguatges HTML i
XHTML.
• Reconeix la utilitat d’XHTML en els sistemes de gestió d’informació.
• Utilitza eines en la creació del web.
• Identifica els avantatges que aporta la utilització de fulls d’estil.
• Aplica fulls d’estil.
2. Estableix mecanismes de validació per a documents XML utilitzant mèto-

des per definir-ne la sintaxi i estructura.
• Estableix la necessitat de descriure la informació transmesa en els

documents XML i les seves regles.
• Identifica les tecnologies relacionades amb la definició de documents
XML.
• Analitza l’estructura i sintaxi específica utilitzada en la descripció.
• Crea descripcions de documents XML.
• Utilitza descripcions en l’elaboració i validació de documents XML.
• Associa les descripcions de documents XML amb els documents
XML.
• Utilitza eines específiques de validació.
• Documenta les descripcions de documents XML.
1. Utilització dels llenguatges de marques en entorns web
A l’hora de crear documents XML només cal preocupar-se de les etiquetes, de

l’estructura dels documents i de comprovar que el document compleixi les normes
del vocabulari correcte, però no de com es veuran aquestes pàgines.
Tot això està bé perquè un dels objectius principals és fer que els programes puguin
interpretar les dades que contenen els documents. Alhora, si s’han seguit les
recomanacions qualsevol persona amb una mica d’esforç també podrà interpretar
les dades que conté el document.
XML està pensat perquè un usuari pugui entendre les dades però no per ser llegides
còmodament. Algú que no sigui expert en informàtica, en intentar veure les dades
d’un document no espera veure això:
1 <?xml version="1.0" encoding="UTF−8"?>

2 <?xml−stylesheet type="text/css" href="notes.css" ?>
3 <institut nom="Institut Cendrassos">
4 <cicles>
5 <especialitat nom="Informàtica">
6 <cicle id="ASIX">
7 Administració de Sistemes Informàtics i Xarxes
8 </cicle>
9 <cicle id="SMX" >
10 Sistemes Microinformàtics i Xarxes
11 </cicle>
12 </especialitat>
13 </cicles>
14 <notes>
15 <classe nom="ASIX">
16 <alumne aprovat="NO"><nom>Jaume Capmany</nom></alumne>
17 <alumne aprovat="SI"><nom>Mohamed Polih</nom><nota>5</nota></alumne
>
18 <alumne aprovat="SI"><nom>Juan Pérez</nom><nota>6</nota></alumne>
19 <alumne aprovat="SI"><nom>Frederic Pi</nom><nota>5</nota></alumne>
20 ...
Per contra, el que aquest usuari espera trobar-se és més aviat una cosa com la de
la figura 1.1.
Fi gu ra 1 . 1 . Document XML amb un estil aplicat

Si bé és cert que hi ha vocabularis XML pensats per ser representats, com SVG
(figura 1.2) o MathXML, aquests llenguatges no estan pensats per representar
informació general sinó per representar camps concrets.
F i g ura 1 .2 . SVG està pensat per representar gràfics

vectorials en 2D.
D’adaptar el contingut d’un document per fer que pugui ser visualitzat d’una
manera alternativa s’encarregaran els fulls d’estil.
Els fulls d’estil seran els responsables de fer que els documents XML puguin
ser visualitzats de maneres diferents per adaptar-se al medi per al qual seran
visualitzats.
En documents XML els fulls d’estil més usats són:
• Cascading style sheets (CSS): un mecanisme simple per afegir estil als
documents. És el que es fa servir en HTML/XHTML.
• XSL formatting objects (XSL-FO): un llenguatge XML que només té

com a objectiu donar format als documents XML. Es fa servir sobretot per
transformar la informació en altres formats com PDF (portable document
format) o HTML.
1.1 Cascading style sheets (CSS)
XHTML és la versió en XML Els fulls d’estil CSS van ser creats per posar una mica d’ordre en l’entorn web i,
d’HTML.
per tant, es van pensar per donar format a HTML (i per tant, també a XHTML).
De totes maneres també es poden aplicar a documents XML que no siguin

XHTML, tot i que normalment portarà una mica més de feina. Com que les
etiquetes HTML ja defineixen una manera de ser representades per defecte això
permet que en alguns casos no calgui canviar aquesta representació, però en canvi
en XML no hi ha informació sobre com s’ha de presentar la informació i, per tant,
normalment s’haurà de definir la manera de representar cada una de les etiquetes.
Han sortit diverses versions de CSS:
• CSS1: va ser la primera versió que va sortir i ja no està suportada pel W3C.
• CSS2: va expandir les característiques de CSS1 afegint-li moltes funcio-

nalitats. Tot i que va sortir el 1998 encara és la versió més suportada pels
programes i està en constant revisió.
• CSS3: CSS3 a més d’afegir noves funcionalitats converteix l’especificació

en modular, de manera que alguns mòduls s’han convertit en recomanacions
i d’altres encara no. No està gaire suportada.
En l’especificació de la
versió 2 de CSS fins i tot s’hi
Mentre que fa temps tothom visitava les pàgines web amb un ordinador, en un inclou un punt, que
anomena “A brief CSS 2.1
moment donat la situació va començar a canviar radicalment i es van començar tutorial for XML”, en què es
parla com es pot lligar CSS
a visitar les pàgines web amb altres dispositius: ordinadors de butxaca, telèfons amb documents XML.
mòbils, televisions, etc... i les primeres versions d’HTML no estaven preparades

per al canvi.
Calia que les pàgines s’adaptessin al dispositiu que les visitava, ja que allò que
en un ordinador personal era perfectament llegible, en un telèfon mòbil podia
ser il·legible. Però en HTML era molt difícil convertir una pàgina que tenia un
format específic en un altre, ja que les dades estaven mesclades amb la manera de
representar-les. Calia separar les dades de la manera de representar-les.
A més, la popularitat de les pàgines web va començar a fer que els llocs web
cada vegada tinguessin més pàgines. En tenir el format dins del document, si es
volia que totes les pàgines mostressin un aspecte coherent s’havia de repetir l’estil
en totes les pàgines. Calia una manera de poder aplicar un estil a múltiples
pàgines.
CSS intenta donar una manera de definir les regles de presentació d’un
document sense barrejar les dades amb el contingut i permetent que els estils
es puguin aplicar a múltiples pàgines.
Per tant, CSS proporciona un sistema per controlar la presentació de les pàgines
sense haver de canviar el document al qual es vol donar estil.
1.1.1 Navegadors web
Com que CSS va sorgir de les tecnologies web els programes que en tenen un
suport més gran són els navegadors web. Per tant, solen ser els programes més
usats per visualitzar documents als quals s’aplica un full d’estil.
Actualment els navegadors web estan fent tasques molt diferents d’aquelles per a
les quals van ser pensats inicialment. Els navegadors web no solament es fan servir
per visualitzar informació en una pàgina web sinó que es poden fer servir per
descarregar programes, visualitzar pel·lícules, escoltar música, edició de textos,
executar programes, etc. Fins i tot les tecnologies en el núvol ens permeten
administrar servidors des del navegador.
• La complexitat associada a les múltiples tasques noves que han anat assu-
mint els navegadors ha fet que no sempre compleixin perfectament tots els
estàndards i recomanacions.
• A vegades algunes especificacions no deixen clar què s’ha de fer en casos

determinats i els navegadors han tendit a improvisar, i això fa que no tots
els navegadors responguin igual en aquestes situacions.
El suport dels navegadors a CSS ha estat molt variable al llarg del temps però
en general els navegadors interpretaran les regles CSS majoritàriament de la
mateixa manera (però no sempre) i, per tant, en crear un full d’estil CSS s’haurà
de comprovar com es veu amb diferents navegadors per assegurar-se que no té
problemes.
Visualització de documents XML
En carregar un document XML que no tingui full d’estil els navegadors solen
carregar un full d’estil per defecte que sol ser en forma d’arbre com en la figura
1.3.
F igu r a 1. 3 . Visualització per defecte d’un document XML en el Firefox
Aquesta visualització avisa que el document no té full d’estil.
Si es defineix un full d’estil sense regles es mostrarà el document amb la visió per
defecte (figura 1.4).
La representació per defecte d’un document XML és simplement ignorar els

elements i pintar el contingut de les dades un rere l’altre.
Figur a 1. 4. Visualització per defecte d’un document XML en el Firefox
1.1.2 Associar un full d’estil a un document
Per poder aplicar un full d’estil CSS a un document aquest s’ha de modificar per
indicar-li quin és el full d’estil per aplicar. Associar un full d’estil es farà de manera
diferent si l’estem associant a un document HTML que si l’estem associant a un
document XML.
Com que l’XHTML és HTML i a més està basat en XML, es pot associar
un full d’estil CSS a XHTML fent servir qualsevol dels sistemes.
Associar un document HTML
L’HTML defineix dues etiquetes per mitjà de les quals es poden definir fulls
d’estils per a un document:
1. <style>
2. <link>
Totes dues regles s’han de definir dins de l’etiqueta <head> del document.
L’element <style> permet que es puguin afegir regles CSS directament en un

document HTML.
1 <html>
2 <head>
3 <title>Test</title>
4 <style type="text/css">
5 ... regles ...
6 </style>
7 ...
Les regles CSS simplement s’han d’especificar entre l’obertura i el tancament de

l’element.
Aquest no és el sistema més usat, ja que es perd la possibilitat de fer que totes les
pàgines d’un lloc web concret tinguin un estil semblant. Per aquest motiu el més
corrent és definir el full d’estil com un fitxer a part amb l’element <link> (figura
1.5).
F i g ura 1 . 5 . Definir un full d’estil CSS extern en HTML
Els tipus MIME

MIME és un estàndard que es fa
servir per transferir arxius
binaris en protocols que només
accepten la transferència de • L’atribut type sempre serà el valor MIME de CSS (text/css).
caràcters de text. Inicialment va
ser creat per poder adjuntar
arxius per correu electrònic, però
actualment hi ha molts altres
• rel serveix per determinar quina és la relació de l’arxiu que estem enllaçant
protocols que el fan servir. amb el document.
• I l’atribut href és el que es fa servir per enllaçar amb l’arxiu que conté les
regles CSS. Normalment se li posa extensió .css però pot tenir l’extensió
que es vulgui.
Associar un document XML
L’XML permet a l’usuari especificar les seves etiquetes pròpies i no en porta cap
de predefinida, o sigui que en XML les etiquetes <style> i <link> no existiran,
o si existeixen estaran dotades d’un significat diferent del que tenen en HTML.
Per aquest motiu els fulls d’estil en documents basats en XML es defineixen fent
servir la instrucció de procés xml-stylesheet (figura 1.6).
Fi gu ra 1 . 6 . Definició de la instrucció de procés

”xml-stylesheet”
La majoria dels atributs tenen el mateix nom que en l’element <link> d’HTML
(excepte rel, que aquí no es pot fer servir).
Altres paràmetres
Tant <link> com <?xml-stylesheet ?> permeten tota una sèrie d’atributs a
part dels dos bàsics (type i href) que tenen per objectiu passar més informació
al programa per representar el document (taula 1.1).
Taul a 1. 1. Paràmetres de càrrega de CSS
Atribut Descripció
title El nom o el títol del full.
media Indica sota quin medi s’ha de carregar el CSS.
charset Codi de caràcters que fa servir el full d’est’l.
alternate Indica si el CSS és preferit o no.
Sense cap mena de dubte, dels atributs que hi ha el més usat és media, que permet
que s’apliqui un estil o un altre en funció del dispositiu amb què s’està intentant
visualitzar el document.
Gràcies a l’atribut media es poden fer fulls d’estil que s’aplicaran en funció de
quin sigui el dispositiu que vol llegir el document (taula 1.2).
Taul a 1 .2. Valors possibles en l’atribut ”media”
valor dispositius
screen Per ser visualitzat en un monitor de PC
print Sortida en paper: impressores, etc.
tty Sortida en terminals, teletips, etc.
handheld PDA, telèfons mòbils, etc.
braille La sortida es generarà en dispositius tàctils per a

cecs.
aural Per sortir en lectors de pantalla, sintetitzadors de veu,

etc.
tv Televisors, consoles de videojocs, etc.
Tot i que el suport en els navegadors està millorant, normalment (excepte per als
atributs screen i print) els navegadors no sempre compleixen l’estàndard i no
hi ha gaires garanties que si es navega per la pàgina amb un navegador de telèfon
mòbil, per exemple, aquesta faci servir el full d’estil marcat com a handheld i no
pas un altre.
Si no s’especifica cap valor a l’atribut media s’està indicant que el que s’està
definint és el full d’estil per defecte.
1 <?xml−stylesheet href="web.css"?>
2 <?xml−stylesheet media="print" href="imprimir.css"?>
3 <?xml−stylesheet media="handheld" href="mobils.css"?>
En cas d’especificar diversos fulls d’estil es barrejaran les regles de tots i en cas
de conflicte es faran servir les definicions especificades més tard. Això permet
fer fulls d’estils personalitzats per a algunes pàgines sense que es perdi l’aspecte
global d’una web.
1 <?xml−stylesheet href="empresa.css"?>
2 <?xml−stylesheet href="departament.css"?>
1.1.3 Regles CSS
Els documents de CSS normalment seran una llista de regles en què cada una té
una forma semblant a la que es mostra en la figura 1.7.
F i g ura 1 . 7 . Forma bàsica de les regles CSS
Els elements es van passant a CSS i aquest determina quines són les regles que
se’ls ha d’aplicar a partir del selector. Per exemple, si es té el CSS següent quan
s’està analitzant l’etiqueta cognom d’un document:
1 nom { color: red; }

2 cognom { color: blue; }
La regla de la primera línia fallarà, ja que no quadra el selector nom amb l’etiqueta
cognom i per tant la regla s’ignorarà. En canvi, com que la segona regla sí
que coincideix amb l’etiqueta aquesta sí que serà aplicada en la representació de
l’etiqueta.
Cal tenir en compte que no s’aplica només a la primera regla, sinó a totes les
regles que es puguin aplicar a l’element.
Un cop determinades les regles s’aplicaran els valors de les propietats que
s’especifiquin en la declaració a l’element. En l’exemple anterior, per tant, es
modificarà la propietat ‘color’ de l’etiqueta <cognom> amb el valor ‘blue’ que
farà que el text es representi de color blau:
1 color:blue;
A pesar que en l’exemple anterior només es canvia una de les propietats de

l’etiqueta, CSS permet que en una regla es puguin especificar tantes propietats
com calgui, sempre que es vagin separant l’una de l’altra amb un punt i coma (;).
1 persona {
2 color: red;
3 margin: 5px;
4 }
Selectors
Els selectors són un dels components bàsics de CSS, ja que serveixen per
determinar quines regles s’han d’aplicar a cada element i quines no.
Per facilitar la tasca de seleccionar les etiquetes, CSS defineix diferents tipus de
selectors:
• Universal
• D’etiquetes
• De fills
• De descendents
• De germans adjacents
• Per ID
• De classes
• D’atributs
• De pseudoclasses
Selector universal
El selector universal es representa amb un ‘*’ i es fa servir per seleccionar tots els
elements d’un document.
Això vol dir que es pot fer servir per definir característiques que seran aplicades
a totes les etiquetes del document. Per exemple, amb això s’està definint que s’ha
de pintar tot el text de color vermell:
1 * { color: red; }
Per tant, aplicat al codi:
1 <alumnes>
2 <nom>Pere</nom>
4 </alumnes>
S’obtindrà tot el text del document de color vermell (figura 1.8).

Fig u ra 1 . 8 . Aplicació del selector universal
Selector d’etiquetes
Es pot seleccionar un element específic simplement amb el nom. En aquest codi
se seleccionen totes les etiquetes nom del document:
1 nom { color: red; }

Que si s’aplica al codi següent
1 <classe>
2 <alumnes>
3 <alumne>
4 <nom>Pere</nom>
6 </alumne>
7 <alumne>
8 <nom>Manel</nom>
10 </alumne>
11 </alumnes>
12 </classe>
Pintarà els <nom> vermells i els <cognom> blaus (figura 1.9).
Fig u ra 1 . 9 . Exemple de selector d’etiquetes
S’ha de tenir en compte que no solament se seleccionen els elements del mateix
nivell, sinó tots els elements que tinguin el mateix nom d’etiqueta sense importar
en quin nivell estiguin.
Si es volen aplicar les mateixes característiques a diversos elements, es poden

especificar separant-los per comes. En l’exemple següent es pinta el text de <nom>
i <cognom> de color vermell.
1 nom, cognom { color:red; }
Tampoc no seria cap error especificar-los per separat:
1 nom { color:red; }
2 cognom { color:red; }
Selector de fills
El selector de fills es fa servir per seleccionar les etiquetes filles directes d’una
altra. Es fa servir el símbol > per definir el pare i el fill.
Per exemple, si es parteix d’aquest XML

1 <classe>
2 <professor>
3 <nom>Marcel</nom>
5 </professor>
6 <alumnes>
7 <alumne>
8 <nom>Pere </nom>
10 </alumne>
11 <alumne>
12 <nom>Joan</nom>
13 <cognom>Ferrarons</cognom>
14 </alumne>
15 </alumnes>
16 </classe>
I se li aplica aquest CSS:

1 alumne > nom { color: red; }
El resultat serà que només els elements <nom> descendents d’<alumne> són
pintats de vermell (figura 1.10).
Fi g ura 1 .10 . Selecció dels noms dels alumnes
No hi ha cap problema a fer servir altres selectors en combinació amb aquest. Per
tant, si volem que es pintin de color vermell tant els noms com els cognoms dels
alumnes es pot definir la regla d’aquesta manera:
1 alumne > nom, cognoms { color: red; }
El resultat serà el de la figura 1.11.
Fi g ura 1 .11 . Selecció dels noms i cognoms dels alumnes
També es pot fer servir el selector d’etiquetes per triar diferents pares. Si es vol
que els noms dels alumnes i dels professors siguin de color vermell simplement
se n’especifiquen les etiquetes una rere l’altra.
1 alumne, professor > nom { color: red; }
Selector de descendents
Una possibilitat alternativa consisteix a definir que es vol que l’estil s’apliqui a
algun dels descendents d’un element.
Per especificar que es vol fer servir aquest selector simplement es posen els noms
dels elements l’un al costat de l’altre. Fent servir aquest selector s’aconsegueix
pintar el cognom dels alumnes de color vermell i deixar el dels professors (figura
1.12).
1 alumnes cognom { color:red; }
Fig u ra 1 . 1 2 . Selecció de descendents
Es poden combinar amb el selector d’etiquetes cada un dels dos termes, de manera
que amb el codi següent pintem el nom i cognom dels alumnes i dels professors
de color vermell.
1 alumnes,professor nom,cognom { color: red; }
Selector de germans adjacents

El selector de germans adjacents serveix per seleccionar elements que compartei-
xin el mateix pare i estiguin situats immediatament l’un rere l’altre.
En el codi XML següent:
1 <classe>
2 <alumne>
3 <delegat/>
4 <nom>Pere</nom>
5 </alumne>
6 <alumne>
7 <nom>Joan</nom>
8 </alumne>
9 <alumne>
10 <nom>Marcel</nom>
11 </alumne>
12 </classe>
El CSS permet seleccionar aquests elements fent servir el símbol +. Per fer que el
nom dels alumnes que estigui just darrere de l’atribut delegat siguin pintats de
color vermell definirem la regla següent:
1 delegat+nom { color: red; }

El navegador només mostrarà de color vermell el text de l’etiqueta <nom> que sigui
posterior a un element <delegat> (figura 1.13).
Fi gura 1 .13 . Selecció del germà de delegat
No es poden seleccionar elements que siguin de diferents nivells perquè no

comparteixen el mateix pare. En el següent codi:
1 <classe>
2 <professor>
3 <nom>Marcel Puig</nom>
4 </professor>
5 <alumne>
7 </alumne>
8 <alumne>
9 <nom>Manel Puigdevall</nom>
10 </alumne>
11 </classe>
Aquest CSS no hi tindrà cap efecte a pesar de que els elements alumne i nom són
adjacents:
1 alumne+nom { color: blue; }
Selector per ID
L’atribut id es fa servir per poder identificar elements concrets dins d’un docu-
ment XML o HTML. Per tant, l’atribut id només especificarà un sol element dins
d’un document.
1 <classe>
2 <professor>
3 <nom>Marcel</nom>
5 </professor>
6 <alumnes>
7 <alumne id="delegat">
8 <nom>Pere </nom>
10 </alumne>
11 <alumne>
12 <nom>Joan</nom>
14 </alumne>
15 </alumnes>
16 </classe>
Es poden seleccionar els elements pel seu id fent servir el símbol #

Alguns navegadors encara
fallen en seleccionar
1 alumne#delegat { color:red; } elements amb l’atribut id en
documents XML.
Aquest codi pintarà de color vermell l’element que tingui l’atribut id amb el valor
delegat (figura 1.14).
Figu r a 1. 14 . Selecció per l’identificador ”delegat”
Això és molt usat en HTML

però no sol funcionar en
Selector de classes
XML tret que tingui l’espai Podria passar que, en algun document, a etiquetes que tenen el mateix nom a
de noms d’XHTML definit.
vegades els volem aplicar un estil i a vegades un altre.
Això se soluciona especificant l’atribut class en els elements, com en l’exemple

següent:
1 <p class="normal">
2 Els fitxers de marques només són arxius de text que
3 es poden obrir amb un <span class="important">editor de textos</span>
4 senzill.
5 </p>
6
7 <p class="important">
8 Tot i que els editors especialitzats ens ajudaran a no
9 cometre errors.
10 </p>
11
12 <p class="normal">
13 Per tant, la creació de documents XML està
14 a l’abast de tothom.
15 </p>
Es poden seleccionar els atributs per classes amb el nom de l’etiqueta, un punt i
el nom de la classe:
1 p.important {
2 color:red;
3 }
Com que l’atribut class mateix es pot especificar en diferents elements, es pot
fer una selecció de tots els atributs del mateix nom si no s’hi especifica el nom de
l’element.
1 .important { color:red; }
Això donarà el que es mostra en la figura 1.15.

Fi gura 1 .15 . Selecció de tots els elements d’una classe
Els elements poden pertànyer a més d’una classe alhora. Simplement s’hi posen
els diferents noms de classes separats per un espai.
1 <p class="important ressaltat">Oh!</p>
Selector d’atributs
També hi ha un selector que permet triar les etiquetes en funció dels seus atributs.
1 <classe>
2 <alumnes>
3 <alumne aprovat="si" delegat="si">
4 <nom >Pere </nom>
6 </alumne>
7 <alumne>
8 <nom aprovat="si">Jordi</nom>
10 </alumne>
11 <alumne aprovat="no">
12 <nom>Manel</nom>
14 </alumne>
15 <alumne aprovat="si">
18 </alumne>
19 </alumnes>
20 </classe>
Es pot triar per si l’atribut existeix. Per exemple, per fer que el delegat sigui pintat
de color verd (figura 1.16).
1 alumne[delegat] { color: green; }
Fi gura 1 .16 . A partir de l’atribut pinta de color verd el delegat del curs
També es pot seleccionar per a atributs que tinguin un determinat valor. Per
exemple es poden marcar els aprovats i no aprovats de colors diferents:
1 alumne[aprovat="si"] { color:blue; }
2 alumne[aprovat="no"] { color:red; }
Que ens mostraria això (figura 1.17).
Fig u ra 1 . 1 7 . Diferenciar els aprovats dels no aprovats
O fins i tot seleccionar per diversos atributs, per aconseguir condicions més
complexes. En l’exemple següent definim que si el delegat ha aprovat el pinti
verd i si no ha aprovat el pinti groc:
1 alumne[aprovat="si"][delegat] { color: green; }

2 alumne[aprovat="no"][delegat] { color: yellow; }
En el cas que els valors de l’atribut siguin una llista es pot fer servir l’operador
especial ˜= per seleccionar si algun dels valors és un valor en concret.
L’atribut moduls defineix tres valors per a l’element alumne:
1 <alumne moduls="XML BDD Programació"/>
Es poden seleccionar tots els elements <alumne> que tinguin el valor XML en
l’atribut amb aquesta regla:
1 alumne[moduls]~="XML" { color: red; }
Selectors de pseudoclasses
La idea d’aquests selectors és permetre seleccionar elements a partir d’una
condició que no sigui el seu nom.
Les pseudoclasses se separen del nom de l’element al qual s’aplicaran amb dos
punts (:).
Hi ha diverses pseudoclasses disponibles, que es poden veure en la taula 1.3.

Taul a 1. 3. Pseudoclasses de CSS
Pseudoclasse Significat
first-child Permet seleccionar el primer element de la classe

actual.
link Selecciona l’element si és l’origen d’un enllaç ja

visitat.
visited Per als enllaços visitats d’un tipus determinat.

Pseudoclasse Significat
active Per als elements que s’estan activant (essent clicats,

etc.).
linking Per a enllaços en XLink.
hover Elements que tenen el cursor al damunt.
focus Tria l’element que té el focus.
lang Permet triar els elements amb l’etiqueta especificant

un idioma determinat.
Per tant, en aquest exemple:
1 <alumnes>
5 </alumnes>
Es poden definir característiques especials per al primer alumne de la llista fent

servir una pseudoclasse:
1 alumnes:first−child {
2 color: red;
3 }
Resolució de conflictes
Es pot donar el cas en què, en seleccionar les regles per aplicar a un element, una
propietat estigui definida en diverses regles de les que se li han d’aplicar. I a més,
que els valors d’aquesta propietat es contradiguin.
Quan a un element se li pot aplicar la mateixa propietat segons regles

diferents i aquestes es contradiuen, el CSS defineix que la regla per aplicar
ha de ser la més específica.
Per exemple, com que les regles nom de l’exemple següent es contradiuen s’agafarà
la primera regla perquè és més concreta –defineix més clarament a quins elements
s’està fent referència:
1 alumnes nom { color: red; }

2 nom { color: blue; }
Per tant, els noms sortiran de color vermell (figura 1.18).
Fi g ura 1 .18 . En cas de conflicte es tria la regla més específica

Si hi ha regles que són igual d’específiques, aleshores s’aplicarà la que s’hagi

especificat més tard. En l’exemple següent les regles són igual d’específiques i,
per tant, es triarà la segona:
1 nom { color:red; }
2 nom { color:blue; }
O sigui, que pintarà el nom de color blau (figura 1.19).
Fig u ra 1 . 1 9 . En cas de conflicte es tria la regla més específica
Declaracions
La declaració és el segon terme de les regles CSS i és la part que s’encarregarà de

donar el format a les etiquetes. Es defineix entre claus ”{ }” i estarà formada per
una o més propietats. A cada propietat se li assignarà quin és el valor desitjat.
Per exemple, per fer que el text de l’atribut alumne sigui vermell es pot fer servir la
propietat color i se li assigna el color amb la paraula “red” aprofitant que alguns
dels colors es poden usar fent servir el nom en anglès:
1 alumne { color: red; }
Podem afegir tantes propietats com calguin en una regla. Es poden fer declaracions
tan llargues com calgui:
1 alumne { color: red;

2 padding: 35px;
3 border−style: solid;
4 border−color: black;
5 border−width: 1px;
6 }
Per tant, coneixent les propietats de CSS es tindrà un potent mecanisme per
representar les dades en documents XML i HTML.
Herència
La primera lletra de CSS és de cascading (‘cascada’, en català), i indica que les
propietats de les etiquetes no cal que es vagin repetint indefinidament, ja que
s’hereten. Això vol dir que si apliquem unes propietats a un element, els seus
elements fills automàticament les adquireixen.
Si tenim el document següent:
1 <alumnes>
2 <alumne>
5 </alumne>
6 </alumnes>
Si assignem el color vermell a l’element <alumne> automàticament els elements

<nom> i <cognom> també adquiriran el color vermell.
Per evitar aquest comportament en algun dels descendents només cal sobreescriure
la propietat amb una regla nova. Per exemple, si volem <cognom> de color blau li
assignem explícitament:

Ara <alumne> rep per herència que ha de fer servir el color vermell, però com que
ell té blau i aquesta és una regla més específica es pintarà blau (figura 1.20).
Fi g ura 1 .20 . Es pot evitar l’herència de propietats sobreescrivint-les
1.1.4 Model de caixes
El CSS tracta tots els elements com si estiguessin dins d’una caixa rectangular que
envolta el contingut (figura 1.21). En aquesta caixa es poden definir una sèrie de
marges:
• padding: marge intern entre el contingut i la caixa.
• margin: marge entre la caixa i les altres caixes adjacents.
La caixa pot tenir una línia al seu voltant, que el CSS anomena border.
F i g ura 1 . 2 1. El contingut dels elements CSS fa servir el

model de caixes
Però com que tant l’XML com l’HTML fan servir etiquetes niuades normalment
tindrem caixes que estan dins d’altres caixes (figura 1.22).
F i g ura 1 .2 2 . El contingut dels elements CSS poden ser

altres caixes
Per defecte:
• En XML quan es posicionen les caixes si no es diu el contrari sempre es

col·loquen una al costat de l’altra fins que s’acaba l’espai horitzontal. Quan
no queda més espai es representa la caixa següent a sota (figura 1.23)
• En HTML algunes etiquetes fan com les d’XML i d’altres no permeten tenir
altres caixes al costat.
F i g ura 1 . 2 3 . El posicionament per defecte col·loca les

caixes horitzontalment
Es pot canviar el comportament per defecte de dues maneres:
• Amb la propietat display.
• Posicionant les caixes.
Propietat display
Els elements tenen una propietat display, que entre d’altres coses determina com
es posiciona la caixa respecte a les altres:
• block: treballa amb blocs de contingut. Fa que les caixes acabin com
si tinguessin un salt de línia darrere seu. Per tant, es trenca amb el
posicionament per defecte.
• inline: permet que les etiquetes flueixin amb la resta del contingut. Aquest
és el comportament per defecte en representar contingut XML.
Per tant, si es té un codi XML com aquest:
1 <alumnes>
2 <nom>Pere</nom>
4 <nom>Manel</nom>
5 </alumnes>
El resultat de mostrar-lo amb un navegador si no li definim cap estil serà posar-los

inline com en la figura 1.24.
Fi g ura 1 .24 . El document es presenta per defecte en ’inline’
En canvi, si canviem la propietat display de l’element <nom> a block:
1 nom { display:block; }
Ens afegirà un salt de línia darrere de cada un dels elements com en la figura 1.25.
Fi g ura 1 .25 . El resultat de mostrar les caixes amb ’block’

Posicionament de caixes
El posicionament en CSS reposa sobre tres opcions:
• Normal
• Relatiu
• Flotant
• Absolut
Posicionament normal
El posicionament normal és el posicionament per defecte i consisteix a anar posant
les caixes una al costat de l’altra horitzontalment fins que no hi hagi espai per posar-
ne una altra. Quan això passi les següents es posen al principi de la línia següent
i tornem a començar
Una cosa que s’ha de tenir en compte és que els marges horitzontals de les caixes
es respecten i s’acumulen. Per tant, dos elements alumne que tinguin la definició
de format següent estaran separades 40 píxels:
1 alumne { margin: 20px; }
En canvi verticalment els navegadors mesclen els marges, de manera que no se

sumen els marges sinó que s’agafa el més gran. Per tant, amb la mateixa definició
anterior les caixes estaran separades només 20px verticalment.
Posicionament relatiu
Si se segueix el posicionament normal les caixes ja tenen un lloc en el qual
posicionar-se però es pot canviar aquest lloc convertint el posicionament de la
caixa amb position: relative. Amb això s’aconsegueix que la caixa es
mogui de la posició que li tocava indicant-li en quina quantitat.
Ens podem moure de les posicions normals amb left, right, top, bottom.
Per tant si partim del document següent:
1 <alumnes>
2 <nom>Pere</nom>
3 <nom delegat="si">Frederic</nom>
4 <nom>Manel</nom>
5 </alumnes>
Les dades de mesura que
indiquem en el
posicionament relatiu
sempre es computen en
relació amb la caixa anterior. Si li afegim les regles següents per canviar-li la posició esquerra on ha de sortir
l’element amb el position: relative i afegint 30 píxels a la posició esquerra:
1 nom { display:block; }
2 nom[delegat] {
3 position: relative;
4 left:30px;
5 }
En visualitzar el document es veurà que el posicionament de l’etiqueta ha canviat

(figura 1.26).
Fi g ura 1 .26 . Canvi en les posicions relatives d’un element
Posicionament flotant
El posicionament flotant ens permet col·locar la caixa de manera que quedi surant
en la part de la pantalla que li especifiquem.
La propietat que es fa servir per marcar posicionament com a flotant és float,

que pot tenir els valors de la taula 1.4.
Taul a 1. 4. Valors de la propietat ”float”
Valor Significat
left La caixa es quedarà tant a l’esquerra com pugui.
right La caixa es quedarà tant a la dreta com pugui.
none La caixa no és flotant.
inherit Ha de fer el mateix que faci el seu element pare.
Per tant, si es parteix d’aquest exemple:
1 <classe>
2 <professor>
4 </professor>
5 <alumnes>
6 <nom>Pere Gallerí</nom>
7 <nom delegat="si">Frederic Pi</nom>
8 <nom>Manel Fontcoberta</nom>
9 <nom>Llucia Martí</nom>
10 </alumnes>
11 </classe>
En aplicar-li les regles següents:
1 professor {
2 float: right;
3 width: 50%
4 color:red;
5 }
El nom del professor apareixerà a la dreta de la pantalla, mentre que els alumnes
apareixeran normalment (figura 1.27).
Fig u ra 1 . 2 7 . El professor en ser ”float” apareix a la dreta
Una de les característiques interessants de float és que fa que el contingut de les

altres caixes aparegui al seu voltant.
Es pot donar el cas que sí que quedi sobre alguns elements posteriors si es dóna el
cas que els elements del seu voltant siguin molt més petits que el float.
Per evitar que passi això es pot afegir un valor a l’atribut clear en els elements
que no vulguem que siguin adjacents a una finestra float (taula 1.5).
Taul a 1. 5. Valors de la propietat ”clear”
Valor Significat
left El costat esquerre no pot ser adjacent a un float.
right El costat dret no pot ser adjacent a un float.
both No es permeten caixes flotants en cap dels seus

costats.
inherit Ha de fer el mateix que faci el seu element pare.
none Ha de fer el funcionament per defecte.
Per tant, si s’afegeix clear a l’etiqueta <nom> de l’exemple anterior:
1 professor {
2 float: right;
3 width: 50%
4 color:red;
5 }
6 nom {
7 display:block;
8 clear: right;
9 }
El resultat serà que els alumnes no permeten <professor> a la seva esquerra, i

per tant baixen un nivell (figura 1.28).
Fig u ra 1 . 2 8 . L’atribut ”clear” impedeix que hi hagi ”floats” a la dreta

Posicionament absolut
El posicionament absolut serveix per posicionar exactament la caixa en un lloc
determinat. Les caixes que es posicionen amb posicionament absolut surten del
flux normal de representació.
Per fer posicionament absolut es fa servir l’atribut position, que només pot tenir
dos valors: absolute i fixed (vegeu taula 1.6).
Taul a 1. 6. Valors de l’atribut ”position”
Valor Funcionament
absolute Posiciona la caixa exactament en la posició

especificada.
fixed La caixa es col·loca en una posició fixa de la pantalla.

Això fa que no es mogui mai encara que el document
pugi i baixi.
El posicionament fixed
només té sentit per mostrar
el document per pantalla.
No té cap sentit per imprimir,
etc.
Per tant, es pot posicionar un element en el lloc on es vulgui. Per exemple, a 200
píxels a l’esquerra i 20 des de dalt.
1 professor {
2 position:absolute;
3 left:200px; top:20px;
4 width: 100px;
5 height: 50px; A diferència del
6 background−color:blue; posicionament relatiu, en
7 } aquest tipus de
posicionament les mesures
que definim són relatives al
total de les mides de la
pàgina, i no pas a algun
dels elements que conté
Aquest codi mostraria el que es veu en la figura 1.29. aquesta.
Fi g ura 1 .29 . L’element ”professor” amb posicionament absolut
Les caixes amb posicionament absolut, en no estar dins del flux normal de
representació, poden quedar per sota o per sobre de les altres (figura 1.30), i per
aquest motiu se solen especificar amb l’amplada i alçada.
Fi g ura 1 .30 . Problemes amb el posicionament absolut

1.1.5 Propietats
En cada una de les versions de CSS s’han anat afegint propietats noves que es
poden aplicar a cada element.
Seria excessiu veure-les totes i, per tant, ens concentrarem en les més usades. De
totes maneres es poden consultar totes les propietats disponibles en l’especificació
No s’ha d’oblidar que no tots oficial al web de W3C (http://www.w3.org/TR/CSS21/propidx.html).
els navegadors suporten
totes les propietats de CSS,
de manera que sempre
s’haurà de provar quin és
Podem dividir les propietats en tres grans grups:
l’efecte de les regles en
diversos navegadors.
1. Propietats de caixa: permetran definir característiques de la representació
de les caixes que contenen els elements.
2. Propietats de text: ens permetran definir com ha de ser representat el

contingut textual del document.
3. Propietats de color: definiran el color en què s’han de representar els

continguts i les caixes.
Unitats
Algunes propietats necessitaran que els especifiquem un color o unes dimensions.

En aquests casos, el CSS ofereix diverses alternatives per poder definir-hi un valor.
Colors
Per especificar colors es poden fer servir diversos sistemes però el més corrent és
fer-ho en RGB (red, green, blue), que consisteix a barrejar quantitats de cada color
per representar-ne d’altres.
Això es pot fer amb la funció rgb():

1 nom {
2 color: rgb(250,20,10);
3 }
4 cognom{
5 color: rgb(80%, 40%, 0%);
6 }
O bé el seu valor en hexadecimal

1 nom {
2 color: #cc6600;
3 }
També hi ha una sèrie de colors predefinits que es poden usar fent servir la paraula
en anglès: red, blue, yellow, green, black, white...
1 alumne {
2 color:red;
3 }
Mides
Quan alguna propietat demana que se li especifiqui una mida es poden especificar
de dues maneres diferents:
• Valors absoluts
• Valors relatius
Les mides en valors absoluts són aquelles en les quals s’especifica la mida exacta
en la qual es vol que es representi aquella propietat. És corrent definir-ho en píxels
(px) però també es poden fer servir una sèrie de valors de text (small, medium,
large... )
1 nom {
2 width: 50px;
3 }
4
5 cognom{
6 width: large;
7 }
Unitats ’em’
Les unitats ‘em’ fan referència a
També es poden especificar les mides en valors relatius. En aquest cas s’expressa l’increment o decrement sobre la
mida de la font que s’està fent
l’increment o decrement de la mida per defecte del tipus de lletra de la caixa. servir. Tenint en compte que la
Podem definir aquestes mides en percentatge (%) o en escalat (em). mida normal és 1em si
s’especifica 2 em s’està dient que
les lletres s’han de representar al
1 alumne { doble de la mida normal. També
2 width: 100px; es pot fer servir per reduir-ne la
mida a la meitat amb 0.5em
3 }
4
5 nom {
6 width: 50%;
7 }
8
9 cognom
10 {
11 width: 1.2em;
12 }
Propietats de caixa
El CSS representa totes les marques com a caixes rectangulars. Per defecte
les caixes tenen unes propietats per defecte però es poden canviar simplement
redefinint-les. Es poden veure algunes de les propietats en la taula 1.7.
Taul a 1. 7. Algunes de les possibles propietats de caixa
Propietat Ús
margin Serveix per definir quin és l’espai entre caixes. Per

defecte és 0.
padding Permet definir el marge intern d’una caixa. Per

defecte és 0.
border Permet definir si s’ha de representar la línia que

envolta la caixa. Per defecte no es fa.
width Permet definir l’amplada d’una caixa.
height Permet definir l’alçada d’una caixa.

Les propietats margin, padding i border especificades directament assignen els

seus valors als quatre costats de la caixa. D’aquesta manera, amb aquest codi:
1 nom {
2 border: 1px black solid;
3 padding:10px;
4 }
El resultat serà que sortirà una línia que envoltarà tota la caixa i el contingut tindrà
un marge intern de 10 píxels (figura 1.31).
Fig u ra 1 . 3 1 . Canvi en el marge intern i una línia envoltant
Es poden definir els valors dels marges d’un costat en concret especificant els
valors de cada costat (dalt, dreta, baix, esquerra: sempre en aquest ordre, com les
agulles del rellotge).
1 nom {
2 padding: 30px 50px 1px 1px;
3 }
O bé fent servir la versió de l’atribut que permet posar explícitament els valors:
1 nom {
2 padding−left:1px;
3 padding−top: 30px;
4 padding−right: 50px;
5 padding−bottom: 1px;
6 }
Les darreres regles ens mostraran la figura 1.32.
Fig u ra 1 . 3 2 . Canvis en els marges interns dels elements
Una cosa semblant passa amb la propietat border, que permet especificar el gruix
de la línia, el color i el tipus de línia que es vol.
1 nom { border: 1px black solid; }
També es poden especificar les línies de cada un dels costats de manera individual:
1 nom {
2 border−top: 2px red solid;
3 border−bottom: 2px blue dashed;
4 border−left: 1px green dotted;
5 border−right: 1px yellow outset;
6 }
Que mostrarà una imatge com la de la figura 1.33.
Fi g ura 1 .33 . Aplicar propietats diferents per a cada línia
També es disposa de propietats per canviar només característiques concretes de la

línia, com ara:
1 nom {
2 border−width: 1px;
3 border−color: black;
4 border−style: solid;
5 border−top−color: red;
6 }
Propietats de text
Un dels aspectes fonamentals a l’hora de donar format serà poder-ho fer al

contingut de text dels documents. En CSS això es fa de dues maneres:
• Propietats de tipus: fan referència a com es veuran les lletres
• Propietats text: fan referència a com es mostrarà el bloc de text en conjunt
Propietats de tipus
Aquestes propietats permetran canviar tot el que fa referència al tipus de lletra que
es fa servir per mostrar el text. Es poden canviar la majoria dels paràmetres de
cop fent servir la propietat font.
1 nom {
2 font:italic bold 12px Verdana,Geneva,Arial,sans−serif;
3 }
També es pot canviar només algun aspecte concret amb propietats més específi-
ques com les de la taula 1.8
Taul a 1. 8. Propietats habituals del tipus ”font”
Propietat Ús
font-family Permet especificar quin tipus de lletra fem servir i la

família a la qual pertany. Normalment se n’hi posen
diverses per si l’equip no té instal·lat el tipus de lletra
demanat.
font-size Serveix per definir la mida del tipus de lletra que es fa

servir.
font-weight Defineix el pes de la lletra. Generalment es fan servir

negretes (bold) o rodones (normal), però hi ha més
valors possibles.
font-style Permet definir l’estil de lletra. Els valors més corrents

són cursiva (italic) o obliqua (oblique).
font-variant Sobretot es fa servir per convertir el contingut a

versaletes (small-caps).
Famílies de tipus de lletra
Una família de tipus de lletra és un grup de tipus de lletra que comparteixen característiques
comunes. En CSS se’n defineixen cinc famílies, que contenen un gran nombre de tipus:
• sans-sefif: tipus de lletra de pal sec. Per exemple: Arial, Verdana, Helvetica...
• serif: són els que contenen gràcies, que són unes línies de decoració en els extrems
d’algunes lletres. Per exemple: Times, Georgia, Times New Roman...
• monospace: tipus de lletra de mida fixa. Tots els caràcters ocupen el mateix espai. Per
exemple: Courier.
• cursive: en aquesta família les lletres semblen escrites a mà. Per exemple: Comic Sans...
• fantasy: la família està formada per tipus de lletres en què les lletres tenen decoració afegida.
Per exemple: Impact.
En l’XML següent...
1 <alumnes>
2 <alumne>
5 </alumne>
6 <alumne>
7 <nom>Pere</nom>
9 </alumne>
10 </alumnes>
apliquem aquest CSS:
1 alumne {
2 display:block;
3 }
4
5 nom {
6 font:italic bold 30px Georgia, serif;
7 }
8
9 cognom {
10 font−family:Times,serif;
11 font−size:15px;
12 }
Observeu que els tipus de lletra han canviat (figura 1.34).
Fi g ura 1 .34 . Canvis en els tipus de lletra
Propietats de text
A més de les propietats de les lletres també es poden canviar les propietats de com
es visualitzarà el text. Podem canviar l’orientació, el color, l’espaiat entre línies,
etc. (taula 1.9).
Taul a 1. 9. Propietats del text
Propietat Ús
word-spacing Espaiat entre paraules.
letter-spacing Espaiat entre lletres.
text-decoration Permet decorar el text amb subratllats o línies

diverses.
vertical-align Alineació vertical del contingut dins de la caixa.
text-align Alineació del text en la caixa.
line-height Alçada de la línia de text.
color Color amb què es mostrarà el text.
Les regles següents:
1 nom {
2 text−decoration:underline;
3 }
4
5 cognom {
6 letter−spacing:20px;
7 }
Generaran un resultat com el que es veu a la figura 1.35.
Fi g ura 1 .35 . Canvi de la representació del text

Propietats de color i d’imatge
Una altra de les característiques del model de caixes és que en el fons de les caixes
es pot definir un color o una imatge
El color de fons es defineix amb background-color i s’hi especifica el color que

es vol:
1 nom {
2 background−color: blue;
3 }
Les imatges s’afegeixen passant l’URL de la imatge.
1 nom {
2 background−image: url(’fons.png’);
3 }
El funcionament per defecte és omplir el fons repetint la imatge tantes vegades

com calgui fins a cobrir-lo tot, tal com es mostra en la figura 1.36.
Fig u ra 1 . 3 6 . Imatge de fons
Hi ha una sèrie de propietats que permeten canviar aquest comportament, que

podeu veure en la taula 1.10.
Taul a 1. 10 . Propietats del fons de caixa
Propietat Ús
background-repeat Defineix de quina manera s’ha de repetir la imatge, si

s’ha de fer.
bakground-position Es fa servir per posicionar la imatge en un punt

concret.
background-attachment Defineix si el fons es mourà en desplaçar la imatge o

no.
1.1.6 Amagar contingut
A vegades pot interessar que no tot el contingut del document XML sigui mostrat,
ja sigui perquè no aporta res a un lector humà o per altres raons.
Això es pot fer mitjançant dues propietats:

• visibility
• display:none
Propietat ’visibility’
La propietat visibility permet fer que algun element no es mostri quan es

defineix en un determinat element.
Si partim del document següent:
1 <persona>
2 <nom>Pere</nom>
3 <cognom>Gallerí</cognom>
4 </persona>
Podem fer que no es mostri l’element <nom> definint la propietat hidden:
1 persona {
2 display:block;
3 }
4
5 nom {
6 visibility:hidden;
7 }
En la figura 1.37 podeu comprovar que, en efecte, no es mostra el nom si aquest

té el valor visibility:hidden.
Fi g ura 1 .37 . Aplicar ”visibility:hidden”
És important veure que, a pesar que no se’n mostra el contingut, encara s’està
reservant l’espai que ocuparia.
Propietat display:none
Amb aquesta propietat el que s’aconsegueix és que l’etiqueta no sigui mostrada.

Prenent el codi de l’exemple anterior, amb el CSS següent:
1 persona {
2 display:block;
3 }
4
5 nom {
6 display:none;
7 }
S’aconsegueix que l’etiqueta <nom> no es mostri ni, a diferència del que passa
amb visibility:hidden, es reservi cap espai (figura 1.38).
Fig u ra 1 . 3 8 . El nom desapareix de la presentació
1.1.7 Afegir contingut a l’XML
Hi ha tota una sèrie d’aspectes que són molt diferents en XML i HTML. Per
exemple l’HTML té etiquetes que s’encarreguen de mostrar el contingut en taules,
llistes numerades, etc.
En XML totes aquestes ajudes per a la representació de la informació no existeixen

i, per tant, s’haurà de buscar alguna alternativa per representar-les.
Crear taules XML
En HTML es pot fer servir <table> per fer taules però en XML no existeix aquesta
etiqueta. No existeix perquè els documents XML no especifiquen de quina manera
s’han de mostrar les dades.
Es pot simular la manera de mostrar les taules per pantalla fent combinacions de
posicionament però això representa molta feina.
L’atribut display de CSS permet crear taules des del full d’estil amb les etiquetes
de la taula ??. Això fa que es pugui associar cada una de les etiquetes del document
a files, cel·les, etc.
Taul a 1. 11 . Taules en CSS

Valor Descripcio
display:table Defineix que comença una taula.
display:table-row Defineix l’etiqueta com una línia de la taula.
display:table-cell L’etiqueta amb aquest valor serà una cel·la.
Si partim del document següent:

2 <classe>
3 <alumnes>
4 <alumne>
5 <nom>Pere</nom>
6 <cognom>Punyetes</cognom>
7 </alumne>
8 <alumne>
11 </alumne>
12 <alumne>
13 <nom>Mariano</nom>
15 </alumne>
16 </alumnes>
17 </classe>
Es pot veure que la informació pot ser mostrada en forma de taules; si definim
que la taula comença a <alumnes>, cada fila està representada per <alumne> i el
contingut de cada cel·la seran les etiquetes <nom> i <cognom>:
1 alumnes {
2 display:block;
3 display:table;
4 margin:10px;
5 }
6
7 alumne {
8 display:table−row;
9 }
10
11 nom, cognom {
12 display:table−cell;
13 border: 1px solid #000000;
14 padding: 3px;
15 border−spacing: 0px;
16 }
17
18 nom { background−color:blue; }
19 cognom {background−color:red; }
Amb la decoració afegida el resultat serà semblant al que es pot veure en la figura
1.39.
Fi g ura 1 .39 . Presentació de les dades XML en taules
Llistes de valors
A partir de determinades etiquetes es poden crear llistes de resultats fent servir la

propietat display:list-item. Normalment aquests elements es mostren amb
un cercle davant del seu valor S’ha de vigilar de posar
marge a la caixa que tindrà
la llista perquè si no pot
Per exemple, en aquest document passar que quedi fora de
pantalla.
1 <persones>
2 <persona>
4 </persona>
5 <persona>
7 </persona>
8 </persones>
Es pot fer que es mostrin les <persones> en forma de llista amb un codi CSS com
el següent:
1 persona {
2 display:block;
3 margin−left:40px;
4
5 }
6 persona {display:list−item; }
Es mostrarà el document tal com apareix en la figura 1.40.
Fig u ra 1 . 4 0 . Representació en forma de llista
Per representar una llista es poden fer servir diferents propietats (taula 1.12) que
permeten personalitzar-les tal com calgui.
Taul a 1. 12 . Representar una llista amb CSS
Propietat Significat
list-style-type Permet definir de quin tipus serà la llista. Pot tenir

una sèrie de valors numèrics o símbols. Per exemple:
decimal, circle, square, disc ...
list-style-position Defineix si les marques han d’aparèixer abans o en el

flux de text.
list-style-image Permet definir una imatge com a marca de la llista.
Per exemple, podem canviar el símbol d’ítem de llista per una imatge determinada.
1 persona {
2 display:block;
3 margin−left:40px;
4 }
5
6 persona
7 {
8 display:list−item;
9 list−style−image: url("bola.png");
10 }
Imatges en XML
En els documents de marques les imatges no s’afegeixen sinó que s’hi enllacen.
El problema és que l’XML no té cap etiqueta que serveixi per mostrar imatges, ni
té cap manera de fer enllaços. Per tant, l’única manera que hi ha és per mitjà d’un
llenguatge XML anomenat XLink. XLink
L’XLink és un llenguatge basat
Una opció alternativa consisteix a afegir les imatges per mitjà de la propietat en XML que està pensat per
afegir enllaços als documents
background de les cel·les de CSS. Amb aquesta propietat podrem fer que aparegui XML; en podeu trobar més
informació en el web
una imatge en representar una etiqueta d’un document XML. www.w3.org/TR/xlink .
1 logotip {
2 display:block;
3 background: url(logotip.png);
4 background−repeat: no−repeat;
5 }
Afegir text que no es troba en el document
Es pot afegir text nou en mostrar un document XML fent servir els pseudoselectors.
Els pseudoselectors permetran afegir informació complementària a les etiquetes. No tots els pseudoselectors
funcionen amb XML.
Els pseudoselectors més usats són els que es mostren a la taula 1.13 :
Taul a 1. 13 . Pseudo-selectors
pseudo-selector Descripció
:first-letter Permet definir estils especials a la primera lletra del

contingut seleccionat pel selector.
:fist-line Es fa servir per donar format a la primera línia d’un

contingut de dades de bloc.
:before Permet afegir contingut abans d’un element.
:after Permet afegir contingut després d’un element.
Gràcies als pseudoselectors es pot afegir contingut a la representació fent servir la

propietat content. Per exemple, en l’XML següent:
1 <persones>
2 <professor>
4 </professor>
5 <alumnes>
7 <nom>Filomenu Garcia</nom>
9 </alumnes>
10 </persones>
es pot afegir el text “professor:” davant del nom del professor amb la regla
:before:
1 professor nom:before {
2 content:"Professor:";
3 color: red;
4 }
5 nom {display:block;}
I mostrarà el text “Professor:” abans del nom del professor (figura 1.41).
Fig u ra 1 . 4 1 . Representació del document XML amb el text “professor”
Mostrar el valor dels atributs
El CSS no té cap manera senzilla de mostrar les dades que hi ha en els atributs.
Fent servir els pseudoselectors es podran mostrar els valors dels atributs fent servir
la funció attr().
En l’exemple següent els càrrecs es defineixen fent servir un atribut:
1 <alumnes>
3 <nom carrec="delegat">Pere Garcia</nom>
5 <nom carrec="subdelegat">Maria Bosch</nom>
6 </alumnes>
Si es vol mostrar la llista d’alumnes però que al costat surti el càrrec ho podem fer
de la manera següent:
1 alumnes {
2 display:block;
3 }
4
5 nom:after {
6 content: "(" attr(carrec) ")";
7 }
i mostrarà el de la figura figura 1.42.
Fig u ra 1 . 4 2 . Mostrar l’atribut d’un document XML
Com que alguns elements no tenen l’atribut es mostren els parèntesis () sense
contingut a dins. Això es pot solucionar posant el pseudoselector només pels
elements que tenen l’atribut:
1 nom[carrec]:after
2 {
3 font−size:8px;
4 content: " (" attr(carrec) ")";
5 }
El resultat final serà el que es mostra en la figura 1.43.
Fi g ura 1 .43 . Mostrar només els atributs dels elements que en tenen
1.1.8 Validació
Generalment els navegadors web que es troben amb una línia que conté algun error
(una propietat mal escrita, unitats mal definides, etc...) o que no entenen (perquè
no l’han implementat) la solen ignorar.
En conseqüència, una de les coses importants per no tenir problemes de represen-

tació del CSS és que el document segueixi tant com pugui els estàndards.
Figur a 1. 44. Pàgina del W3C per validar CSS
Igual que en molts llenguatges de marques, podem validar el CSS per comprovar
que no hi ha cap error i que no s’incompleix cap norma de l’especificació.
Els validadors de CSS ens permetran comprovar que el document de regles

que estem definint no incompleix cap estàndard ni conté errors.
Hi ha diverses maneres de validar documents CSS però una de molt popular és el

validador en línia del W3C jigsaw.w3.org/css-validator (figura 1.44).
1.2 HTML / XHTML
A pesar que es pot representar la informació fent servir XML i CSS, el més habitual
sol ser representar-la en algun tipus de llenguatge de marques que estigui pensat
per a la representació. El llenguatge de marques per excel·lència a l’hora de
presentar la informació és l’HTML (hypertext markup language).
L’HTML va sorgir durant el 1989 quan Tim Berners-Lee va proposar un sistema

d’hipertext per compartir documents científics per mitjà d’Internet perquè pogues-
sin ser visualitzats des de diferents sistemes.
L’HTML és un llenguatge de marques que permet publicar informació molt

diversa pensant en l’estructura dels documents i en com es representaran les
dades que contenen. Ha tingut tant d’èxit que pràcticament s’ha convertit en
una forma de comunicació universal.
L’HTML és una recomanació del W3C. El gran èxit que ha tingut ha provocat que
n’hagin sortit diverses versions al llarg dels anys per intentar adaptar-se a les noves
demandes dels usuaris.
HTML5
Des de la publicació de l’HTML 4.01 (1999), l’activitat de millora de l’HTML es van aturar
perquè el W3C es va centrar en l’XHTML, ja que la intenció era que l’XHTML substituís
completament l’HTML.
Com a resposta a la lentitud en els canvis en l’HTML, una sèrie d’empreses pel seu compte
(Mozilla, Apple i Opera) van crear el WHATWG (Web Hypertext Application Technology
Working Group), que es va centrar en crear l’HTML5. Des del 2007 el W3C torna a definir
les recomanacions d’HTML.
L’objectiu fonamental de l’HTML5 és suportar les darreres tecnologies multimèdia mentre

es manté el llenguatge de marques fàcil de llegir per als humans i fàcil d’entendre per als
programes i dispositius. En podeu trobar més informació en els enllaços següents:
• www.w3.org/TR/html5
• whatwg.org/html
1.2.1 HTML
L’HTML està pensat per definir l’estructura d’un document de text a partir d’una
sèrie d’etiquetes predefinides formades per un nom envoltat dels símbols < i >.
Cada una de les etiquetes servirà per definir l’estructura d’un document a part
d’aportar-li informació semàntica sobre el contingut respecte al document.
En les primeres versions, algunes de les etiquetes i propietats estaven pensades

també per marcar quina seria la manera en què es representaria la informació,
però actualment s’estan eliminant de l’estàndard.
Actualment la creació d’una pàgina web consistirà a definir l’estructura del

document per mitjà d’HTML i definir-ne el format per mitjà dels fulls d’estil
CSS.
La separació de la informació de l’estructura de les dades és un dels components

clau per donar dinamisme a les pàgines web.
Definició de l’estructura d’un document
Si s’analitza un document de text a grans trets podem veure que té una estructura
definida. Primer hi sol haver títols, text repartit en paràgrafs, imatges... (figura
1.45).
Fi g ura 1 .45 . Determinació de l’estructura d’un text

Aquestes parts són fàcils de detectar per una persona però no és igual de senzill
que un programa ho pugui fer. L’HTML intenta definir l’estructura d’un document
de manera que sigui senzill per a un programa interpretar què són cada una de les
dades que va trobant. Per fer-ho fa servir tota una sèrie d’etiquetes que indicaran
quin és el paper que tenen cada una de les dades en el document.
S’han definit etiquetes per marcar cada una de les seccions en què podem definir
un document.
Títols
Es poden definir títols fent servir les etiquetes <h1>, <h2>,<h3>, <h4>, <h5> i
<h6>. Aquestes etiquetes serveixen per definir diferents nivells de títols en un
document.
Els navegadors, en carregar un document HTML, ja “comprenen” per defecte quin

és el significat dels diferents nivells de títols i els representen convenientment: amb
mides diferents i amb un salt de línia després (figura 1.46).
1 <h1>Primer títol</h1>
2 <h2>Segon títol</h2>
3 <h3>Tercer títol</h3>
4 <h4>Quart títol</h4>
5 <h5>Cinquè títol</h5>
6 <h6>Sisè títol</h6>
Fig u ra 1 . 4 6 . Representació per defecte dels títols en el Firefox
Paràgrafs
Una de les parts bàsiques que formen un document solen ser els paràgrafs, que
en HTML es defineixen fent servir l’etiqueta <p>.
Per defecte els paràgrafs acaben amb un salt de línia encara que no s’indiqui
explícitament en el document (figura 1.47).
1 <h1>Primer títol</h1>
2 <p>Aquest és el primer paràgraf</p><p>Segon paràgraf</p>
Fi gura 1 .47 . Representació dels paràgrafs en el Firefox
Agrupació de contingut
Gairebé sempre, els títols i un nombre determinat de paràgrafs d’un text estan
lligats per un contingut semàntic comú. Però com que la representació de les dades
pot reordenar el contingut del document cal algun sistema per mantenir aquestes
parts unides.
L’HTML permet agrupar continguts que tenen algun tipus de lligam per mitjà de
l’etiqueta <div>.
1 <div>
2 <h1>Titol 1</h1>
3 <p>Contingut de text</p>
4 <p>Més contingut de text</p>
5 </div>
Generalment els elements <div> se solen identificar per mitjà d’atributs id o

class perquè el full d’estil hi pugui fer referència de manera més senzilla.
Un cop es té el contingut agrupat convenientment es farà més fàcil per als fulls
d’estil presentar el document reordenant els continguts d’un document sense que
se’n perdi la coherència interna (figura 1.48).
Fi g ura 1 .48 . Amb ”div” es pot reordenar coherentment

Ressaltar text
Hi ha tota una sèrie d’etiquetes més que tenen diverses funcions per a parts
concretes del text:
• Definir text com a citacions: <blockquote>, <q> i <cite>.
• Marcar que s’ha de donar èmfasi a una part del text: <em> i <strong>
• Definir contingut com abreviacions, acrònims i definicions: <abbr>,

<acronym>, <dfn>
• Permetre l’entrada de text preformatat: <pre> i <code>
Però moltes d’aquestes etiquetes poden ser substituïdes per l’etiqueta <span>.
L’element <span> aporta una manera de separar lògicament contingut dins d’un
paràgraf. Gràcies a aquesta separació es podrà donar un format diferent a parts
del seu contingut.
Per defecte els navegadors representen les etiquetes <span> com a text normal, de
manera que si volem que el text tingui un format diferent del normal se li haurà
d’assignar per mitjà d’un full d’estil. És per aquest motiu que gairebé sempre s’hi
afegeix un atribut id o class.
Figu r a 1. 49 . El paràgraf té dues parts amb format diferent
Per exemple, si es volgués mostrar el text tal com apareix a la figura 1.49, es podria
definir la part que ha de ser en negreta envoltant-la amb <span> d’aquesta manera:
1 <h1>Cicles formatius de formació professional</h1>

2 <p>dimarts, 12 d’abril de 2011 12:23</p>
3 <p>Els cicles formatius són els ensenyaments que preparen per a l'exercici d'
una professió determinada;
4 s'agrupen en famílies professionals i poden ser de <span class="negreta">grau
mitjà</span> o de <span class="negreta">grau superior</span>.
5 </p>
I posteriorment, en el full d’estil, definint que es vol negreta en la classe negreta.
Imatges
Les imatges són un dels elements importants en les pàgines web. Podem classificar
les imatges que trobem en una pàgina web en dos grans grups:
• Imatges d’adornament: no són essencials per al contingut de la pàgina,

simplement hi són per millorar-ne la presentació. Per tant, s’haurien de
carregar des del CSS.
• Imatges de contingut: formen part del contingut de la pàgina. Per tant,

s’han de definir en el document.
És important saber que les imatges no s’afegeixen realment al document sinó que
en aquest només s’hi desa una referència al lloc on les podem trobar via una URL.
Per definir imatges en un document es fa servir l’element <img>, que té dos atributs
obligatoris:
• L’atribut src, en què s’especificarà l’URL de la imatge.
• L’atribut alt, que contindrà un text que visualitzaran els programes que
accedeixin al document HTML però no tinguin capacitat gràfica per mostrar En HTML l’etiqueta <img> no
cal que sigui tancada però
imatges. en XHTML ho ha d’estar per
força.
Per tant, es pot fer que aparegui una imatge en qualsevol document HTML definint
la imatge amb una línia com aquesta:
1 <img alt="Pilota" src="pilota.png"/>
Llistes
Les llistes són una altra manera de representar la informació en HTML. Hi ha tres
tipus de llistes disponibles (figura 1.50):
• Llistes numerades
• Llistes no numerades
• Llistes de definicions
Les llistes numerades permeten especificar una sèrie de valors precedits per un
nombre. Aquestes llistes comencen amb l’etiqueta <ol> i després cada un dels
elements de la llista es col·loquen en un <li>.
En les llistes no numerades cada un dels elements de la llista està precedit per
un símbol, que per defecte és un cercle. Es comença la definició per <ul> i
posteriorment els elements es posen dins d’un <li>.
Les llistes de definició són les menys conegudes però permeten especificar dos
valors per cada element: un per a un terme o una frase, i l’altre per a la definició.
En aquestes llistes es comença la llista per <dl>, els termes per <dt> i la definició
per <dd>.
Figu r a 1. 50 . Representació de la informació en llistes
Taules
A vegades la presentació de dades requereix que aquestes siguin formatades en
taules. L’HTML permet la definició de taules amb tot un grup d’etiquetes.
Les taules sempre es consideren un grup de files en què cada fila té unes quantes
caselles. Hi ha un grup més d’etiquetes per representar capçaleres, peus de taula,
unir caselles, però la idea sempre es basa en el mateix.
Les etiquetes bàsiques per representar les taules són tres: <table> per marcar
l’inici d’una taula, <tr> per crear files, i la que representarà cada una de les cel·les
Formatat de pàgines amb
dins d’una fila,<td>.
taules
Durant molt de temps les taules El codi següent ens crea una taula de dues files i dues caselles a cada fila:
es van fer servir per poder donar
formats especials a les pàgines
web. Això va comportar que es 1 <table>
creessin moltes pàgines que no 2 <tr>
complien amb la idea bàsica de 3 <td>1</td>
separar el contingut de la
presentació. Aquestes pàgines 4 <td>2</td>
acabaven sent molt difícils de 5 </tr>
mantenir i d’interpretar. 6 <tr>
7 <td>3</td>
S’han de fer servir les taules
només per a allò per al que van 8 <td>4</td>
ser creades: mostrar informació 9 </tr>
tabulada. 10 </table>
En ser representat, aquest codi ens donarà un document com el que es mostra a la
figura 1.51 (s’hi han afegit les línies per poder visualitzar-ne millor el resultat).
Fig u ra 1 . 5 1 . Representació d’una taula
Esquema bàsic d’un document HTML
Els documents HTML només tenen una arrel, que serà l’element <html>. Aquesta
etiqueta es fa servir per informar a qui llegeixi el document que el contingut del
document és un fitxer HTML.
L’arrel només pot tenir dos elements fills:
• <head>: és el lloc en el qual es pot posar informació sobre el document

HTML. El títol, el creador, l’idioma, el full d’estil, etc. Molta d’aquesta
informació no es visualitzarà en el navegador.
– En la capçalera hi ha un element obligatori, <title>, en el qual

s’especificarà el nom del document.
• <body>: conté el contingut i l’estructura del document. Són les parts que
es “veuen” en visualitzar el document HTML.
Declaració DOCTYPE
Segons els estàndards HTML cada document necessita una declaració del tipus
de document, que ha de sortir abans de l’element <html>. Encara que no és
estrictament necessari, és molt recomanable.
Amb l’etiqueta DOCTYPE es defineix quin és el vocabulari real que es fa servir en

el document i quin és el tipus d’estàndard que es fa servir, i es dóna informació al
possible validador sobre quina versió ha de fer servir per comprovar la sintaxi del
document.
Tot i que en les primeres versions no es feien servir, també s’han definit DOCTYPE
per a aquestes versions:
• HTML 2
1 <!DOCTYPE HTML PUBLIC "−//IETF//DTD HTML//EN">
• HTML 3.2
1 <!DOCTYPE HTML PUBLIC "−//W3C//DTD HTML 3.2 Final//EN">
Per a la versió 4.01 es van crear diferents conjunts de regles en funció d’una sèrie
d’objectius. L’objectiu era que tothom fes servir la versió strict, però per criteris
de compatibilitat es van definir altres versions.
• Strict: no permet informació presentacional ni els elements declarats “per

eliminar”. Tampoc no permet fer servir marcs.
1 <!DOCTYPE HTML PUBLIC "−//W3C//DTD HTML 4.01//EN"

2 "http://www.w3.org/TR/html4/strict.dtd">
• Transitional: permet elements i atributs que ja no es recomanen. Està

pensat per compatibilitat respecte a versions anteriors. No es permeten
marcs.
1 <!DOCTYPE HTML PUBLIC "−//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.

org/TR/html4/loose.dtd">
• Frameset: és idèntic al transitional però accepta marcs
1 <!DOCTYPE HTML PUBLIC "−//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/

TR/html4/frameset.dtd">
XHTML també ha definit els seus DTD i a més la seva especificació defineix que
s’han d’especificar obligatòriament:
• XHTML 1.0 strict
1 <!DOCTYPE html PUBLIC "−//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/

xhtml1/DTD/xhtml1−strict.dtd">
• XHTML 1.0 transitional
1 <!DOCTYPE html PUBLIC "−//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.

org/TR/xhtml1/DTD/xhtml1−transitional.dtd">
• XHTML 1.0 frameset
1 <!DOCTYPE html PUBLIC "−//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/

TR/xhtml1/DTD/xhtml1−frameset.dtd">
En XHTML 1.1 això ja no es va fer d’aquesta manera i només hi ha una sola

definició DOCTYPE per a tots els documents. XHTML 1.1 és igual que la versió
1.0 strict però hi afegeix suport per a mòduls.
1 <!DOCTYPE html PUBLIC "−//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11

/DTD/xhtml11.dtd">
Esquelet bàsic
Per tant, si escollim fer servir HTML 4.01 strict, l’esquelet bàsic d’un document
XHTML serà com aquest:

2 <!DOCTYPE html PUBLIC "−//W3C//DTD HTML 4.01//EN"
4 <html>
5 <head>
6 <title>Títol</title>
7 </head>
8 <body>
9 ...
10 </body>
11 </html>
Enllaços
La possibilitat que els documents s’enllacin entre ells ha estat un dels aspectes clau
en la popularitat de les pàgines web. L’objectiu dels enllaços és permetre tenir un
apuntador unidireccional cap a una destinació qualsevol i que s’hi pugui accedir
per mitjà d’una URL.
Hi ha diverses maneres de fer enllaços en HTML però la més corrent és l’etiqueta

<a>. L’objectiu d’aquesta etiqueta és definir origen i destinacions dels enllaços.
L’únic obligatori que té aquesta etiqueta és href, que permet definir la destinació.
Les destinacions solen ser altres documents HTML.
1 <a href="http://ioc.xtec.cat/">Web de l’IOC</a>
O documents d’altres tipus:
1 <a href="http://ioc.xtec.cat/educacio/presentació.mp3">Presentació</a>
O fins i tot es poden enllaçar punts dins del document mateix. Per fer-ho només
s’ha d’afegir el nom d’un origen que s’hi hagi definit i posar-hi el símbol # davant.
1 <a href="#LLOC">Enllaç dins del document</a>
Els punts que poden ser destinacions dins d’un document es defineixen amb la
mateixa etiqueta però fent servir l’atribut ‘id’ i un nom descriptiu únic. Per
exemple, si es col·loca aquest codi en un document estem definint que pugui ser
enllaçat amb el nom LLOC.
1 <a id="LLOC" />
Tots els navegadors per defecte mostren els enllaços de manera diferent del text
normal per facilitar que el lector els localitzi ràpidament (figura 1.52).
Fi g ura 1 .52 . Els enllaços es mostren de manera diferent per ser localitzats fàcilment
Formularis
Un formulari en HTML és una part especial que conté uns elements anomenats
controls que permeten que l’usuari hi introdueixi algun tipus de dades.
Els formularis sobretot estan pensats per permetre que els usuaris enviïn informa-
ció emplenant o seleccionant els controls que conté.
Així, el codi següent:
1 <form action="resultat.php" method="post">

2 <p>
3 <label for="nom">Nom:</label>
4 <input type="text" id="Nom" />
5 <label for="cognom">Cognom:</label>
6 <input type="text" id="Cognom" />
7 <input type="radio" name="tipus" value="professsor"/>
8 <input type="radio" name="tipus" value="alumne"/>
9 <input type="submit">
10 </p>
11 </form>
...ens mostrarà el resultat que podeu veure en la figura 1.53.
Fig u ra 1 . 5 3 . Formulari en HTML
1.2.2 Convertir d’HTML a XHTML
XHTML (extensible hypertext markup language) és una recomanació oficial

del W3C i defineix una sintaxi d’HTML compatible amb XML. O dit d’una
altra manera, és un vocabulari XML vàlid.
Tot i que visualment l’HTML i l’XHTML són molt semblants, la diferència més
important entre els dos llenguatges és que l’XHTML compleix les regles XML i
per tant no permet que hi hagi etiquetes que s’obrin i no es tanquin o que no es
mantingui l’ordre a l’hora de tancar les etiquetes obertes.
El compliment de les normes XML fa que els documents XHTML tinguin

tendència a ser més grans però també tenen l’avantatge de que poden ser processats
d’una forma més senzilla pels programes i que això els fa més fàcils de mantenir
La segona diferència important està en el fet de que durant els anys l’evolució
d’HTML ha fet que hi apareguin algunes inconsistències en les que XHTML ha
intentat posar ordre. Per exemple HTML fa servir en alguns elements els atributs
id i name per pràcticament les mateixes coses
XHTML parteix de la idea actual de separar la presentació de les dades del seu
contingut i per tant elimina algunes de les etiquetes d’HTML que es feien servir
exclusivament per donar format (font, center, u, s, strike, color, align...).
L’XHTML ja no es preocupa de l’aspecte de les coses sinó de què signifiquen.
La manera com s’ha de representar es deixa per als navegadors o bé per als fulls
d’estil.
Però també hi ha algunes diferències més com que mentre en HTML l’especifica-
ció del DTD que es fa servir és opcional en XHTML s’ha d’especificar sempre o
que XHTML obliga a fer servir les minúscules per especificar les etiquetes i els
atributs
Com que l’HTML deixava molta llibertat, molts documents necessiten bastants
canvis per poder-se convertir en documents XHTML. Però com a contraprestació,
un cop fet el canvi tindran l’avantatge que els documents obtinguts seran docu-
ments XML vàlids, i per tant podran aprofitar dels avantatges que ofereix l’XML.
Es podran processar amb les mateixes eines que els documents XML i n’obtindran
els avantatges derivats:
• Seran més fàcils d’usar pels programes d’ordinador.
• Es podran validar els documents amb els processadors XML.
• Seran més petits perquè no contindran la informació sobre el format per

aplicar.
• Serà més senzill canviar-ne la presentació, ja que el codi HTML no s’haurà

de tocar. I per tant, el mateix document es podrà representar de maneres
alternatives i es podrà adaptar als nous dispositius.
• S’hi podrà mesclar informació en altres llenguatges XML (SVG, MathML,

etc..).
Declaració XML
La declaració XML és opcional en els documents XML però es recomana que tots
els documents XHTML en tinguin.
Però a pesar de la recomanació la realitat és que no es fa servir gaire perquè un dels

navegadors més usats, el Microsoft Internet Explorer, durant molt de temps, en
trobar la declaració XML mostrava l’arbre XML en comptes de mostrar la pàgina
web. Com es pot veure en la figura 1.54, en les darreres versions de l’Internet
Explorer ja no és així, i per tant no hi ha excusa per no incloure la declaració
XML en els documents HTML.
Fig u ra 1 . 5 4 . Internet Explorer 8 ja no té problemes amb la declaració XML
Per tant, podem trobar molts documents que són XHTML però que no tenen la
declaració XML, tot i que es recomana fer-la servir.
DOCTYPE
L’estàndard XHTML especifica que la declaració DOCTYPE és obligatòria. Per

tant si es vol convertir un document HTML que no contingui la declaració
DOCTYPE, en HTML era opcional, en un XHTML s’hi haurà d’afegir
Espai de noms
Com que l’XHTML està basat en XML, s’ha de definir l’espai de noms d’XHTML
en l’etiqueta arrel :
1 <html xmlns="http://www.w3.org/1999/xhtml">
2 ...
3 </xhtml>
A més, tot i que no és obligatori, es recomana fer servir els atributs xml:lang i
lang per definir l’idioma en el qual està escrit el document.
1 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ca" lang="ca" >

2 ...
3 </xhtml>
1.2.3 Eines de disseny web
Els documents HTML/XHTML només són documents de text i, per tant, es poden
crear fent servir un simple editor de text, com es pot veure en la imatge (figura
1.55).
Fi gura 1 .55 . Edició HTML des de consola
A pesar d’això hi ha tota una sèrie d’editors que ofereixen diverses ajudes per crear
documents HTML de manera més ràpida i menys subjecta a errors.
Molts editors ofereixen alguna ajuda visual per a la creació de pàgines web. El
més habitual és l’acoloriment de sintaxi HTML o fins i tot autocompletar durant
l’edició (figura 1.56).
Fi g ura 1 .56 . Edició d’HTML amb el Komodo
A pesar de tot, els editors més populars són els editors HTML WYSIWYG (what
you see is what you get) que permeten editar els documents HTML veient en tot
moment com quin serà el resultat final.
Editors HTML WYSIWYG
L’objectiu principal d’aquests editors és permetre que qualsevol pugui crear docu-
ments HTML per crear pàgines sense ser un expert en el llenguatge. S’esforcen a
fer que es pugui treballar gràficament en comptes de fer-ho editant el codi HTML.
Hi ha una gran llista d’editors d’aquest tipus, i no para de créixer:
• Adobe Dreamweaver
• Microsoft Expression Studio

• CoffeCup HTML Editor
• Kompozer
• Amaya
• BlueFish
• Quanta Plus
• etc.
Sempre s’haurien de fer proves per determinar quin és l’editor HTML que s’adapta
més a les necessitats que es tinguin.
Barra d’eines
Normalment els editors basen el seu funcionament en una sèrie de botons en
forma de barra d’eines (figura 1.57) que permeten arrossegar components sobre
la pantalla d’edició.
Fig u ra 1 . 5 7 . Barra d’eines del Kompozer
Vistes
Els editors HTML solen dividir la pantalla en diferents vistes per intentar facilitar
les tasques als usuaris. En cada una de les vistes de treball l’usuari pot veure
diferents aspectes de la web en funció de les necessitats de cada moment.
Normalment sempre solen tenir almenys dues vistes, una vista de previsualitza-
ció (figura 1.58) i una vista de codi.
El més habitual serà treballar amb la vista de previsualització, ja que permet

editar l’arxiu a més de veure en tot moment quin és l’aspecte que va prenent la
pàgina.
Fig u ra 1 . 5 8 . Vista de previsualització del Kompozer

En la vista de codi (figura 1.59) es pot veure i editar el codi HTML que ha anat
generant el programa automàticament. Normalment es recorre a aquesta vista
quan cal fer alguna tasca que no està prevista en l’editor gràfic, o per forçar que el
codi compleixi amb l’estàndard.
Fi g ura 1 .59 . Vista de codi del Kompozer
Característiques extra
La major part dels editors solen oferir la possibilitat de fer més tasques a part de
l’edició d’HTML assistida:
• Permetre l’edició de fulls d’estil.
• Facilitar la incorporació de codi en llenguatges de programació a la pàgina:

Javascript, PHP...
• Penjar la pàgina al servidor on ha de ser-hi.
• etc.
Problemes
Però a pesar dels avantatges que ofereixen aquests editors també s’hi poden trobar
alguns punts foscos:
• No sempre són gaire estrictes en el seguiment dels estàndards.
• No sempre tots els navegadors interpreten igual que els editors les pàgines
i, per tant, podem tenir resultats inesperats.
Per tant, sempre que es dissenyi una pàgina s’hauria de validar el codi amb
un validador i a més comprovar quin és el resultat de visualitzar la pàgina
amb diferents navegadors.
Un dels validadors en línia més populars és el que ofereix el W3C a valida-

tor.w3.org (figura 1.60).
F igu r a 1. 6 0 . Validador HTML/XHTML del W3C
Aquest validador a partir de la línia DOCTYPE analitza el document que hem fet i
ens mostra els errors que hi trobi.
També ens permet comprovar quin seria el resultat si defínissim algun altre
DOCTYPE. Per exemple, si validem la web de l’IOC contra XHTML 1.1 ens dóna
8 errors i ens explica com solucionar-los (figura 1.61).
F igu r a 1. 6 1 . Errors en validar la web de l’IOC contra XHTML 1.1

2. Definició d’esquemes i vocabularis en XML
L’XML permet crear els llenguatges de marques que vulguem, sigui quin sigui el
camp d’actuació, ja que en deixar crear les etiquetes que calguin es pot adaptar
a qualsevol situació. Aquest és el punt fort de l’XML sobre altres llenguatges de
marques: s’adapta al que es vulgui representar sense importar la complexitat que
pugui tenir.
Però les dades dels documents XML normalment hauran de ser processades per
un programa d’ordinador, i els programes d’ordinador no donen tanta llibertat com
l’XML. Aquests no són gaire bons interpretant i entenent informació per a la qual
no han estat programats per processar.
Suposem que s’ha desenvolupat un programa per representar imatges a partir de

les etiquetes <dibuix>, <rectangle>, <cercle>. Des d’un punt de vista de la
llibertat que deixa l’XML no hi haurà cap problema per crear un arxiu XML com
aquest:
1 <dibuix>
2 <rectangle>12,10,14,10</rectangle>
3 <linia>13,13,25,25</linia>
4 </dibuix>
El document és perfectament correcte des d’un punt de vista de l’XML però el

programa no sabrà què fer amb l’etiqueta <linia> perquè ningú no l’ha programat.
És per aquest motiu que els programes normalment es dissenyen per processar
només tipus concrets d’XML.
Per tant, una de les coses que haurà de fer un programa és comprovar que les dades
del document XML siguin correctes. Com que aquesta tasca és molt feixuga s’han
definit sistemes per comprovar que el document XML entrat conté les etiquetes
que ha de contenir i que estan col·locades tal com fa falta. El procés de fer aquestes
comprovacions s’anomena validació.
2.1 Validació de documents XML
El procés de comprovar que uns fitxers XML determinats segueixen un determinat

vocabulari s’anomena validació i els documents XML que segueixen les regles
del vocabulari s’anomenen documents vàlids. Cal tenir clara la diferència entre
el que és un document ben format i un document vàlid:
Un document és ben format quan segueix les regles d’XML.

Un document és vàlid si segueix les normes del vocabulari que té associat.
Un document pot complir perfectament amb les regles de creació de documents

XML i, per tant, estar ben format, però en canvi no seguir les normes del
vocabulari i, per tant, no ser vàlid.
Un document pot ser ben format però no vàlid, i en canvi si és vàlid segur
que és ben format.
La validació de documents és un procés corrent en llenguatges de marques, ja

que no sempre la persona que defineix com ha de ser el document després és la
que generi els documents (de vegades els documents arribaran d’altres llocs, es
generaran automàticament...).
La validació és el procés de comprovar que un document compleix amb les

regles del vocabulari en tots els seus aspectes.
La validació permet assegurar que la informació està exactament en la manera com

ha d’estar. Això és especialment important quan es comparteix informació entre
sistemes, ja que validar el document és assegurar-se que realment l’estructura de
la informació que s’està passant és la correcta. Si es vol fer que dos programes
situats en ordinadors diferents col·laborin cal que la informació que es passen l’un
a l’altre segueixi l’estructura prefixada per enviar-se missatges.
Per forçar una determinada estructura en un document cal que hi hagi alguna
manera de definir aspectes com ara:
• en quin ordre han d’anar les etiquetes,
• quines són correctes i quines no,
• en quin ordre han d’aparèixer,
• quins atributs s’hi poden posar,
• quin contingut hi pot haver,
• etc.
L’XML fa això per mitjà de llenguatges de definició de vocabularis o llenguatges

d’esquemes.
Els llenguatges de definició d’esquemes sorgeixen per la necessitat que els

documents XML siguin processats per programes (per extreure’n informació,
transformar-los en altres coses, etc), ja que els programes no són tan flexibles
com l’XML i necessiten processar dades amb estructures de document tancades.
Hi ha molts llenguatges de definició d’esquemes, però els més utilitzats en XML

són:
• Document type definitions (DTD)

• W3C XML definition language
• Relax NG
• Schematron
El procés de validació es fa per mitjà de programes especials anomenats

processadors o validadors (en anglès s’anomenen parsers).
Els validadors sovint estan en forma de biblioteques per poder ser incorporats als
programes. No tots els processadors poden validar tots els llenguatges de definició
de vocabularis i, per tant, s’hauran de triar en funció del llenguatge que fem servir.
2.2 Processadors d’XML
Els processadors XML són els encarregats de validar els documents i, per tant, és
molt important triar un processador que sigui capaç de validar el llenguatge de
validació que fem servir:
• El fet que la DTD sigui el sistema més antic i que se’n parli en l’especificació
d’XML ha fet que la majoria dels processadors XML puguin validar
llenguatges definits amb DTD.
• Amb el pas del temps, XML Schemas s’ha convertit en la manera estàndard
de validar vocabularis XML, i altres tecnologies XML en fan servir alguns
aspectes. Per tant, la majoria dels processadors també suporten aquest
format.
• Molts processadors a part dels dos més usats també poden fer servir altres
llenguatges (en especial Relax NG).
2.2.1 Biblioteques per validar XML
Els documents XML estan pensats per poder ser tractats de manera automàtica, i
moltes de les utilitats per validar documents estan en forma de biblioteques. Entre
les biblioteques existents per validar XML en podem destacar:
• libxml2
• MSXML
• Apache Xerces2
libxml2
La utilitat libxml de la biblioteca libxml2 del projecte Gnome permet validar docu-
ments XML que tinguin associats DTD, XML Schemas, Relax NG o Schematron.
Validar DTD
La manera més senzilla de fer-ho és especificar el paràmetre –valid, que fa que
el programa, a més de comprovar que el document XML estigui ben format, sigui
vàlid.
Amb el paràmetre –noout no es mostrarà cap missatge si el document és correcte.
1 $ xmllint −−valid prova.xml −−noout

2 $
També ofereix l’opció de validar un document extern amb el paràmetre

–dtdvalid. Això és especialment interessant per poder validar sense haver
d’associar el document XML i la DTD.
1 $ xmllint alumnes.xml −−dtdvalid alumnes.dtd −−noout

2 $
En cas que el document no validi mostrarà l’error trobat:

2 prova.xml:13: element classe: validity error :
3 Element classe content does not follow the DTD,
4 expecting (classe , professor , alumnes), got (professor alumnes )
5 </classe>
6 ^
Validar XML Schemas

Per validar un document amb un XML Schema s’ha d’especificar el document
d’esquema fent servir el paràmetre –schema:
1 xmllint −−schema classe.xsd classe.xml −−noout

2 classe.xml validates
Si no valida mostrarà els errors que hi hagi detectat:
1 $ xmllint −−schema classe.xsd classe.xml −−noout −−valid

2 classe.xml:3: element curs: Schemas validity error :
3 Element ’curs’: This element is not expected. Expected is ( professor ).
4 classe.xml fails to validate
Validar amb Relax NG i Schematron

No hi ha massa diferències a l’hora de validar contra Relax NG o Schematron.
Simplement s’especifica el paràmetre correcte. Per a Relax NG és –relaxng:
1 $ xmllint −−relaxng classe.rng classe.xml −−noout

2 classe.xml validates
MSXML
Des dels entorns Windows es pot fer servir la biblioteca MSXML per validar els
documents XML contra DTD o XML Schema.
Aquesta biblioteca ofereix una interfície per desenvolupar aplicacions que tre-
ballin amb diferents tecnologies XML. Es fa servir en molts dels programes de
Microsoft i és la que fan servir per defecte els programes basats en la plataforma
.NET (C#, Visual Basic, J#, managed C++ ...).
Alguns dels editors especialitzats en XML que funcionen exclusivament en

Windows fan servir aquesta biblioteca per funcionar.
Apache Xerces2
Aquesta biblioteca està pensada per ser usada des de programes i no des de la línia
d’ordres (per exemple, molts dels editors especialitzats en XML fan o permeten
fer servir Xerces2 per validar els documents XML). A pesar d’això, sí que és
possible validar un document des de la línia d’ordres si s’instal·len els exemples, ja
que contenen un programa anomenat Counter que permet fer estadístiques d’un
document i que alhora valida.
En una instal·lació d’Ubuntu s’executaria el programa i donaria el resultat següent:
1 $ java −cp /usr/share/java/xercesImpl.jar:\

2 >/usr/share/java/xmlParserAPIs.jar:\
3 >/usr/share/doc/libxerces2−java−doc/examples/xercesSamples.jar \
4 dom/Counter −v alumnes.xml
5 [Error] alumnes.xml:7:11: The content of element type "alumne" is incomplete,
it must match "(nom,cognom,cognom)".
8 alumnes.xml: 229;15;0 ms (10 elems, 9 attrs, 31 spaces, 36 chars)
Si el document valida correctament mostrarà estadístiques del document:
1 $ java −cp /usr/share/java/xercesImpl.jar:\

2 >/usr/share/java/xmlParserAPIs.jar:\
3 >/usr/share/doc/libxerces2−java−doc/examples/xercesSamples.jar \
4 >dom/Counter −v alumnes.xml
En estar desenvolupat en Java també pot ser executat en entorns Windows.

Suposant que tinguem Xerces a C:\xerces es pot validar de la mateixa manera:
1 c:\> java −cp c:\xerces\xercesImpl.jar;

2 c:\xerces\xmlParserAPIs.jar;
3 c:\xerces\xercesSamples.jar dom/Counter −v alumnes.xml
2.2.2 Programes
Tot i que els validadors sobretot es fan servir com a biblioteques incorporades en
programes, també hi ha programes que permeten validar documents sense haver
d’escriure ni una línia de codi. Exemples d’aquets tipus de programes poden ser
XMLStarlet o Jing.
Validar amb XMLStarlet
L’XMLStarlet és un programa de codi obert que s’executa des de línia d’ordres i que
pot manipular fitxers XML. Fa servir libxml2 i es pot baixar des de http://xmlstar.
sourceforge.net/.
Una de les tasques que s’hi poden fer és validar documents XML definits amb DTD, XML
Schemas i Relax NG. Si el document ja té associada la DTD n’hi ha prou d’executar la
instrucció amb validate i el nom del fitxer:
1 $ xmlstarlet validate prova.xml

2 prova.xml − valid
O es pot especificar un fitxer de definició extern:
1 $ xmlstarlet validate −−dtd prova.dtd prova.xml

Es pot fer el mateix per validar XML Schemas:
1 $ xmlstarlet validate −−xsd prova.xsd prova.xml

El problema que té el programa és que no informa dels errors trobats:
1 $ xmlstarlet validate −−xsd classe.xsd classe.xml

2 classe.xml − invalid
Hi ha molts programes que permeten validar documents XML sense haver de

programar, però el més habitual des d’un punt de vista professional sol ser fer
servir algun editor XML especialitzat, com ara oXygen XML Editor, Editix XML
Editor, Altova XMLSpy XML editor o Stylus Studio.
Editors XML
Els editors XML, a més de permetre la creació assistida de documents XML, tam-
bé tenen alguna opció per fer validacions dels documents sense haver d’abandonar
l’editor (figura 2.1).
Figu ra 2. 1. Validació des de l’XML Copy Editor
Aquests editors també detecten els problemes de validació automàticament i

marquen les línies amb errors (figura 2.2).
Fig ura 2. 2 . No cal sortir de l’entorn per veure’n els errors
Sovint també permeten validar documents XML contra gairebé tots els sistemes
de validació: DTD, XML Schemas, Relax NG...
Validar amb l’oXygen XML Editor

Com a exemple de validació amb un editor especialitzat XML farem una validació
des de l’oXygen XML Editor.
Un cop el document XML està carregat en el programa cal especificar contra quin
document s’ha de validar. Això es fa des de l’opció Configure Validation Scenario
(figura 2.3).
F igu r a 2. 3 . Configurar un escenari de validació amb l’oXygen
En la pantalla següent es defineix una nova validació i es tria el fitxer d’esquema

(figura 2.4).
F igu r a 2. 4 . Tria del fitxer per fer la validació
El fitxer quedarà associat al document de manera que cada vegada que es validi el
document ho farà contra l’esquema triat automàticament (figura 2.5).
F igu r a 2. 5 . Validació d’XML amb l’oXygen XML Editor 12

2.3 DTD
El DTD (document type definitions) és un llenguatge de definició d’esquemes que

ja existia abans de l’aparició d’XML (es feia servir en SGML). En estar pensat per
funcionar amb SGML es podia fer servir en molts dels llenguatges de marques que
s’hi han basat, com XML o HTML.
Quan es va definir l’XML es va aprofitar per fer una versió simplificada de

DTD que en fos el llenguatge d’especificació d’esquemes original. Un avantatge
associat era que fer servir una versió de DTD permetria mantenir la compatibilitat
amb SGML, i per tant es van referenciar les DTD en l’especificació d’XML
(http://www.w3.org/TR/REC-xml/).
L’objectiu principal de les DTD és proveir un mecanisme per validar les estructures
dels documents XML i determinar si el document és vàlid o no. Però aquest no
serà l’únic avantatge que ens aportaran les DTD, sinó que també els podrem fer
servir per compartir informació entre organitzacions, ja que si algú altre té la nostra
DTD ens pot enviar informació en el nostre format i amb el programa que hem fet
la podrem processar.
Durant molt de temps les DTD van ser el sistema de definir vocabularis més usat
en XML però actualment han estat superats per XML Schemas. Tot i això encara
és molt usat, sobretot perquè és molt més senzill.
2.3.1 Associar una DTD a un document XML
Per poder validar un document XML cal especificar-li quin és el document

d’esquemes que es farà servir. Si el llenguatge que es fa servir és DTD hi ha
diverses maneres d’especificar-ho però en general sempre implicarà afegir una
declaració DOCTYPE dins el document XML per validar.
El més habitual és afegir la referència a la DTD dins del document XML per mitjà
de l’etiqueta especial <!DOCTYPE. Com que la declaració XML és opcional però
si n’hi ha ha de ser la primera cosa que aparegui en un document XML, l’etiqueta
DOCTYPE haurà d’anar sempre darrere seu.
Per tant, seria incorrecte fer:
1 <!DOCTYPE ... >

Però, per altra banda, l’etiqueta no pot aparèixer en cap altre lloc que no sigui just
a continuació de la declaració XML, i per tant tampoc no es pot incloure l’etiqueta
DOCTYPE un cop hagi començat el document.
2 <document>
3 <!DOCTYPE ...>
4 </document>
Ni tampoc al final:

2 <document>
3 </document>
4 <!DOCTYPE ... >
L’etiqueta DOCTYPE sempre ha d’anar o bé en la primera línia si no hi ha declaració

XML, o bé just al darrere:

2 <!DOCTYPE ... >
3 <document>
4 </document>
Hi ha dues maneres d’incorporar DTD en un document XML:
• Declaració interna
• Declaració externa
Declaració DTD interna
En les declaracions DTD internes les regles de la DTD estan incorporades en el

document XML. L’etiqueta DOCTYPE es declara com es veu en la figura 2.6.
F i g ura 2 . 6 . Declaració DOCTYPE interna
Per exemple, si es copien les línies següents en un document XML anomenat

prova.xml:
2 <!DOCTYPE classe [
3 <!ELEMENT classe (professor, alumnes)>
4 <!ELEMENT professor (#PCDATA)>
5 <!ELEMENT alumnes (nom*)>
6 <!ELEMENT nom (#PCDATA)>
7 ]>
8 <classe>
9 <professor>Marcel Puig</professor>
10 <alumnes>
11 <nom>Frededic Pi</nom>
12 </alumnes>
13 </classe>
Es pot comprovar que el document es valida fent servir la instrucció següent:
Les declaracions de DTD internes no es fan servir gaire perquè tenen una sèrie de
problemes que no les fan ideals:
• En tenir la definició de l’esquema dins del document XML no és fàcil

compartir les declaracions amb altres documents.
• Si es tenen molts documents XML, per canviar lleugerament la declaració

s’hi hauran de fer canvis en tots.
És per aquest motiu que és més recomanable tenir la DTD en un document a part
i fer servir aquest document DTD per validar tots els XML.
Declaració DTD externa
En comptes d’especificar la DTD en el mateix document es considera una pràctica

molt millor definir-la en un fitxer a part.
Per fer una declaració externa també es fa servir l’etiqueta DOCTYPE però el format
és lleugerament diferent i preveu dues possibilitats:
• DTD privada
• DTD pública
DTD privades
Les definicions de DTD privades són les més corrents, ja que, tot i que es defineixi
el vocabulari com a privat, no hi ha res que impedeixi que el fitxer es comparteixi
o es publiqui per mitjà d’Internet. La definició d’una DTD privada es fa de la
manera que es pot veure en la figura 2.7.
Fig u ra 2 . 7 . Definició d’una DTD privada en un document XML
El camp d’adreça especifica on és i quin nom té el fitxer que conté les regles. Es
pot especificar fent servir una URI (uniform resource identifier). Això fa que es
pugui definir la DTD per mitjà d’un nom que per definició hauria de ser únic.
En el camp d’adreça es poden definir camins dins la màquina:
1 <!DOCTYPE classe SYSTEM "C:\dtd\classe.dtd">

URI
Una URI (uniform resource
identifier) és una cadena de
caràcters que es fa servir ‘er fer
referència única a un recurs local, O fins i tot es pot definir una DTD per mitjà d’una adreça d’Internet:
dins d’una xarxa o a Internet.
1 <!DOCTYPE classe SYSTEM "http://www.ioc.cat/classe.dtd">
Per tant, podríem definir dins d’un fitxer XML una DTD que tingui l’element arrel
<alumnes> d’aquesta manera:
1 <!DOCTYPE alumnes SYSTEM "alumnes.dtd">
Un cop definit només cal crear l’arxiu alumnes.dtd en el lloc adequat amb les
regles que defineixen el vocabulari:

2 <!ELEMENT classe (professor, alumnes) >
3 <!ELEMENT professor (#PCDATA) >
4 <!ELEMENT alumnes (nom*) >
5 <!ELEMENT nom (#PCDATA) >
DTD públiques
Les definicions PUBLIC estan reservades per a DTD que estiguin definides per
organismes d’estandardització, ja siguin oficials o no. En la definició d’una DTD
pública s’afegeix un camp extra que fa d’identificador de l’organisme (figura 2.8).
Fi gura 2 .8. Definició d’una DTD pública en un document XML
La majoria dels camps són idèntics que en definir una DTD privada però en aquest
cas s’hi ha afegit un camp més, que és un identificador. L’identificador pot estar
en qualsevol format però el més corrent és fer servir el format FPI (formal public
identifiers). L’FPI es defineix per mitjà d’un grup de quatre cadenes de caràcters
separades pels dobles barres. En cada posició s’especifica:
1 "simbol//Nom del responsable de la DTD//Document descrit//Idioma"
en què cada valor es definirà segons la taula 2.1.
Taul a 2. 1. Definició d’un FPI

Camp Valors possibles
primer Si l’estàndard no ha estat aprovat hi haurà un ’-’,

mentre que si ha estat aprovat per un organisme no
estàndard tindrem un ’+’. I en canvi, si ha estat
aprovat per un organisme d’estàndards, hi haurà una
referència.
Nom del responsable Qui és l’organització o la persona responsable de

definir l’estàndard.
Document descrit Conté un identificador únic del document descrit.
Idioma El codi ISO de l’idioma en què està escrit el

document.
Per exemple, aquesta seria una declaració correcta:
1 <!DOCTYPE classe PUBLIC "−//IOC//Classe 1.0//CA" "http://www.ioc.cat/classe.dtd

">
Un exemple de DTD pública que es fa servir molt és la declaració d’HTML 4.01:
1 <!DOCTYPE HTML PUBLIC "−//W3C//DTD HTML 4.01//EN"

Regles internes en declaracions externes

Qualsevol de les definicions externes també pot contenir un apartat opcional que
permet especificar-hi un subconjunt de regles internes.
1 <!DOCTYPE nom SYSTEM "fitxer.dtd" [ regles ] >

2 <!DOCTYPE classe PUBLIC "−//IOC//Classe 1.0//CA" "fitxer.dtd" [ regles ] >
Si no hi ha regles no cal especificar aquest apartat però també es pot deixar en

blanc. Per tant, seria correcte definir la DTD d’aquesta manera:
1 <!DOCTYPE alumnes SYSTEM "alumnes.dtd" [ ]>
Com d’aquesta:
1 <!DOCTYPE alumnes SYSTEM "alumnes.dtd">
2.3.2 Definició d’esquemes amb DTD
La part més important d’un sistema de definició de vocabularis és definir com es fa

per determinar l’ordre en què els elements poden aparèixer i quin contingut poden
tenir, quins atributs poden tenir les etiquetes, etc.
Això, en DTD, es fa definint una sèrie de regles per mitjà d’un sistema d’etiquetes
predefinit. A diferència del que passa en XML, en fer una definició en DTD les
etiquetes estan definides. Per definir elements i atributs s’hauran de fer servir
etiquetes concretes.
Elements
De la mateixa manera que els elements són la base de l’XML, la definició d’aquests
elements és la base de la definició de fitxers DTD. Per tant, sempre s’hauran de
definir tots els elements que componen el vocabulari i a més especificar-ne el
contingut (figura 2.9).
F i g ura 2 . 9 . Definició d’una DTD
Per tant, és molt senzill definir elements amb DTD: simplement es defineix el nom
de l’element i quin és el contingut.

Com en XML, els continguts poden ser dades o bé altres elements. Podem definir
tres grans grups de maneres de definir els continguts en una DTD:
• Continguts genèrics
• Contingut d’elements
• Contingut barrejat
Continguts genèrics
Hi ha tres continguts genèrics que es poden fer servir per definir elements: ANY,
EMPTY i #PCDATA (vegeu la taula 2.2).
Taul a 2. 2. Continguts genèrics en una DTD
Valor Significat
ANY El contingut de l’element pot ser qualsevol cosa.
EMPTY L’element no té contingut.
#PCDATA El contingut de l’etiqueta poden ser dades.
Els elements que estiguin definits amb ANY poden contenir qualsevol cosa dins seu.
Tant etiquetes, com dades, o fins i tot una barreja de les dues coses.
Si es defineix persona d’aquesta manera:
1 <!ELEMENT persona ANY>
validarà tant elements que continguin dades:
1 <persona>Frederic Pi</persona>
com elements que continguin altres elements:
1 <persona>
4 </persona>
Per tant, el contingut definit amb ANY és molt potent però també fa que es perdi
el control de les coses que es poden validar amb la DTD, ja que ho validarà
pràcticament tot.
Els elements en XML a vegades no cal que tinguin cap valor per aportar alguna
informació, ja que el nom de l’etiqueta pot tenir algun tipus de significat semàntic.
L’etiqueta <professor> de la línia 4 de l’exemple següent no necessita tenir cap

contingut perquè està implícit que la persona a la qual s’assigni l’etiqueta serà un
professor.
1 </persones>
2 <persona>
3 <nom>Pere Martí</nom>
4 <professor/>
5 </persona>
6 <persona>
7 <nom>Marcel Peris</nom>
8 </persona>
9 </persones>
Els continguts definits amb EMPTY estan pensats per a les etiquetes que no tindran
cap contingut dins seu. Per tant, l’element <professor> de l’exemple anterior es
definiria d’aquesta manera:
1 <!ELEMENT professor EMPTY>
Aquesta definició serveix tant per als elements que es defineixen fent servir el
sistema d’una sola etiqueta...
1 <professor/>
com per als que defineixen les etiquetes d’obertura i tancament.
1 <professor></professor>
El contingut genèric #PCDATA (parser character data) segurament és el més usat

per marcar que una etiqueta només té dades en el seu contingut.
Si partim de l’exemple següent:
1 <persona>
2 <nom>Marcel</nom>
3 <cognom>Puigdevall</nom>
4 </persona>
Es pot fer servir #PCDATA per definir el contingut dels elements <nom> i
<cognom> perquè dins seu només tenen dades.

2 <!ELEMENT cognom (#PCDATA)>
Però no es pot fer servir, en canvi, per definir l’element <persona>, perquè dins
seu no hi té només dades sinó que hi té els elements <nom> i <cognom>.
Contingut d’elements
Una de les situacions habituals en un document XML és que un element dins del
seu contingut en tingui d’altres.
Tenim diverses possibilitats per definir el contingut d’elements dins d’una DTD:
• Seqüències d’elements
• Alternatives d’elements
• Modificadors
Si mirem l’exemple següent veurem que tenim un element <persona> que conté
dos elements, <nom> i <cognom>.
1 <persona>
2 <nom>Pere</nom>
3 <cognom>Martinez</cognom>
4 </persona>
Per tant, l’element <persona> és un element que té com a contingut una

seqüència d’altres elements. En una DTD es defineix aquesta situació definint
explícitament quins són els fills de l’element, separant-los per comes.
1 <!ELEMENT persona (nom,cognom)>
Mai no s’ha d’oblidar que les seqüències tenen un ordre explícit i, per tant, només
validaran si l’ordre en què es defineixen els elements és idèntic a l’ordre en què
apareixeran en el document XML.
Per tant, si agafem com a referència el document següent:

1 <menjar>
2 <dinar>Arròs</dinar>
3 <sopar>Sopa</sopar>
4 </menjar>
Si l’element <menjar> es defineix amb la seqüència (<dinar>,<sopar>), aquest

validarà, ja que els elements que conté estan en el mateix ordre que en el document.
1 <!ELEMENT menjar (dinar,sopar)>
Però no validaria, en canvi, si definíssim la seqüència al revés

(<sopar>,<dinar>) perquè el processador esperarà que arribi primer un
<sopar> i es trobarà un <dinar>.
1 <!ELEMENT menjar (sopar,dinar)
De vegades, en crear documents XML, succeeix que en funció del contingut que
hi hagi en el document pot ser que hagin d’aparèixer unes etiquetes o unes altres.
Si dissenyéssim un XML per definir les fitxes de personal d’una empresa podríem
tenir una etiqueta <personal> i després definir el càrrec amb una altra etiqueta.
El president es podria definir així:
1 <personal>
2 <president>Josep Maria Flaviol</president>
3 </personal>
I un dels treballadors així:

1 <personal>
2 <treballador>Pere Vila</treballador>
3 </personal>
Podem fer que una DTD validi tots dos casos fent servir l’operador d’alternativa
(|).
L’operador alternativa (|) permet que el processador pugui triar entre una de
les opcions que se li ofereixen per validar un document XML.
Per tant, podem validar els dos documents XML anteriors definint <personal>
d’aquesta manera:
1 <!ELEMENT personal (treballador|president)>
No hi ha cap limitació definida per posar alternatives. Per tant, en podem posar
tantes com ens facin falta.
1 <!ELEMENT personal (treballador|president|informàtic|gerent)>
També es permet mesclar la definició amb EMPTY per indicar que el valor pot
aparèixer o no:
1 <!ELEMENT alumne (delegat|EMPTY)>

Combinar alternatives
amb PCDATA és més
complex. Vegeu l’apartat
“Problemes en barrejar
No hi ha res que impedeixi barrejar les seqüències i les alternatives d’elements a
etiquetes i #PCDATA”. l’hora de definir un element amb DTD. Per tant, es poden fer les combinacions
que facin falta entre seqüències i alternatives.
Si tenim un XML que defineix l’etiqueta <cercle> a partir de les seves coorde-
nades del centre i del radi o el diàmetre podem definir l’element combinant les
seqüències amb una alternativa. L’etiqueta <cercle> contindrà sempre dins seu
les etiquetes <x>,<y> i després pot contenir també <radi> o <diàmetre>:
1 <!ELEMENT cercle (x,y,(radi|diametre))>
Combinar seqüències i alternatives permet saltar-se les restriccions d’ordre de les

seqüències. L’exemple següent ens permet definir una persona a partir de nom i
cognom en qualsevol ordre:
1 <!ELEMENT persona ((cognom,nom)|(nom,cognom))>
En els casos en què les etiquetes es repeteixin un nombre indeterminat de

vegades serà impossible especificar-les totes en la definició de l’element. Els
modificadors serveixen per especificar quantes instàncies dels elements fills hi
pot haver en un element (taula 2.3).
Taul a 2. 3. Modificadors acceptats en el contingut dels elements
Modificador Significat
? Indica que l’element tant pot ser que hi sigui com no.
+ Es fa servir per indicar que l’element ha de sortir una

vegada o més.
* Indica que pot ser que l’element estigui repetit un

nombre indeterminat de vegades, o bé no ser-hi.
Per tant, si volem especificar que una persona pot ser identificada per mitjà del nom
i un o més cognoms podríem definir l’element <persona> d’aquesta manera:
1 <!ELEMENT persona (nom,cognom+)>
Com que aquesta expressió indica que cognom ha de sortir una vegada, podrà
validar tant aquest exemple:
1 <persona>
2 <nom>Joan</nom>
4 </persona>
com aquest altre:
1 <persona>
2 <nom>Joan</nom>
5 </persona>
És evident que aquesta no és la millor manera de definir el que volíem, ja

que definit d’aquesta manera també ens acceptarà persones amb 3 cognoms, 4
cognoms, o més.
Per tant, el modificador ideal per forçar que només hi pugui haver un o dos
cognoms seria ?, emprant-lo de la manera següent:
1 <!ELEMENT persona (nom, cognom, cognom?)>
El modificador * aplicat al mateix exemple ens permetria acceptar que alguna

persona no tingués cognoms o que en tingui un nombre indeterminat:
1 <!ELEMENT persona (nom, cognom*)>
Els modificadors aplicats darrere d’un parèntesi impliquen aplicar-los a tots els
elements de dintre dels parèntesis:
1 <!ELEMENT escriptor ((llibre,data)*|articles+) >
Contingut barrejat
El contingut barrejat es va pensar per poder definir continguts que continguin text
que es va intercalant amb d’altres elements, com per exemple:
1 <carta>Benvolgut <empresa>Ferros Puig</empresa>:

2
3 Sr. <director>Manel Garcia</director>, li envio aquesta carta per comunicar−li
que li hem enviat la seva comanda <comanda>145</comanda> a l’adreça que
ens va proporcionar.
4
5 Atentament, <empresa>Ferreteria, SA</empresa>
6
7 </carta>
El contingut barrejat es defineix definint el tipus #PCDATA (sempre en primer

lloc) i després s’afegeixen els elements amb l’ajuda de l’operador d’alternativa, |,
i s’acaba tot el grup amb el modificador *.
1 <!ELEMENT carta (#PCDATA|empresa|director|comanda)*>
S’ha de tenir en compte que aquest contingut només serveix per controlar que els
elements hi puguin ser però que no hi ha cap manera de controlar en quin ordre
apareixeran els diferents elements.
Per tant, podem definir una DTD que validi l’exemple presentat al principi
d’aquest apartat de la manera següent:
1 <!ELEMENT carta (#PCDATA|empresa|director )*>

2 <!ELEMENT empresa (#PCDATA)>
3 <!ELEMENT director(#PCDATA)>
Atributs en DTD
En les DTD s’han d’especificar quins són els atributs que es faran servir en cada
una de les etiquetes explícitament. La declaració d’atributs es fa amb l’etiqueta
especial ATTLIST, que es defineix tal com es veu en la figura 2.10.
Fig u ra 2 . 1 0 . Definició d’un atribut en DTD
Els dos primers valors de la definició de l’atribut són el nom de l’etiqueta i el

nom de l’atribut, ja que en definir un atribut sempre s’especifica a quina etiqueta
pertany. Una de les crítiques que s’han fet a les DTD ha estat que no s’hi poden
fer atributs genèrics. Si algú vol definir un atribut que sigui compartit per tots els
elements del seu vocabulari ha d’anar especificant l’atribut per a tots i cada un
dels elements.
Per definir un atribut anomenat nom que pertanyi a l’element <persona> ho podem
fer d’aquesta manera:
1 <!ATTLIST persona nom CDATA #IMPLIED>

Especificar múltiples atributs

Si un element necessita diversos atributs haurem d’especificar tots els atributs
en diverses línies ATTLIST. Per exemple, definim els atributs nom i cognoms de
l’element <persona> d’aquesta manera:
1 <!ATTLIST persona nom CDATA #REQUIRED>

2 <!ATTLIST persona cognom CDATA #REQUIRED>
O bé es pot fer la definició dels dos atributs amb una sola referència ATTLIST:
1 <!ATTLIST persona nom CDATA #REQUIRED

2 cognom CDATA #REQUIRED>
Les dues declaracions anteriors ens permetrien validar els atributs de l’element
<persona> d’aquest exemple:
1 <persona nom="Frederic" cognom="Pi" />
Atributs d’ATTLIST
Els elements ATTLIST a part de tipus de dades també poden tenir atributs que
permeten definir característiques sobre els atributs. Aquests atributs es poden
veure en la taula 2.4.
Taul a 2. 4. Atributs d’ATTLIST
Atribut Significat
#IMPLIED L’atribut és opcional. Els elements el poden tenir o no.
#REQUIRED L’atribut és obligatori. L’element l’ha de tenir definit o

no validarà.
#FIXED Es fa servir per definir atributs que tenen valors

constants i immutables. S’ha d’especificar, ja que és
permanent.
#DEFAULT Permet especificar valors per defecte en els atributs.
Per tant, si es defineix un atribut d’aquesta manera:
1 <!ATTLIST equip posicio ID #REQUIRED>
s’està obligant que quan es defineixi l’element <equip> en un document XML

s’especifiqui obligatòriament l’atribut posicio i que a més el seu valor no es
repeteixi en el document, ja que és de tipus ID.
En canvi, definint l’atribut DNI de <persona> amb #IMPLIED es permetrà que en

crear el document XML l’atribut DNI hi pugui ser o no.
1 <!ATTLIST persona dni NMTOKEN #IMPLIED>
En definir un atribut com a #FIXED o com a #DEFAULT se li ha d’especificar el valor.

Aquest valor s’especifica a continuació de l’atribut i ha d’anar entre cometes:
1 <!ATTLIST document versio CDATA #FIXED "1.0">

2 <!ATTLIST document codificacio NMTOKEN #DEFAULT "UTF−8">
Els atributs de tipus #FIXED han de tenir el valor especificat en la definició i aquest
no es pot canviar, mentre que els valors definits amb #DEFAULT sí que poden ser
canviats.
Tipus de dades
El tercer paràmetre d’una declaració ATTLIST serveix per definir quins tipus de
dades pot tenir l’atribut. Els atributs en DTD no fan servir els tipus de dades
dels elements sinó que en defineixen de propis. Els tipus de dades dels atributs es
poden veure a la taula 2.5.
Taul a 2. 5. Tipus de dades dels atributs d’una DTD
Tipus Significat
CDATA Pot contenir qualsevol cadena de caràcters

acceptable. Es pot fer servir per a preus, URL,
adreces electròniques, etc.
Enumeracions Es fan servir per definir que l’atribut ha de tenir un

dels valors especificats.
ID L’atribut es podrà fer servir com a identificador d’un

element. El seu valor serà únic.
IDREF o IDREFS El valor són referències a un ID que ha d’existir. El

plural és per definir que és una llista.
ENTITY o ENTITIES Les entitats permeten definir constants per al

document i, per tant, el valor de l’atribut ha de ser
una entitat.
NMTOKEN o NMTOKENS Especifiquen cadenes de caràcters que només

tinguin caràcters permesos per XML. Per tant, no es
permeten els espais.
NOTATION Permet que l’atribut sigui d’una notació declarada

anteriorment.
CDATA
El tipus CDATA és un tipus de dades pràcticament idèntic al tipus #PCDATA de les
etiquetes. En un CDATA es pot posar qualsevol dada en format de text tant si té
espais com si no en té.
Per tant, la declaració següent:

1 <!ATTLIST empresa nom CDATA #REQUIRED>
permetria definir etiquetes empresa com aquestes:

1 <empresa nom="Microsoft Corporation"/>
2 <empresa nom="6tem"/>
És important recordar que els nombres també validarien amb un tipus CDATA
perquè interpretats en forma de text no deixen de ser simplement caràcters:
1 <empresa nom="12"/>
Enumeracions
Els atributs també poden ser especificats definint-hi quins poden ser els valors cor-
rectes per a un atribut. Aquests valors s’especifiquen literalment amb l’operador
de selecció:
1 <!ATTLIST mòdul inici (setembre|febrer) #IMPLIED>
Per tant, segons la definició, l’atribut inici ha d’existir i només pot tenir els valors
“setembre” o “febrer”.
Es poden posar múltiples opcions en una enumeració. Per exemple, podem

comprovar que el valor de l’atribut sigui un nombre entre 1 i 12 d’aquesta manera:
1 <!ATTLIST mòdul nombre(1|2|3|4|5|6|7|8|9|10|11|12)>
ID
El tipus de dades ID serveix per definir atributs que es puguin usar com a
identificadors d’un element dins del document. Cal tenir en compte que:
• Els valors assignats no es poden repetir dins del document. Això els fa
ideals per fer servir el tipus ID per identificar únicament els elements d’un
document.
• Els valors han de començar per una lletra o un subratllat.
Els valors de l’atribut posicio de la definició següent no es podran repetir dins

del mateix document:
1 <!ATTLIST equip posicio ID #REQUIRED>
Per tant, si es fes servir la declaració anterior per validar aquest document es
generaria un error de validació en l’atribut posició, ja que es repeteix el valor
“primer” en els dos elements.
1 <classificació>
2 <equip posició="primer">F.C.Barcelona</equip>
3 <equip posició="primer">Reial Madrid</equip>
4 </classificació>
Perquè validi aquest document cal assegurar-se que els atributs ID no tinguin el
mateix valor:
1 <classificació>
2 <equip posició="primer">F.C.Barcelona</equip>
3 <equip posició="segon">Reial Madrid</equip>
4 </classificació>
IDREF / IDREFS
Els valors IDREF i IDREFS es fan servir per definir valors d’atributs que fan
referència a elements que tinguin un valor de tipus ID. Només tenen sentit en
vocabularis que tinguin atributs amb valor ID.
IDREF es fa servir per fer referència a un valor ID:
1 <!ATTLIST recepta id ID #REQUIRED>

2 <!ATTLIST ingredient ref IDREF #REQUIRED
Amb la declaració que s’acaba d’especificar es pot validar un document com el

següent:
1 <llibre−cuina>
2 <receptes>
3 <recepta id="recepta1">Patates fregides</recepta>
4 <recepta id="recepta2">Patates bullides</recepta>
5 </receptes>
6 <ingredients>
7 <ingredient ref="recepta1">Oli</ingredient>
8 <ingredient ref="recepta2">Aigua</ingredient>
9 </ingredients>
10 </llibre−cuina>
IDREFS permet especificar una llista de valors ID en el mateix atribut. Per exemple,
si es defineix l’atribut ingredient amb IDREFS:
1 <!ATTLIST ingredient ref IDREFS #REQUIRED>
Es podria posar una llista d‘ID com a valor de l’atribut:
1 <ingredient ref="recepta1 recepta2">Patates</ingredient>
NMTOKEN / NMTOKENS
Els tipus NMTOKEN permeten especificar que els atributs poden tenir qualsevol
Vegeu l’apartat “Noms caràcter acceptat per l’XML.
vàlids XML” en aquesta
unitat.
Així, la declaració següent:
1 <!ATTLIST home naixement NMTOKEN #REQUIRED>
permetrà validar aquest element:
1 <home naixement="1970" />
Però no ho farà amb aquest altre, perquè té un espai:
1 <home naixement="segle XX" />
El valor en plural NMTOKENS permet especificar una llista de valors en comptes

d’un de sol:
1 <coordenades posicio="x y"/>

NOTATION
Es fa servir per permetre valors que han estat declarats com a notation amb
l’etiqueta <!NOTATION. Es fa servir per especificar dades no-XML.
Sovint es fa servir per declarar tipus MIME:
1 <!NOTATION GIF SYSTEM "image/gif">

2 <!NOTATION JPG SYSTEM "image/jpeg">
3 <!NOTATION PNG SYSTEM "image/png">
4 <!ATTLIST persona
5 photo_type NOTATION (GIF | JPG | PNG) #IMPLIED>
ENTITY / ENTITIES
Indica que el valor és una referència a un valor extern que no s’ha de processar.
En general solen contenir valors binaris externs.
Fer servir ENTITY implicarà haver declarat l’entitat amb <!ENTITY:
1 <!ATTLIST persona foto ENTITY #IMPLIED

2 <!ENTITY pere SYSTEM "Pere.jpg">
Permetrà que es defineixi l’atribut persona amb el valor de l’entitat i que

automàticament sigui associat a la imatge:
1 <persona nom="pere" />
Altres
Les etiquetes <!ELEMENT> i <!ATTLIST> no són les úniques que es poden fer
servir per declarar DTD. N’hi ha algunes més que en determinats casos es poden
fer servir per crear una DTD.
En la taula 2.6 se’n poden veure algunes, i també un breu resum de què és el que
fan.
Taul a 2. 6. Altres etiquetes possibles en una DTD
Etiqueta Es fa servir per ...
<!ENTITY> Definir referències a fitxers externs que no s’han de

processar.
<!NOTATION> Incloure dades que no siguin XML en el document.
<!INCLUDE> Fer que parts de la DTD s’afegeixin al processament.
<!IGNORE> Fer que parts de la DTD siguin ignorades pel

processador.
2.3.3 Limitacions
Una de les crítiques que s’ha fet a l’ús de DTD per definir llenguatges XML és
que no està basat en XML. La DTD no segueix la manera de definir els documents
d’XML i, per tant, per fer-lo servir, cal aprendre un nou llenguatge. Si la DTD
estigués basada en XML no caldria conèixer de quina manera s’han de definir
els elements, marcar les repeticions, els elements buits, etc., ja que es faria amb
elements.
Tot i així, el fet que DTD no sigui un llenguatge XML és un problema menor si es
tenen en compte les altres limitacions que té:
• No comprova els tipus
• Presenta problemes en barrejar etiquetes i #PCDATA
• Només accepta expressions deterministes
La DTD no comprova els tipus
Un dels problemes més importants que ens trobarem a l’hora d’usar DTD per
definir el nostre vocabulari és que no té cap manera de comprovar els tipus de
dades que contenen els elements. Sovint els noms dels elements ja determinen
que el contingut que hi haurà serà d’un tipus determinat (un nombre, una cadena
de caràcters, una data, etc.) però la DTD no deixa que se li especifiqui quin tipus
de dades s’hi vol posar.
Per tant, si algú emplena amb qualsevol cosa un element que es digui <dia>, el
document serà vàlid a pesar que el contingut no sigui una data:
1 <dia>xocolata</dia>
En no poder comprovar el tipus del contingut, una limitació important afegida és

que no hi ha cap manera de poder posar-hi restriccions. Per exemple, no podem
definir que volem que una data estigui entre els anys 1900 i 2012.
Problemes en barrejar etiquetes i #PCDATA
Una limitació més complexa de veure és que no es poden barrejar etiquetes i

#PCDATA en expressions si el resultat no és el que es coneix com a “contingut
Vegeu l’apartat “Contingut
barrejat”.
barrejat” d’aquesta unitat.
Un exemple d’això consistiria a fer una definició d’un exercici com un enunciat
de text, però que hi pugui haver diversos apartats que també continguin text.
1 <exercici>
2 Llegiu el text "Validació de documents XML" i responeu les preguntes segü
ents:
3 <apartat numero="1">Què volen dir les sigles XML?</apartat>
4 <apartat numero="2">Què és un DTD?</apartat>

5 </exercici>
El més senzill seria mesclar un #PCDATA i l’etiqueta <apartat>, però és incorrec-

te:
1 <!ELEMENT exercici (#PCDATA | apartat*)>
A més, no es permet que es facin declaracions duplicades d’elements, o sigui que

tampoc no ho podem arreglar amb:
1 <!ELEMENT exercici(#PCDATA)>
2 <!ELEMENT exercici(apartat*)>
L’única manera de combinar-ho seria fer servir la fórmula del contingut

barrejat:
1 <!ELEMENT exercici(#PCDATA|apartat)*>
Només accepta expressions deterministes
Una altra de les limitacions de les DTD és que obliga que les expressions hagin
de ser sempre deterministes.
Si ens mirem un document DTD:
1 <!ELEMENT classe(professor|alumnes)>
2 <!ELEMENT professor (nom,cognoms)>
3 <!ELEMENT alumnes (alumne*) >
4 <!ELEMENT alumne (nom,cognom) >
Quan s’analitza un fitxer XML es defineix quina és l’arrel de la DTD. Si

considerem que l’arrel és l’element <classe>, el procés de validació començarà
en la primera línia que ens diu que perquè el document sigui vàlid després de
l’arrel hi ha d’haver un element <professor> o bé un element <alumnes>. Si el
que arriba és un <professor> el procediment de validació passarà a avaluar la
segona i si arriba un <alumne> passarà a la tercera. Si seguim amb l’avaluació
veurem que realment el validador sempre que es troba amb una alternativa acabarà
anant a una sola expressió. Això és perquè la DTD analitzada és determinista.
El mateix ho podem fer amb una expressió més complexa que contingui diferents
elements dins de l’alternativa. El validador ha de poder triar, en llegir el primer
element, amb quina de les alternatives s’ha de quedar. Si m’arriba un element
<nom> em quedo amb l’alternativa de l’esquerra, nom,cognoms, i si m’arriba un
<àlies> em quedo amb la de la dreta, àlies,nom,cognoms.
1 <!ELEMENT persona(nom,cognom|àlies,nom,cognom)>
Si en algun moment algú crea un document que no sigui determinista la validació

fallarà. Això passarà si en algun moment el validador es troba que no pot decidir
quina és l’alternativa correcta.
1 <!ELEMENT terrestre(persona, home | persona, dona)>
Quan des de l’element <terrestre> ens arribi un element <persona> el pro-

cessador no tindrà cap manera de determinar si estem fent referència a l’element
<persona> de l’expressió de la dreta persona,home o bé el de l’esquerra
persona,dona, i per tant fallarà perquè té dues opcions possibles. És una
expressió no determinista.
Sovint les expressions no deterministes les podem expressar d’una altra manera, de
manera que esdevinguin deterministes. L’exemple anterior es podia haver escrit
d’una manera determinista perquè en arribar un element <persona> no hi hagi
dubtes.
1 <!ELEMENT terrestre(persona,(home|dona))>
Es força que sempre aparegui un element <persona> i després hi haurà l’alterna-

tiva entre un <home> o un <dona> que és determinista.
Les expressions no deterministes són més corrents del que sembla, ja que els
modificadors les poden provocar i pot ser que no ho semblin. Si es volgués escriure
una expressió que determini un llibre a un llibre a partir de l’autor o el títol en
qualsevol ordre:
1 <!ELEMENT llibre(autor?,titol?|titol?,autor?)>
Però l’expressió anterior és incorrecta, ja que si el validador es troba un <autor>

no sap si és l’autor del costat dret de la condició autor?,titol? o bé és el del
costat esquerre que no té títol, titol?,autor?.
L’expressió determinista idèntica a l’anterior seria:
1 <!ELEMENT llibre(autor,titol?|titol,autor?|EMPTY)>
2.3.4 Exemple de creació d’una DTD
Les DTD es continuen fent servir perquè són senzilles de crear però cal recordar
sempre les limitacions que tenen, i tenir present que no sempre s’adaptaran
perfectament a allò que es vol fer.
Enunciat
Una empresa ha preparat una botiga d’Internet que genera les comandes dels
clients en un format XML que s’envia al programa de gestió de manera automàtica.
Els XML que es generen contenen dades del client i de la comanda que s’ha fet:

2 <!DOCTYPE comanda SYSTEM "comanda.dtd">
3 <comanda numero="26" dia="2011−12−01" >
4 <client codi="20">
7 </client>
8 <articles>
9 <article>
10 <descripció>Yoda Mimobot USB Flash Drive 8GB</descripció>
11 <quantitat>5</quantitat>
12 <preu>38.99</preu>
13 </article>
14 <article>
15 <descripció>Darth Vader Half Helmet Case for iPhone</descripció>
17 <preu>29.95</preu>
18 </article>
19 </articles>
20 <total valor="254,85"/>
21 </comanda>
Abans de passar-lo al programa han decidit que per tenir més seguretat es farà
un pas previ que consistirà a validar que el document. Per això necessiten que es
generi la DTD.
Resolució
S’hauran de fer dues coses:
• Associar les regles al fitxer XML.
• Crear un fitxer amb les regles, que s’anomenarà “comanda.dtd”.
Associar el fitxer XML

En la segona línia del document s’hi especifica la regla DOCTYPE per associar el
fitxer amb la DTD.
2 <!DOCTYPE albarà SYSTEM "comanda.dtd">
Crear les regles

No hi ha una manera única de crear una DTD però normalment seguir un sistema
pot ajudar a evitar errors. El sistema que es farà servir per resoldre el sistema
consisteix a començar per l’arrel i anar definint els fulls per nivells.
L’arrel del document és l’element <comanda>, que té tres fills:
1 <!ELEMENT comanda (client, articles, total)>
També té dos atributs, numero i dia, que només poden tenir valors sense espais i,
per tant, seran NMTOKEN. Són dades obligatòries per motius fiscals.
1 <!ATTLIST comanda numero NMTOKEN #REQUIRED>

2 <!ATTLIST comanda dia NMTOKEN #REQUIRED>
Un cop definit el primer nivell podem passar a definir els altres. D’una banda
l’element <client>, que té un atribut per als clients existents i no en tindrà per
als nous:
1 <!ELEMENT client (nom, cognom)>

2 <!ATTLIST client codi NMTOKEN #IMPLIED >
D’altra banda l’element <total>, que és buit però té un atribut:
1 <!ELEMENT total EMPTY>

2 <!ATTLIST total valor CDATA #REQUIRED >
També l’element <articles>, que contindrà una llista dels articles que ha
comprat el client. Com que no tindria sentit fer una comanda sense articles el
modificador que es farà servir serà +.
1 <!ELEMENT articles (article+)>
Per la seva part, desenvolupar <article> tampoc no portarà gaires problemes:
1 <!ELEMENT article (descripció, quantitat, preu)>
Per acabar només queden els elements que contenen dades:

3 <!ELEMENT descripció (#PCDATA)>
4 <!ELEMENT quantitat (#PCDATA)>
5 <!ELEMENT preu (#PCDATA)>
El fitxer resultant serà:

2 <!ELEMENT comanda (client, articles, total) >
3 <!ATTLIST comanda numero NMTOKEN #REQUIRED >
4 <!ATTLIST comanda dia NMTOKEN #REQUIRED>
5
6 <!ELEMENT client (nom,cognom) >
7 <!ATTLIST client codi NMTOKEN #IMPLIED >
8
9 <!ELEMENT total EMPTY>
10 <!ATTLIST total valor CDATA #REQUIRED >
11
12 <!ELEMENT articles (article+)>
13 <!ELEMENT article (descripció, quantitat, preu)>
14
17 <!ELEMENT descripció (#PCDATA)>
18 <!ELEMENT quantitat (#PCDATA)>
19 <!ELEMENT preu (#PCDATA)>
2.4 W3C XML Schema Definition Language
En l’especificació XML es fa referència a les DTD com a mètode per definir

vocabularis XML, però les DTD tenen una sèrie de limitacions que van portar
el W3C a definir una nova especificació. Aquesta especificació va rebre el nom de
W3C XML Schema Definition Language (que popularment s’anomena XML
Schema o XSD), i es va crear per substituir la DTD com a mètode de definició de
vocabularis per a documents XML.
Es pot trobar l’especificació més recent a www.w3.org/XML/Schema.
Relax NG
Durant l’especificació molts membres del grup de treball van considerar que el que sortia
era massa complex i van desenvolupar alternatives més simples, entre les quals destaca
Relax NG (www.relaxng.org).
Com que Relax NG es va fer més tard que DTD i XSD, va poder solucionar alguns dels
problemes.
Els esquemes es poden definir en dues versions de Relax NG, una basada en XML i una
altra que no ho està, anomenada Relax NG Compact, i que està pensada per generar
documents d’esquemes més petits i compactes.
L’èxit d’XSD ha estat molt gran i actualment es fa servir per a altres tasques a part
de simplement validar XML. També es fa servir en altres tecnologies XML com
XQuery, serveis web, etc.
Les característiques més importants que aporta XSD són:
• Està escrit en XML i, per tant, no cal aprendre un llenguatge nou per definir
esquemes XML.
• Té el seu propi sistema de dades, de manera que es podrà comprovar el

contingut dels elements.
• Suporta espais de noms per permetre barrejar diferents vocabularis.
• Permet ser reutilitzat i segueix els models de programació com herència

d’objectes i substitució de tipus.
2.4.1 Associar un esquema a un fitxer XML
A diferència del que passa en altres llenguatges de definició –com per exemple en
les DTD, en què l’associació s’ha d’especificar en el document XML–, per validar
un XML amb un XSD no cal modificar el fitxer XML. De totes maneres, també
és possible fer-ho definint-hi l’espai de noms.
Per associar un document XML a un document d’esquema cal definir-hi l’espai de

noms amb l’atribut xmlns, i per mitjà d’un dels atributs del llenguatge definir-hi
quin és el fitxer d’esquema:
1 <lliga xmlns:xsi="http://www.w3.org/2001/XMLSchema−instance"
2 xsi:noNamespaceSchemaLocation="lliga.xsd">
Es poden definir les referències al fitxer d’esquema de dues maneres, que podem
veure en la taula ??.
Taul a 2. 7. Definir referències a un esquema
Atribut Significat
noNamespaceSchemaLocation S’empra quan no es faran servir espais de noms en

el document.
schemaLocation S’empra quan es fan servir explícitament els noms

dels espais de noms en les etiquetes.
2.4.2 Definir un fitxer d’esquema
L’XSD està basat en XML i, per tant, ha de complir amb les regles d’XML:
• Tot i que no és obligatori normalment sempre es comença el fitxer amb la

declaració XML.
• Només hi ha un element arrel, que en aquest cas és <schema>.
Com que no s’està generant un document XML lliure sinó que s’es-
tà fent servir un vocabulari concret i conegut per poder fer servir els
elements XML sempre s’hi haurà d’especificar l’espai de noms d’XSD:
”http://www.w3.org/2001/XMLSchema”.

2 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
3 ...
4 </xs:schema>
En la declaració d’aquest espai de noms s’està definint que xs és l’àlies per fer
referència a totes les etiquetes d’aquest espai de noms. Els àlies per a XSD
normalment són xs o xsd, però en realitat no importa quin es faci servir sempre
Etiquetes d’XSD
que es faci servir el mateix en tot el document.
L’XSD defineix moltes etiquetes
i no es veuran totes aquí. Podeu L’etiqueta <schema> pot tenir diferents atributs, alguns dels quals podem veure
trobar totes les etiquetes
possibles en l’especificació en la taula 2.8.
www.w3.org/TR/xmlschema11-1
. Taul a 2. 8. Atributs de l’etiqueta ”<schema>”
Atribut Significat
attributeFormDefault Pot ser qualified si fem que sigui obligatori posar

l’espai de noms davant dels atributs o unqualified
si no ho fem. Per defecte es fa servir unqualified.
elementFormDefault Serveix per definir si cal l’espai de noms davant del

nom. Pot prendre els valors qualified i
unqualified.
Atribut Significat
version Permet definir quina versió del document d’esquemes

estem definint (no és la versió d’XML Schemas).
A partir de l’etiqueta arrel ja es poden començar a definir les etiquetes del

vocabulari que es vol crear.
Definició d’elements
Els elements es defineixen tal com es veu a la figura 2.11, fent servir l’etiqueta
<element>, i amb atributs s’hi especifica com a mínim el nom i opcionalment el
tipus de dades que contindrà l’element.
Fi g ura 2 .11 . Definició d’un element
L’XSD divideix els elements en dos grans grups basant-se en les dades que
contenen:
• Elements amb contingut de tipus simple: són elements sense atributs que
només contenen dades.
• Elements amb contingut de tipus complex: són elements que poden tenir
atributs, no tenir contingut o contenir elements.
A partir de la definició es pot veure que gairebé sempre hi haurà algun tipus
complex, ja que l’arrel normalment contindrà altres elements.
Elements amb contingut de tipus simple
Es consideren elements amb contingut de tipus simple aquells que no

contenen altres elements ni tenen atributs.
La versió 1.1 d’XSD defineix una cinquantena de tipus de dades diferents, que es
poden trobar a la seva definició (www.w3.org/TR/xmlschema11-2). Entre els més
usats en destaquen els de la taula 2.9.
Taul a 2. 9. Tipus de dades més usats en XSD
Tipus Dades que s’hi poden emmagatzemar
string Cadenes de caràcters
decimal Valors numèrics
boolean Només pot contenir ‘true’ o ‘false’ o (1 o 0)
date Dates en forma (AAAA-MM-DD)
anyURI Referències a llocs (URL, camins de disc...)
base64binary Dades binàries codificades en base64
integer Nombres enters
A partir dels tipus bàsics, l’estàndard en crea d’altres amb l’objectiu de tenir tipus
de dades que es puguin adaptar millor als objectius de qui dissenya l’esquema. En
aquest sentit apareixen els tipus anomenats positiveInteger, nonNegativeInteger,
gYearMonth, unsignedInt...
Els tipus de dades permeten restringir els valors que contindran les etiquetes XML.
Per exemple, si es parteix de la definició següent:
1 <xs:element name="posicio" type="xs:integer"/>

2 </xs:schema>
Només s’aconseguirà validar un element si el seu contingut és un nombre enter.

Per exemple, l’exemple següent no validarà:
1 <posicio>Primer</posicio>
En la taula 2.10 es poden veure exemples de definicions d’elements i valors que

hi validen.
Taul a 2. 10 . Exemples d’elements i què s’hi pot validar
Etiqueta Exemple
<xs:element name=“dia” type=“xs:date” /> <dia>2011-09-15</dia>
<xs:element name=“alçada” type=“xs:integer”/> <alçada>220</alçada>
<xs:element name=“nom” type=“xs:string”/> <nom>Pere Puig</nom>
<xs:element name=“mida” type=“xs:float”/> <mida>1.7E2</mida>
<xs:element name=“lloc” type=“xs:anyURI”/> <lloc>http://www.ioc.cat</lloc>
Quan es defineix una etiqueta en XSD s’està definint que l’etiqueta haurà de sortir
en el document XML una vegada. És bastant habitual que hi hagi etiquetes que
es repeteixin un nombre determinat de vegades. En XSD això s’ha simplificat per
mitjà d’uns atributs de l’etiqueta <element> que determinen la cardinalitat dels
elements:
• minOccurs: permet definir quantes vegades ha de sortir un element com a

mínim. Un valor de ‘0’ indica que l’element pot no sortir.
• maxOccurs: serveix per definir quantes vegades com a màxim pot sortir
un element. unbounded implica que no hi ha límit en les vegades que pot

sortir.
Fent servir els atributs es pot definir que l’element <nom> ha de sortir una vegada
i l’element <cognom> un màxim de dues vegades.
1 <xs:element name="nom" />
2 <xs:element name="cognom" maxOccurs="2"/>
També es poden donar valors als elements amb els atributs fixed, default i
nullable.
L’atribut fixed permet definir un valor obligatori per a un element:

1 <xs:element name="centre" type="xs:string" fixed="IOC"/>
De manera que només es podrà definir el contingut amb el valor especificat (o

sense res):
1 <centre />
2 <centre>IOC</centre>
Però mai un valor diferent de l’especificat:

1 <centre>Institut Cendrassos</centre>
A diferència de fixed, default assigna un valor per defecte però deixa que sigui
canviat en el contingut de l’etiqueta.
1 <xsi:element name="centre" type="xs:string" default="IOC" />
La definició permetria validar amb els tres casos següents:

1 <centre />
2 <centre>IOC</centre>
3 <centre>Institut Cendrassos</centre>
L’atribut nullable es fa servir per dir si es permeten continguts nuls. Per tant,
només pot prendre els valors yes o no.
Tipus simples personals

Com que a vegades pot interessar definir valors per als elements que no han de
coincidir necessàriament amb els estàndards, l’XSD permet definir tipus de dades
personals. Per exemple, si es vol un valor numèric però que no accepti tots els
valors sinó un subconjunt dels enters.
Per definir tipus simples personals no es posa el tipus a l’element i s’hi defineix
un fill <simpleType>.
1 <xs:element name="persona">
2 <xs:simpleType>
3 ...
4 </xs:simpleType>
5 </xs:element>
Dins de simpleType s’especifica quina és la modificació que s’hi vol fer. El més
corrent és que les modificacions sigui fetes amb list, union, restriction o
A pesar que es poden extension.
definir llistes de valors no es
recomana gaire fer-ne servir.
La majoria dels experts
creuen que és millor definir
Fer servir list permetrà definir que un element pot contenir llistes de valors. Per
els valors de la llista fent tant, per especificar que un element <partits> pot contenir una llista de dates es
servir repeticions
d’etiquetes. definiria:
1 <xs:element name="partits">
2 <xs:simpleType>
3 <xs:list itemType="xs:date"/>
4 </xs:simpleType>
5 </xs:element>
L’etiqueta validaria amb una cosa com:
1 <partits> 2011−01−07 2011−01−15 2011−01−21</partits>
Els elements simpleType també es poden definir amb un nom fora dels
elements i posteriorment usar-los com a tipus de dades personal.
1 <xs:simpleType name="dies">
2 <xs:list itemType="xs:date"/>
3 </xs:simpleType>
4
5 <xs:element name="partits" type="dies"/>
Fent servir els tipus personalitzats amb nom es poden crear modificacions de tipus
union. Els modificadors union serveixen per fer que es puguin mesclar tipus
diferents en el contingut d’un element.
La definició de l’element <preu> farà que l’element pugui ser de tipus valor o
de tipus simbol.
1 <xs:element name="preus">
2 <xs:sipleType>
3 <xs:union memberTypes="valor simbol"/>
4 </xs:simpleType>
5 </xs:element>
Amb això li podríem assignar valors com aquests:
1 <preus>25 A
C</preus>
Però sense cap mena de dubte el modificador més interessant és el que permet
definir restriccions als tipus base. Amb el modificador restriction es poden crear
tipus de dades en què només s’acceptin alguns valors, que les dades compleixin
una determinada condició, etc.
L’element <naixement> només podrà tenir valors enters entre 1850 i 2011 si es
defineix d’aquesta manera:
1 <xs:simpleType name="any_naixement">
2 <xs:restricion base="xs:integer">
3 <xs:maxInclusive value="2011"/>
4 <xs:minInclusive value="1850"/>
5 </xs:restriction>
6 </xs:simpleType>
7
8 <xs:element name="naixement" type="any_naixement"/>
Es poden definir restriccions de molts tipus per mitjà d’atributs (taula 2.11).
Normalment els valors de les restriccions s’especifiquen en l’atribut value:
Taul a 2. 11 . Atributs que permeten definir restriccions en XSD
Elements Resultat
maxInclusive / maxExclusive Es fa servir per definir el valor numèric màxim que

pot agafar un element.
minInclusive / minExclusive Permet definir el valor mínim del valor d’un element.
length Amb lenght restringim la llargada que pot tenir un

element de text. Podem fer servir <xs:minLength> i
<xs:maxLenght> per ser més precisos.
enumeration Només permet que l’element tingui algun dels valors

especificats en les diferents línies <enumeration>.
totalDigits Permet definir el nombre de dígits d’un valor numèric.
fractionDigits Serveix per especificar el nombre de decimals que

pot tenir un valor numèric.
pattern Permet definir una expressió regular a la qual el valor

de l’element s’ha d’adaptar per poder ser vàlid.
Per exemple, el valor de l’element <resposta> només podrà tenir un dels tres
valors “A”, “B” o “C” si es defineix d’aquesta manera:
1 <xs:element name="resposta">
2 <xs:simpleType>
3 <xs:enumeration value="A"/>
4 <xs:enumeration value="B"/>
5 <xs:enumeration value="C"/>
6 </xs:simpleType>
7 </xs:element>
Una de les restriccions més interessants són les definides per l’atribut pattern,
que permet definir restriccions a partir d’expressions regulars. Com a norma
general tenim que si s’especifica un caràcter en el patró aquest caràcter ha de sortir
en el contingut; les altres possibilitats les podem veure a la taula 2.12
Taul a 2. 12 . Definició d’expressions regulars
Símbol Equivalència
.
Qualsevol caràcter
\d Qualsevol dígit
\D Qualsevol caràcter no dígit
\s Caràcters no imprimibles: espais, tabuladors, salts de

línia...
\S Qualsevol caràcter imprimible
x* El de davant de * ha de sortir 0 o més vegades
x+ El de davant de + ha de sortir 1 o més vegades

Tau la 2 . 12 (continuació)
Símbol Equivalència
x? El de davant de ? pot sortir o no
[abc] Hi ha d’haver algun caràcter dels de dins
[0-9] Hi ha d’haver un valor entre el dos especificats, amb

aquests inclosos
x{5} Hi ha d’haver 5 vegades el que hi hagi al davant dels

claudàtors
x{5,} Hi ha d’haver 5 o més vegades el de davant
x{5,8} Hi ha d’haver entre 5 i 8 vegades el de davant
Fent servir aquest sistema es poden definir tipus de dades molt personalitzats. Per
exemple, podem definir que una dada ha de tenir la forma d’un DNI (8 xifres, un
guió i una lletra majúscula) amb aquesta expressió:
1 <xs:simpleType name="dni">
2 <xs:restriction base="xs:string">
3 <xs:pattern value="[0−9]{8}−[A−Z]"/>
4 </xs:restriction>
5 </xs:simpleType>
A part de les restriccions també hi ha l’element extension, que serveix per afegir
característiques extra als tipus. No té gaire sentit que surti en elements de tipus
simple però es pot fer servir, per exemple, per afegir atributs als tipus simples
(cosa que els converteix en tipus complexos).
Elements amb contingut de tipus complex
Els elements amb contingut de tipus complex són aquells que tenen atributs,
contenen altres elements o no tenen contingut.
Els elements amb contingut complex han rebut moltes crítiques perquè es conside-
ren massa complicats, però s’han de fer servir perquè en tots els fitxers d’esquema
normalment hi haurà un tipus complex: l’arrel del document.
Es considera que hi ha quatre grans grups de continguts de tipus complex:
1. Els que en el seu contingut només tenen dades. Per tant, són com els de
tipus simples però amb atributs.
2. Els elements que en el contingut només tenen elements.
3. Els elements buits.
4. Els elements amb contingut barrejat.
Els elements amb tipus complex es defineixen especificant que el tipus de dades
de l’element és <xs:complexType>.
1 <xs:element name="classe">
2 <xs:complexType>
3 ....
4 </xs:complexType>
5 </xs:element>
De la mateixa manera que amb els tipus simples, es poden definir tipus
complexos amb nom per reutilitzar-los com a tipus personalitzats.
1 <xs:complexType name="curs">
2 ...
3 </xs:complexType>
4
5 <xs:element classe type="curs"/>
Atributs
Una característica bàsica d’XSD és que només els elements de tipus complex
poden tenir atributs. En essència no hi ha gaires diferències entre definir un
element o un atribut, ja que es fa de la mateixa manera però fent servir l’etiqueta
attribute.
Els tipus de dades són els mateixos i, per tant, poden tenir tipus bàsics com en
l’exemple següent:
1 <xs:attribute name="número" type="xs:integer" />
S’hi poden posar restriccions de la mateixa manera que en els elements. En aquest
exemple l’atribut any no pot tenir valors superiors a 2011 si es defineix d’aquesta
manera:
1 <xs:attribute name="any">
2 <xs:simpleType>
3 <xs:restriction base="xs:integer">
5 </xs:restriction>
6 </xs:simpleType>
7 </xs:attribute>
Tret que s’especifiqui el contrari, els atributs sempre són opcionals.
L’etiqueta <attribute> té una sèrie d’atributs que permeten definir característi-

ques extra sobre els atributs (taula 2.13).
Taul a 2. 13 . Atributs més importants de xs:attribute
Atribut Ús
use Permet especificar si l’atribut és obligatori (required),

opcional (optional) o bé no es pot fer servir
(prohibited).
default Defineix un valor per defecte.
fixed Es fa servir per definir valors obligatoris per als

atributs.
Atribut Ús
form Permet definir si l’atribut ha d’anar amb l’àlies de

l’espai de noms (qualified) o no (unqualified).
Per exemple, l’atribut any s’haurà d’especificar obligatòriament si es defineix de

la manera següent:
1 <xs:attribute name="any" type="xs:integer" use="required" />
’simpleContent’
Si l’element només conté text, el contingut de complexType serà un
simpleContent. El simpleContent permet definir restriccions o extensions a
elements que només tenen dades com a contingut.
La diferència més important és que en aquest cas es poden definir atributs en

l’element. Els atributs s’afegeixen definint una extensió al tipus fet servir en
l’element.
En aquest exemple l’element <Mida> té contingut de tipus enter i defineix dos

atributs, llargada i amplada, que també són enters.
1 <xs:complexType name="Mida">
2 <xs:simpleContent>
3 <xs:extension base="xs:integer">
4 <xs:atribute name="llargada" type="xs:integer"/>
5 <xs:atribute name="amplada" type="xs:integer"/>
6 </xs:extension>
7 </xs:simpleContent>
8 </xs:complexType>
Contingut format per elements

Els elements que contenen altres elements també poden ser definits en XSD dins
d’un <complexType> i poden ser alguns dels elements de la taula 2.14.
Taul a 2. 14 . Elements per definir contingut complex
Etiqueta Serveix per
sequence Especificar el contingut com una llista ordenada

d’elements.
choice Permet especificar elements alternatius.
all Definir el contingut com una llista desordenada

d’elements.
complexContent Estendre o restringir el contingut complex.
L’element <sequence> és una de les maneres amb què el llenguatge XSD permet
que s’especifiquin els elements que han de formar part del contingut d’un element.
Fins i tot en el cas en què només hi hagi una sola etiqueta es pot definir com a una
seqüència.
La condició més important que tenen és que els elements del document XML
per validar han d’aparèixer en el mateix ordre en el qual es defineixen en la
seqüència.
2 <xs:complexContent>
3 <xs:sequence>
4 <xs:element name="nom" type="xs:string"/>
5 <xs:element name="cognom" type="xs:string" maxOccurs="2"/>
6 <xs:element name="tipus" type="xs:string" />
7 </xs:sequence>
8 </xs:complexContent>
9 </xs:element>
En l’exemple anterior es defineix que abans de l’aparició de <tipus> poden

aparèixer un o dos cognoms.
1 <persona>
2 <nom>Marcel</nom>
4 <cognom>Lozano</cognom>
5 <tipus>Professor</tipus>
6 </persona>
No validarà cap contingut si algun element no està exactament en el mateix ordre.
1 <persona>
2 <tipus>Professor</tipus>
4 <nom>Marcel</nom>
5 </persona>
Les seqüències poden contenir dins seu altres seqüències d’elements.
1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="

qualified">
3 <xs:complexType>
4 <xs:sequence>
5 <xs:element name="nomcomplet">
6 <xs:complexType>
7 <xs:sequence>
9 <xs:element name="cognom" type="xs:string"
maxOccurs="2"/>
10 </xs:sequence>
11 </xs:complexType>
12 </xs:element>
13 <xs:element name="professió" type="xs:string"/>
14 </xs:sequence>
16 </xs:element>
17 </xs:schema>
L’element <choice> serveix per fer que s’hagi de triar una de les alternatives de
les que es presenten dins seu.
En aquest exemple l’element persona podrà contenir o bé l’etiqueta

<nomCognoms> o bé <dni>, però no totes dues.
1 <xs:complexType nom="persona">
2 <xs:choice>
3 <xs:element name="nomCognoms" type="xs:string"/>

4 <xs:element name="dni" type="xs:string"/>
5 </xs:choice>
Entre les alternatives hi pot haver seqüències o altres elements <choice>. La

definició següent és un exemple més elaborat que l’anterior i permet que es pugui
triar entre els elements <nom> i <cognom> o <dni>.
1 <xs:choice>
2 <xs:sequence>
5 </xs:sequence>
6 <xs:element name="dni" type="xs:string"/>
7 </xs:choice>
La diferència més important entre l’element <all> i <sequence> és l’ordre.

L’element <all> permet especificar una seqüència d’elements però permet que
s’especifiquin en qualsevol ordre.
Per tant, si definim l’element <persona> de la manera següent:

2 <xs:complexType>
3 <xs:all>
4 <xs:element name="nom"/>
5 <xs:element name="cognom"/>
6 </xs:all>
7 </xs:complexType>
8 </xs:element>
Ens servirà per validar tant aquest document:

1 <persona>
2 <nom>Pere</nom>
3 <cognom>Garcia</nom>
com aquest:
1 <persona>
2 <cognom>Garcia</nom>
3 <nom>Pere</nom>
Però sempre s’han de tenir en compte les limitacions d’aquest element que no eren
presents en les seqüències ordenades:
• Dins seu només hi pot haver elements. No hi pot haver ni seqüències, ni

alternatives.
• No es pot fer servir la cardinalitat en els elements que contingui, ja que

provocaria un problema de no-determinisme.
Per tant, l’exemple següent no és correcte, ja que es demana que <cognom> pugui
sortir dues vegades.
1 <xs:all>
3 <xs:element name="cognom" maxOccurs="2" type="xs:string"/>
4 </xs:all>
Una possible manera de permetre que es puguin especificar el nom i els dos
cognoms en qualsevol ordre seria fer el següent:
1 <xs:complexType>
2 <xs:choice>
3 <xs:sequence>
6 </xs:sequence>
7 <xs:sequence>
10 </xs:sequence>
11 </xs:choice>
’complexContent’
L’etiqueta complexContent permet definir extensions o restriccions a un tipus
complex que contingui contingut barrejat o només elements.
Això fa que amb una extensió es pugui ampliar un contingut complex ja existent
o restringir-ne els continguts.
Per exemple, si ja hi ha definit un tipus de dades nomComplet en què hi ha els

elements <nom> i <cognom> se’n pot reutilitzar la definició per definir un nou
tipus de dades, agenda, en què s’afegeixi l’adreça de correu electrònic.
1 <xs:complexType name="nomComplet">
2 <xs:sequence>
5 </xs:sequence>
6 </xs:complexType>
7
8 <xs:complexType name="agenda">
10 <xs:extension base="nomComplet">
11 <xs:sequence>
12 <xs:element name="email" type="xs:string" />
13 </xs:sequence>
14 </xs:extension>
D’aquesta manera es podrà definir un element de tipus agenda:
1 <xs:element name="persona" type="agenda"/>
que haurà de tenir els tres elements <nom>, <cognom>, i <email>:
1 <persona>
2 <nom>Pere</nom>
4 <email>pgarcia@ioc.cat</email>
5 </persona>
Elements sense contingut

Per a XSD els elements sense contingut són sempre de tipus complex. En la
definició simplement no s’especifica cap contingut i tindrem un element buit.
1 <xs:element name="delegat">
2 <xs:complexType />
3 </xs:element>
La definició permet definir l’element d’aquesta manera:

1 <delegat />
Si l’element necessita atributs simplement s’especifiquen dins del complexType.

1 <xs:element name="delegat">
2 <xs:complexType>
3 <xs:attribute name="any" use="required" type="xs:gYear"/>
4 </xs:complexType>
5 </xs:element>
I ja es podrà definir l’atribut en l’element buit:

1 <delegat any="2012"/>
Contingut barrejat
Els elements amb contingut barrejat són els elements que tenen de contingut tant
elements com text. Es va pensar per poder incloure elements enmig d’un text
narratiu.
En XSD el contingut barrejat es defineix posant l’atribut mixed=“true” en la

definició del l’element <complexType>.
1 <xs:element name="carta">
2 <xs:complexType mixed="true">
3 <xs:sequence>
5 <xs:element name="dia" type="xs:gDay"/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
Això ens permetria validar un contingut com aquest:

1 <carta>Estimat senyor <nom>Pere<nom>:
2
3 Li envio aquesta carta per recordar−li que hem quedat per
4 trobar−nos el dia <dia>12</dia>
5 </carta>
2.4.3 Exemple de creació d’un XSD
Es poden crear definicions de vocabularis XSD a partir de la idea del que volem
que continguin les dades o bé a partir d’un fitxer XML de mostra.
Enunciat
En un centre en què només s’imparteixen els cicles formatius d’SMX i ASIX, quan
han d’entrar les notes als alumnes ho fan creant un arxiu XML com el següent:

2 <classe modul="3" nommodul="Programació bàsica">
3 <curs numero="1" especialitat="ASIX">
4 <professor>
5 <nom>Marcel</nom>
7 </professor>
8 <alumnes>
9 <alumne>
12 <nota>5</nota>
13 </alumne>
14 <alumne delegat="si">
17 <nota>3</nota>
18 </alumne>
19 <alumne>
20 <nom>Manel</nom>
22 <nota>8</nota>
23 </alumne>
24 </alumnes>
25 </curs>
26 </classe>
A la secretaria necessiten que es generi la definició del vocabulari en XSD per

comprovar que els fitxers que reben són correctes.
Resolució
A l’hora de dissenyar un esquema des d’un XML sempre s’ha de partir d’un fitxer
XML que tingui totes les opcions que poden sortir en cada element, o el resultat
no serà vàlid per a tots els fitxers.
Una de les coses que s’han de tenir en compte a l’hora de fer un exercici com aquest
és que no hi ha una manera única de fer-lo. Es pot fer amb tipus personalitzats,
sense tipus personalitzats, a vegades es pot resoldre combinant uns elements però
també amb uns altres, etc. Per tant, la solució que s’oferirà aquí és només una de
les possibles solucions.
Una altra cosa que s’ha de tenir en compte és que els editors XML solen oferir una
manera gràfica de crear XSD que permet crear esquemes de manera més senzilla,
com es pot veure en la figura 2.12.
F igu r a 2. 1 2 . Creació d’esquemes en mode disseny de l’oXygen XML Editor
Anàlisi
La primera fase normalment consisteix a analitzar el fitxer per determinar si hi ha
parts que poden ser susceptibles de formar un tipus de dades. En l’exercici es pot
veure que tant per al professor com per als alumnes les dades que contenen són
semblants (els alumnes afegeixen la nota), i per tant es pot crear un tipus de dades
que farà més simple el disseny final.
Per tant, en l’arrel podem crear el tipus complex persona, que contindrà el nom
i el cognom.
1 <xs:complexType name="persona">
2 <xs:sequence>
4 <xs:element name="cognom" type="xs:string"/>
5 </xs:sequence>
6 </xs:complexType>
Com que els alumnes són iguals però amb un element extra es pot aprofitar el tipus
persona estenent-lo.
1 <xs:complexType name="estudiant">
3 <xs:extension base="persona">
4 <xs:sequence>
5 <xs:element name="nota">
6 ...
7 </xs:element>
8 </xs:sequence>
9 </xs:extension>
Les notes no poden tenir tots els valors (només d’1 a 10), o sigui, que es pot afegir
una restricció al tipus enter.
2 <xs:simpleType>
6 </xs:restriction>
7 </xs:simpleType>
8 </xs:element>
Desenvolupament
L’arrel sempre serà de tipus complex perquè conté atributs i tres elements, de
manera que es pot començar la declaració com una seqüència d’elements.
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element name="curs">
5 ...
6 </xs:element>
7 <xs:element name="professor" type="persona"/>
8 <xs:element name="alumnes">
9 ...
10 </xs:element>
11 </xs:sequence>
13 </xs:element>
S’han deixat els elements <curs> i <alumnes> per desenvolupar-los, mentre que
l’element <professor> ja es pot tancar perquè s’ha definit el tipus persona.
L’element <curs> no té contingut i, per tant, serà de tipus complex. A més, s’hi
han de definir dos atributs.
2 <xs:complexType>
3 <xs:attribute name="numero" use="required">
4 ...
5 </xs:attribute>
6 <xs:attribute name="especialitat" use="required">
7 ...
8 </xs:attribute>
9 </xs:complexType>
10 </xs:element>
Els atributs s’han de desenvolupar perquè no poden tenir tots els valors:
• numero només pot ser “1” o “2”.
• especialitat serà “SMX” o “ASIX”.
La manera més adequada per fer-ho serà restringir els valors amb una enumeració.
2 <xs:simpleType>
4 <xs:enumeration value="1"/>
6 </xs:restriction>
7 </xs:simpleType>
8 </xs:attribute>
10 <xs:simpleType>
12 <xs:enumeration value="ASIX"/>
13 <xs:enumeration value="SMX"/>
14 </xs:restriction>
15 </xs:simpleType>
16 </xs:attribute>
Ja només queda per desenvolupar <alumnes>, que té una repetició d’elements

<alumne>, del qual ja n’hi ha un tipus.
1 <xs:element name="alumne">
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element name="alumne" type="estudiant"
5 maxOccurs="unbounded" minOccurs="1"/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
El resultat final serà:

2 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
3
4 <xs:complexType name="persona">
5 <xs:sequence>
7 <xs:element name="cognom" type="xs:string"/>
8 </xs:sequence>
9 </xs:complexType>
10
11 <xs:complexType name="estudiant">
13 <xs:extension base="persona">
14 <xs:sequence>
16 <xs:simpleType>
21 </xs:simpleType>
22 </xs:element>
23 </xs:sequence>
24 <xs:attribute name="delegat" use="optional">
25 <xs:simpleType>
27 <xs:enumeration value="si"/>
29 </xs:simpleType>
30 </xs:attribute>
31 </xs:extension>
34
36 <xs:complexType>
37 <xs:sequence>
39 <xs:complexType>
40 <xs:sequence>
41 <xs:element name="professor" type="persona"/>
42 <xs:element name="alumnes">
43 <xs:complexType>
44 <xs:sequence>
45 <xs:element name="alumne" type="estudiant"
maxOccurs="unbounded" />
46 </xs:sequence>
48 </xs:element>
49 </xs:sequence>
51 <xs:simpleType>
56 </xs:simpleType>
57 </xs:attribute>
59 <xs:simpleType>
61 <xs:enumeration value="ASIX"/>
62 <xs:enumeration value="SMX"/>
64 </xs:simpleType>
65 </xs:attribute>
67 </xs:element>
68 </xs:sequence>
69 <xs:attribute name="modul" use="required" type="xs:integer" />
70 <xs:attribute name="nommodul" use="required" type="xs:string" />
72 </xs:element>
73 </xs:schema>
2.5 Conversió entre esquemes
Una de les eines que s’han de tenir en compte a l’hora de fer esquemes és que ja
hi ha eines que permeten convertir els llenguatges de definició d’esquemes d’un
format a un altre.
A pesar d’això sempre s’hauran de revisar els resultats per comprovar que no s’ha
perdut cap significat important en fer la conversió, ja que els sistemes automàtics
no són perfectes.
La majoria dels editors XML porten alguna eina per fer la conversió (figura 2.13)
però també hi ha eines específiques per fer conversions, com el programa de codi
obert Trang.
Fig ur a 2. 1 3 . L’oXygen permet convertir els esquemes

d’un format a un altre
2.5.1 Trang
El Trang és un programa de codi obert que permet convertir les definicions de

vocabularis fetes en un sistema a un altre. Pot convertir els llenguatges següents:
• RELAX NG (XML syntax)
• RELAX NG compact syntax
• XML 1.0 DTD
• W3C XML Schema
Per fer la conversió simplement hem d’especificar el fitxer que es vol convertir i
en què es vol convertir. L’única condició és que l’esquema d’origen no sigui un
XML Schema.
Es pot convertir fent servir fitxers que tinguin les extensions per defecte: DTD
(.dtd), XML Schemas (.xsd), RELAX NG (.rng), RELAX NG compact (.rnc).
Amb això es crearà alumnes.xsd a partir d‘alumnes.dtd.
1 $ trang alumnes.dtd alumnes.xsd
O bé especificant explícitament quin és el tipus de fitxer d’entrada (-I) i quin el

de sortida (-O).
1 $ trang −I dtd −O xsd alumnes.dtd alumnes.xsd
Una de les característiques interessants que té és que pot crear el vocabulari basant-
se en fitxers XML de mostra. A partir del fitxer XML, alumnes.xml, es pot fer
que el Trang generi automàticament l’XML Schema que el validaria executant:
1 $ trang alumnes.xml alumnes.xsd
Si es tenen diversos documents XML també pot generar l’esquema associat amb
aquests:
1 $ trang *.xml alumnes.xsd

Àmbits d'aplicació de l'XML
Xavier Sala

d’informació
Llenguatges de marques i sistemes de gestió d’informació Àmbits d'aplicació de l'XML
Índex
Introducció 5
1 Sindicació de continguts 9
1.1 "Feeds" o canals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 RSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.1 RSS 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.2 Llenguatge RSS 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.1 Llenguatge Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4 Validació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.5 Agregadors / lectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5.1 Lectors via web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.5.2 Programari d’escriptori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.6 Problemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2 Conversió i adaptació de documents XML 31

2.1 Ús de CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2 Transformació de documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.1 XSL-FO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Processadors XPath o XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1 Biblioteques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.1 Vista d’arbre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.2 Programari per avaluar XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.3 Navegació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.4 Seqüències . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4.5 Funcions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.5 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.5.1 Programes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.5.2 El procés de transformació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.5.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3 Bases de dades natives XML. Llenguatge de consultes (XQuery) 67

3.1 Bases de dades relacionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.1.1 Convertir les dades XML en relacionals . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.1.2 Sistemes relacionals amb extensions XML . . . . . . . . . . . . . . . . . . . . . . . 70
3.2 XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.2.1 Processadors XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.2.2 Consultes XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.2.3 Comentaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.2.4 Càrrega de documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.2.5 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Llenguatges de marques i sistemes de gestió d’informació Àmbits d'aplicació de l'XML
3.2.6 Expressions avaluables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.2.7 Expressions FLWOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.2.8 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.2.9 El pròleg XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.2.10 Actualitzacions de dades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.3 Bases de dades natives XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.3.1 Característiques més importants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3.2 Exemples de bases de dades natives XML . . . . . . . . . . . . . . . . . . . . . . . . 96
3.3.3 eXist-db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Llenguatges de marques i sistemes de gestió d’informació 5 Àmbits d'aplicació de l'XML
Introducció
En aquesta unitat veureu diferents aspectes relacionats amb XML: les tecnologies
de sindicació de continguts, la transformació de documents i l’emmagatzematge
de dades XML.
La sindicació de continguts ha estat un dels darrers èxits a Internet, ja que permet

alliberar de feina els usuaris. En l’apartat “Sindicació de continguts” s’exploren
les característiques de dos dels llenguatges de sindicació més usats actualment:
RSS i Atom.
Atesa la llibertat que dóna XML, sovint l’intercanvi de dades entre programes no
serà immediat, sinó que requerirà que abans s’hi faci algun tipus de transformació.
En l’apartat “Conversió i adaptació de documents XML” veureu el llenguatge
XSLT per transformar documents XML.
En l’apartat “Bases de dades natives XML. Llenguatge de consultes (XQuery)”

s’exploraran les diferents possibilitats que hi ha per emmagatzemar documents
XML de manera que puguin ser recuperats ràpidament.
En acabar la unitat, l’alumne:
1. Genera canals de continguts analitzant i utilitzant tecnologies de sindicació.
• Identifica els avantatges que aporta la sindicació de continguts en la

gestió i transmissió de la informació.
• Defineix els àmbits d’aplicació de la sindicació de continguts.
• Analitza les tecnologies en què es basa la sindicació de continguts.
• Identifica l’estructura i la sintaxi d’un canal de continguts.
• Crea i valida canals de continguts.
• Comprova la funcionalitat i l’accés als canals de continguts.
• Utilitza eines específiques com agregadors i directoris de canals.
2. Fa conversions sobre documents XML utilitzant tècniques i eines de proces-

sament.
• Identifica la necessitat de la conversió de documents XML.

• Estableix àmbits d’aplicació de la conversió de documents XML.
• Analitza les tecnologies implicades i la manera de funcionament.
• Descriu la sintaxi específica utilitzada en la conversió i adaptació de
documents XML.
• Crea especificacions de conversió.
• Identifica i caracteritza eines específiques relacionades amb la conver-
sió de documents XML.
• Fa conversions amb diferents formats de sortida.
• Documenta i depura les especificacions de conversió
3. Gestiona informació en format XML analitzant i utilitzant tecnologies

d’emmagatzematge i llenguatges de consulta.
• Identifica els principals mètodes d’emmagatzematge de la informació

utilitzada en documents XML.
• Identifica els inconvenients d’emmagatzemar informació en format
XML.
• Estableix tecnologies eficients d’emmagatzematge d’informació en
funció de les seves característiques.
• Utilitza sistemes gestors de bases de dades relacionals en l’emmagat-
zematge d’informació en format XML.
• Utilitza tècniques específiques per crear documents XML a partir
d’informació emmagatzemada en bases de dades relacionals.
• Identifica les característiques dels sistemes gestors de bases de dades

natives XML.
• Instal·la i analitza sistemes gestors de bases de dades natives XML.
• Utilitza tècniques per gestionar la informació emmagatzemada en
bases de dades natives XML.
• Identifica llenguatges i eines per al tractament i emmagatzematge
d’informació i la inclusió en documents XML.
1. Sindicació de continguts
Quan es parla de sindicació de continguts s’està fent referència a l’intercanvi

actualitzat d’informació entre pàgines web.
La primera manera de sindicació que hi va haver va ser la integració de notícies

d’una pàgina dins d’una altra per mitjà d’algun tipus de programa que obtenia la
informació cercant per dins del contingut HTML. Però aquests programes tenien
el problema que sovint quedaven obsolets, ja que qualsevol canvi en la pàgina
original podia fer que deixessin de funcionar correctament.
A pesar del que pugui semblar per l’abundància de “decoració” que hi ha en les
pàgines web, el més important és el contingut. La informació continguda en els
articles, els fitxers, etc., és el que fa que els visitants hi tornin o no.
Amb el sistema tradicional de navegació per Internet, per a un usuari era molt
important obtenir els enllaços dels llocs web que li interessaven i emmagatzemar-
los d’alguna manera per poder-hi tornar ràpidament. Si es volien seguir els canvis
en les pàgines web l’única manera que hi havia era anar visitant de tant en tant la
pàgina per comprovar si hi havia novetats.
L’aparició del que es va conèixer com a Web 2.0 va complicar les coses. El Web
es va emplenar d’una gran quantitat de blogs i pàgines que publicaven informació,
i visitar-les totes per veure si hi havia canvis va passar a requerir molt de temps,
tot plegat per visitar pàgines que potser no havien canviat. S’havia d’optimitzar
d’alguna manera aquesta tasca.
F igur a 1. 1. Amb RSS és la informació la que ve a nosaltres
L’aparició dels sistemes estàndard de sindicació va fer possible obtenir la infor-

mació de les actualitzacions d’un lloc web d’una manera estable per mitjà d’una
adreça. La sindicació de continguts va canviar la manera com es recupera la

informació. Ja no calia anar a buscar la informació: era la informació la que
acudia a l’usuari (figura 1.1).
Fent servir la sindicació ja no cal que l’usuari visiti les pàgines que li interessen
per a veure si hi ha canvis perquè si n’hi ha ja els rebrà. Això comporta un estalvi
de temps, ja que no caldrà visitar pàgines per descobrir que no hi ha canvis.
Amb la sindicació el disseny de la pàgina original no afecta els programes que hi

busquen informació, ja que la sindicació de continguts està basada en XML i no
prioritza la informació d’estil sinó el contingut.
Aquesta està pensada perquè hi puguin interactuar tant els humans com els
programes, i això fa que es puguin dissenyar fàcilment aplicacions que obtinguin la
informació de manera automàtica sense que calgui cap tipus d’intervenció humana.
La participació de l’humà es limitarà a dir al programa quins llocs ha de vigilar.
A més, un cop l’usuari rep la informació en pot fer el que vulgui: filtrar-ne
els continguts, classificar-la per temes... Per tant, tindrà el control de quina és la
informació que vol veure i quina no.
Un altre dels avantatges que aporta la sindicació és inherent a XML. A diferència

del que passa amb HTML, és fàcil interpretar el contingut de la informació que es
rep i, per tant, també serà fàcil poder reutilitzar-ne el contingut per fer-hi altres
tasques.
A pesar que la sindicació es veu sovint com un sistema enfocat a detectar novetats
en el Web, també s’està fent servir per a mantenir actualitzacions en altres camps.
Per exemple, alguns programes d’ordinador fan servir RSS per saber si n’han sortit
actualitzacions i d’aquesta manera mantenen els programes actualitzats.
1.1 "Feeds" o canals
Un canal és un arxiu que conté una versió específica de la informació que

s’ha publicat en un lloc web.
En aquest arxiu es troba tota la informació sobre el lloc web i enllaços als seus
continguts. El gran avantatge és que en estar basat en XML es pot aconseguir
transmetre la informació de manera automatitzada i els receptors la podran
interpretar fàcilment.
Per poder obtenir la informació del canal normalment caldrà localitzar el fitxer.
Generalment aquests canals estan associats a una pàgina web i s’hi pot accedir per
mitjà d’un enllaç.
Els enllaços solen estar clarament especificats amb el text RSS, XML o bé fent
servir un grup d’icones (figura 1.2).
Fig ur a 1 . 2. Icones típiques per marcar contingut RSS
És bastant habitual que les pàgines que tenen contingut de sindicació tinguin en
algun lloc del seu web un enllaç o la icona d’RSS (figura 1.3).
Fig u ra 1. 3. Enllaç al canal de contingut de l’XTEC
Els fitxers dels canals normalment es passaran a programes que seran els que
s’encarregaran de recollir periòdicament les actualitzacions de la informació del
canal. En la terminologia de sindicació això se sol anomenar subscripció.
L’ús de canals aportarà diferents avantatges als usuaris:
• Com que funciona per subscripció, aquests només rebran les noticies
d’interès seu.
• El programa tendirà a donar informació més acurada a les seves preferencies

i gustos del que ho fan els cercadors generalistes com Google, ja que els
canals contenen el resultat d’una cerca.
• La informació es pot classificar i ordenar segons els gustos de l’usuari i

consumir-se segons els criteris que es vulgui.
• En qualsevol moment es pot deixar de seguir un canal sense haver de

demanar cap tipus de permís.
Al llarg dels anys s’han desenvolupat diverses tecnologies per crear canals com
CDF (channel definition format, desenvolupat per Microsoft), PointCast o Apple
MCF (meta content framework), però els llenguatges de creació de canals que
s’han fet més populars i que s’han convertit en la manera estàndard de sindicació
han estat sobretot RSS i en menys mesura Atom.
1.2 RSS
RSS són les sigles que es fan servir per anomenar diferents estàndards molt
populars per a la sindicació de continguts que s’han convertit en una manera
estàndard d’intercanviar informació al Web.
RSS no ha estat desenvolupat per cap organisme d’estàndards ni és una recomana-

Les sigles RSS
ció del W3C, però és un format obert i lliure sota llicència Creative Commons:
Les sigles RSS han anat canviant
de significat en les diferents A pesar que generalment es parla d’RSS de manera genèrica, al parlar d’RSS
versions d’RSS:
sempre s’hauria d’especificar quina és la versió d’RSS de la qual es parla, ja que
• Rich site summary
les versions existents són bastant diferents.
• RDF site summary Els vocabularis RSS són probablement uns dels vocabularis XML que han tingut
• Really simple més èxit de tots els que es fan servir a Internet. Han aconseguit aquesta popularitat
syndication
entre d’altres coses perquè són senzills i oberts.
Des de l’aparició d’RSS 0.9 el 1999 han anat apareixent diferents versions d’RSS
que es poden resumir en dos grans grups:
• RSS 0.92/ RSS 2.0
• RSS 1.0
Aquesta divisió va ser deguda a problemes d’enteniment sobre quin havia de ser
l’objectiu d’RSS i va fer que es creessin dues versions. A pesar de la semblança del
nom de totes dues, RSS 1.0 és un llenguatge basat en RDF (resource description
framework), cosa que el fa bastant diferent d’RSS 0.9.
La versió que es fa servir més és la 2.0, que s’assembla més a la versió 0.92 però
incorpora alguns aspectes de la versió 1.0. Probablement la versió 2.0 és una
de les més senzilles d’utilitzar; a pesar d’això, no obstant això, és una de les més
malinterpretades. Algunes de les definicions dels elements no sempre es fan servir
de la mateixa manera per a tots els canals.
1.2.1 RSS 3.0
RSS està aturat en les versions 2.0, en concret en la versió 2.0.1, perquè es
considera que ja té tot el suficient per funcionar, i perquè ha costat que fos molt
adoptat.
Hi ha una proposta per fer un “RSS 3.0” que, per no trencar amb la tradició, també
seria incompatible amb les altres versions:
• Abandonant XML per fer servir un llenguatge de marques més lleuger, ja

que es considera que XML és massa complex per fer tasques senzilles.
• Abandonar l’ús d’espais de noms, ja que compliquen les coses.
• No permetre fer servir HTML dins d’RSS.
En aquesta proposta es defineix que els elements es posin en línies diferents i que
si el seu contingut no hi cap es comenci a la línia següent deixant un espai en blanc.
A més, hi ha d’haver una línia en blanc per separar les notícies.
1 title: Notícies
2 description: Canal de notícies
3 link: http://noticiesA.cat/rss30
4 creator: esport@noticesA.cat
5 language: ca−ES
6
7 title: Primera notícia
8 created: 2011−11−02
9 guid: 00795648−C1E0−11D6−9AA6−003065F376B6
10 description: Notícia número 1
11
12 title: Segona notícia
13 created: 2011−06−13
14 guid: 0894CB2F−C1E0−11D6−9649−003065F376B6
15 description: Notícia número 2
Podeu trobar més
informació sobre aquesta
versió a l’enllaç
www.aaronsw.com/2002/rss30
Molta gent no s’ha pres seriosament aquesta prescripció, però qui sap si amb el
temps s’aconseguirà que s’apliqui majoritàriament.
1.2.2 Llenguatge RSS 2.0 Algunes fonts diuen que el

80% dels canals RSS són
2.0, tot i que no hi ha
estadístiques oficials
Entre tots els canals disponibles, RSS 2.0 és el més usat amb molta diferència, i
per tant, la gran majoria dels programes lectors d’RSS el suporten.
Una de les característiques que defineixen RSS és que fa honor al seu nom oficial,
really simple syndication (sindicació realment senzilla), i és un sistema senzill.
Es tracta d’un sistema que no té cap estructura complexa, en què les etiquetes
descriuen el contingut que hi ha en l’element, en què pràcticament no es fan servir
els atributs per a res i els espais de noms només es fan servir en les extensions, si
n’hi ha.
L’arrel
RSS és un llenguatge XML, de manera que n’ha de complir les normes i, per tant,
només té un sol element arrel, <rss>. La funció d’aquest element és simplement
informar a qui llegeixi el document que el que està llegint és un canal RSS.
L’element arrel té un dels pocs atributs obligatoris de l’especificació, version,

que és necessari per indicar la versió que s’està fent servir. Aquest atribut serveix
perquè els programes sàpiguen quina versió d’RSS es fa servir en el document.
1 <rss version="2.0">
2 ...
3 </rss>
A pesar que s’hi pot especificar l’espai de noms, RSS no el té en compte, de manera
que mai no caldrà posar cap àlies davant de les seves etiquetes.
Però si el canal fa servir alguna extensió sí que caldrà que es defineixi l’espai de
Vegeu l’apartat “Espais de noms de les extensions que es fan servir.
noms” en la unitat
“Llenguatges de marques”.
1 <rss version="2.0"
2 xmlns:dc="http://purl.org/dc/elements/1.1/"
3 xmlns:content="http://purl.org/rss/1.0/modules/content/">
4 ...
5 </rss>
L’element <channel>
L’arrel només serveix per indicar que el document és de tipus RSS, i el contingut
del canal estarà dins de l’únic fill de <rss>, que s’anomena <channel>. L’element
<channel> serà el que contindrà totes les etiquetes que aporten informació sobre
el canal, i sobretot les que tindran les novetats del lloc.
Només hi pot haver una sola etiqueta <channel> en tot el document RSS.
2 <channel>
3 ... contingut ...
4 </channel>
5 </rss>
Es pot dividir el contingut d’un canal RSS en dos grans grups (figura 1.4):
1. Un grup d’etiquetes destinades a descriure el canal.
2. Els elements <item>, que són els que contindran el contingut del canal.
F igu r a 1. 4 . Divisió del contingut d’un document RSS

Per fer-ho tot més senzill algunes de les etiquetes es repeteixen en els dos grups.
Per exemple les etiquetes més importants de <channel>, que són <title>,
<link> i <description>, són també les més importants dels elements <item>.
Etiquetes per a descriure el canal
Els primers elements que es troben dins de l’element <channel> estan destinats
a donar informació sobre el canal RSS. Aquestes etiquetes no són de contingut ni
serà habitual que es produeixin canvis en els seus valors. L’especificació a l’hora de
definir els valors que s’han
de posar en cada una de les
Els elements més importants d’aquesta part són els elements <title>, <link> i etiquetes és poc concreta i
alguns dels seus elements
<description> (taula 1.1) que són obligatoris en tots els canals RSS. han estat subjectes a
diferents interpretacions per
part dels creadors de
Taul a 1. 1. Elements obligatoris de l’element ’channel’ contingut.
RSS 1.0, que està basat en
Element Ús l’estàndard del W3C RDF,
va néixer amb l’objectiu
d’intentar que els elements
title El nom del canal. És la manera com es coneix el d’RSS deixessin de ser tan
servei. malinterpretats. Però RSS
2.0 no parteix d’RSS 1.0
link Normalment s’inclou un enllaç a l’adreça on hi ha el sinó de les versions 0.9.
contingut HTML que es correspon amb el canal.
description Conté una descripció curta del contingut del canal.
Aquests són els únics elements obligatoris i, per tant, el document següent seria
un document RSS vàlid:
2 <channel>
3 <title>Canal de llenguatges de marques</title>
4 <link>http://ioc.xtec.cat/rss/Marques.html</link>
5 <description>Canal per entrar les notes del mòdul 4 d’ASIX</description>
6 </channel>
7 </rss>
A part dels elements obligatoris en RSS també n’hi ha uns quants que són
voluntaris i que serveixen per donar informació extra sobre el canal. Es poden
veure aquests elements a la taula 1.2.
Taul a 1. 2. Altres elements possibles de l’element ’channel’
Element Ús
language Especifica l’idioma en que està escrit el canal.
copyright Informació sobre el copyright del contingut.
managingEditor Correu electrònic del responsable del contingut.
webMaster Correu electrònic del responsable tècnic.
pubDate Darrera data de publicació en el canal.
category Categoria del contingut.
lastBuildDate Darrera data de modificació del canal.
generator Programa fet servir per generar el contingut.
docs Descriu el format específic.
ttl Temps que els clients han d’esperar per tornar a

demanar.
Element Ús
image Icona que representa el canal.
rating Fa servir una classificació americana sobre el

contingut.
cloud Grup de gent a la qual s’informa dels canvis.
textInput És una etiqueta antiga que ja no es fa servir.
skipHours En quines hores no es poden demanar

actualitzacions.
skipDays Quins dies no es poden demanar actualitzacions.
Contingut del canal
El contingut visible d’un canal RSS anirà en els elements <item>, dels quals n’hi
pot haver la quantitat que es vulgui (fins i tot cap).
Normalment cada vegada que es produeix una novetat en el lloc associat al

contingut d’un canal es crea un nou element item que s’afegeix al document.
A pesar que no sembla que tingui sentit crear ítems sense contingut, això és
estrictament possible perquè ítem no té cap element obligatori però sempre hi
ha d’haver un <description> o un <title>.
Per tant, el següent seria un document RSS correcte. Tenim dos ítems, un amb
títol sense contingut i un amb contingut sense títol.
2 <channel>
3 <title>RSS</title>
4 <link>http://ioc.xtec.cat/rss/RSS</link>
5 <description>Provant</description>
6 <item>
7 <title>Títol sense contingut</title>
8 </item>
9 <item>
10 <description>Contingut sense títol</description>
11 </item>
12 </channel>
13 </rss>
El més normal serà que hi hagi els elements <title>, <link>, i <description>
però a més també hi ha altres atributs que es poden veure a la taula 1.3 com
<pubDate> o <guid>.
Taul a 1. 3. Subelements d’ítem
Element Ús
title Títol del nou contingut.
link Enllaç al contingut en el lloc de referència.
description Contingut.
guid Una cadena que identifica totalment l’ítem per evitar

entrades duplicades en els programes. S’hi sol posar
l’URL del lloc.
Element Ús
pubDate Data i hora en què s’ha publicat.
author Correu electrònic de l’autor.
category Nom de la categoria que descriu el contingut.
comments Adreça de la pàgina on es poden entrar comentaris.
enclosure Identifica un fitxer extern associat. Normalment

música o vídeo.
source
Una referència al canal. És rar que hi sigui.
Contingut HTML
Al principi tothom feia servir text pla en els continguts del canal però aviat es va
començar a pensar a incloure HTML, sobretot en aquelles etiquetes que els usuaris
poden veure.
Estrictament parlant no es pot fer servir HTML dins d’RSS, perquè com que està
basat en XML ha d’estar ben format, mentre que l’HTML no té l’obligació d’estar
ben format i, per tant, en afegir HTML a un RSS hi ha la possibilitat que el resultat
sigui mal format.
En l’exemple següent, dins de l’element description es volia afegir una imatge

i s’ha fet servir l’etiqueta <img> d’HTML per fer-ho. El problema és que aquesta
etiqueta converteix el document en incorrecte, ja que aquest deixa d’estar ben
format (invalida la regla que diu que s’han de tancar totes les etiquetes que
s’obren).
1 <description>
2 Quina imatge més bonica! <img src="like.png">
3 </description>
Per tant, per afegir HTML a un document RSS s’ha de fer com en XML. Si es
vol afegir contingut que no ha de ser processat s’ha de fer per mitjà d’una secció
<![CDATA[...]]>. Per tant, l’exemple anterior es podria representar de la manera
següent:
1 <description>
2 <![CDATA[
3 <div>
4 Quina imatge més bonica! <img src="like.png">
5 </div>
6 ]]>
7 </description>
Per evitar problemes sovint tots els canals fan servir aquest sistema per a incloure
HTML dins dels elements RSS, tant si el contingut està ben format com si no.
Representació de dates
RSS fa servir el sistema de representació de dates que hi ha en un document

relativament obsolet, l’especificació RFC 822 (“ARPA Internet text messages”)
El format de les dates ha de seguir la forma següent:
1 Dia de la setmana, Dia Mes Any Hora:Minut:Segon Zona_Horaria
On:
• El dia de la setmana és opcional i només pot ser només una abreviació dels
noms en anglès: “Mon”, “Tue”, “Wed”, “Thu”, “Fri”, “Sat”, “Sun”.
• El mes també es defineix en abreviacions (“Jan”, “Feb”, “Mar”, “Apr”,

“May”, “Jun”, “Jul”, “Aug”, “Sep”, “Oct”, “Nov”, “Dec”).
• L’any sempre ha de tenir quatre dígits.
• La zona horària es pot expressar en diferències numèriques o per mitjà de

constants de temps americanes. El més corrent sol ser que sigui expressada
en GMT (universal time).
Per tant, seran dates correctes:
• Sat, 13 Aug 2011 10:43:37 GMT
• 13 Aug 2011 10:43:37 +0100
Extensions
La popularitat d’RSS ha fet que moltes grans companyies l’hagin fet servir per
a les seves tasques. Però a vegades no solament l’han fet servir sinó que hi han
afegit funcions segons les seves necessitats.
Amazon
La llibreria en línia Amazon permet accedir al seu catàleg de productes per mitjà d’RSS, de
manera que qualsevol pot estar al dia de què és el que s’està venent més, quines són les
novetats, etc., simplement subscrivint-se a un dels RSS.
Per exemple, aquest és el canal de llibres més venuts de programació web:
www.amazon.com/gp/rss/bestsellers/books/377888011/ref=zg_bs_377888011_rsslink
Com que RSS està basat en XML es pot barrejar amb altres llenguatges XML fent
servir els espais de noms. Això ha permès que qualsevol pugui incrementar la
funcionalitat d’RSS sense canviar-ne el nucli de funcionament. S’ha d’anar amb compte en
fer servir extensions perquè
no tots els lectors d’RSS les
Per tant, hi ha tota una sèrie d’extensions que es poden usar dins d’RSS per obtenir entenen.
funcions no previstes en l’especificació. Entre les més populars destaquen:
• Dublin core metadata initiative: es tracta d’una extensió que permet

introduir els elements definits en el Dublin core en RSS. Aquests elements
serveixen com a metadades per a descriure els recursos d’una xarxa
2 xmlns:dc="http://dublincore.org/documents/dcmi−namespace/">
• Content: l’objectiu de content és incloure el contingut d’un web dins d’un

canal RSS.
2 xmlns:content="http://purl.org/rss/1.0/modules/content/">
• Yahoo Media RSS: afegeix suport multimèdia. Incorpora tota una sèrie
d’elements i atributs pensats per donar millor suport multimèdia a RSS.
2 xmlns:media="http://search.yahoo.com/mrss/">
• BlogChannel RSS: afegeix un grup de funcionalitats pensades per treballar

amb blogs.
2 xmlns:C="http://backend.userland.com/blogChannelModule/">
Però com que estem parlant de vocabularis XML, això implica que qualsevol pot
crear la seva extensió pròpia d’RSS.
S’ha de tenir en compte que no sempre tots els lectors d’RSS comprenen les
extensions. Per tant, la recomanació general és només fer servir les extensions
que siguin absolutament necessàries per al contingut que es vol transmetre.
1.3 Atom
Atom va ser dissenyat pensant a superar els problemes d’interpretació que tenia
RSS 2.0 i evitar la complexitat afegida d’RSS 1.0. La seva idea era aprofitar les
millors coses dels RSS i arreglar les parts que en causaven confusió.
Un segon objectiu que el diferencia clarament d’RSS és que també es volia que no
solament servís per recuperar els canvis en la informació del canal sinó que també
es pogués fer servir de manera estandarditzada per afegir-hi informació. La
sindicació ha estat molt lligada als blogs i fins al moment cada programa per fer
blogs feia servir el seu protocol propi (Blogger API, MetaWebLog API, ...), que
estaven pensats només per un blog en concret.
Per tant, podem dividir Atom en dues parts:
• Atom syndication format: un llenguatge XML per sindicar continguts.
• Atom publishing protocol: un protocol basat en HTTP pensat per actualit-

zar i crear recursos en el Web.
Va ser desenvolupat per un comitè de l’IETF (Internet Engineering Task Force) i

va ser publicat en dos RFC (RFC 4287 i RFC 5023).
A part de les diferències en les etiquetes, les grans diferències amb RSS són que:
• Permet definir quin és el contingut de les etiquetes (text, HTML, etc.), però
també permet referències a arxius externs. En RSS no es defineix quin
contingut hi ha.
• Es pot fer servir dins d’altres documents XML, ja que té la seva definició i
fa servir els espais de noms. No es pot posar RSS dins d’altres documents
XML perquè no té en compte l’espai de noms.
• RSS no ofereix un protocol de publicació com Atom.
Però Atom, malgrat el suport obtingut (va ser adoptat per Google), no ha pogut
superar RSS 2.0.
1.3.1 Llenguatge Atom
Com a bon llenguatge XML, Atom té només una arrel, que és <feed>. Aquesta
etiqueta la poden fer servir els programes per detectar que el document que estan
llegint és de tipus Atom.
L’arrel <feed> sempre ha de tenir definit l’espai de noms dels documents Atom,
que és www.w3.org/2005/Atom. Si no s’especifica l’espai de noms el document
no validarà.
1 <feed xmlns="http://www.w3.org/2005/Atom">
2 ...
3 </feed>
El fet de tenir un espai de noms i de fer-lo servir possibilita que els documents
Atom es puguin mesclar amb documents XML d’altres vocabularis sense proble-
mes.
Atom té disponibles els atributs d’XML xml:lang, que serveix per identificar
l’idioma del document, i xml:base, que es fa servir per controlar com es resolen
les adreces relatives.
De la mateixa manera que en altres llenguatges de canals, com RSS, es poden

agrupar les etiquetes d’Atom en dos grups:
• Etiquetes que proporcionen dades sobre el canal.
• Etiquetes amb el contingut del canal.
Etiquetes amb dades del canal
Els elements obligatoris dins de l’etiqueta <feed> sempre han de tenir els
elements fills <title>, <id> i <updated> (taula 1.4).
Taul a 1. 4. Elements obligatoris en Atom
Element Ús
title És el nom del canal. Normalment és el de la pàgina

web que l’ha creat.
updated Darrer cop que es va actualitzar el canal.
id Identificador únic i universal del canal. Si es té una

adreça web que no està prevista que canviï en molt
de temps es pot fer servir aquesta adreça com a id.
Per tant, aquest seria un document Atom vàlid, ja que aquestes són les úniques
etiquetes obligatòries:
1 <?xml version="1.0" encoding="utf−8"?>

2 <feed xmlns="http://www.w3.org/2005/Atom">
3
4 <title>Atom IOC</title>
5 <updated>2011−08−13T15:20:02Z</updated>
6 <id>http://ioc.xtec.cat/</id>
7
8 </feed>
A part dels elements obligatoris, en l’especificació d’Atom també es fa referència

a uns elements que anomena “molt recomanables” (taula 1.5). Els elements
recomanables són <link> i <author>.
Taul a 1. 5. Elements molt recomanables en Atom
Element Ús
link Identifica la pàgina web equivalent al canal. S’hi

defineix la relació amb l’atribut rel.
author Es tracta d’un element que permet identificar l’autor

del canal. Hi pot haver múltiples autors.
I lògicament també hi ha tota una llista d’elements opcionals que es fan servir per
aportar informació extra sobre el canal (taula 1.6).
Taul a 1. 6. Elements opcionals
Element Ús
category A quina categoria pertany el feed.
contributor Gent que col·labora. N’hi pot haver tants com calguin.
generator Identifica el programa que s’ha fet servir per crear el

canal.
icon Enllaç a una icona identificativa del canal.
logo Enllaç al logotip del canal.
rights Informació sobre els drets d’ús del canal.
subtitle Títol secundari del canal.
Etiquetes de contingut del canal
Per definir les diferents entrades dins d’un canal es fa servir com a base l’element
<entry>. Cada nova aportació crearà un nou element <entry>, que com a
mínim ha de tenir les etiquetes <title>, <id>, <updated>, i a més un element
<content> o bé un element <link> (taula 1.7).
Taul a 1. 7. Elements obligatoris de ”entry”
Element Ús
title Títol de l’entrada que es publica.
id Identificador únic de l’entrada. Sol ser la URI de la

pàgina on és.
updated Data en què es va crear o actualitzar l’entrada.
content El contingut de l’entrada. S’hi pot especificar de quin

tipus és el contingut.
link Conté l’URL de l’entrada. N’hi pot haver diverses

sempre que es canviï el tipus o s’apunti a un lloc
diferent.
Com fa sovint l’especificació, Atom també defineix un segon nivell d’elements,

considerats “molt recomanats”, i que, per tant, també haurien de sortir. Entre els
recomanats hi haurà <content> o <link> si no s’han especificat anteriorment
(taula 1.8).
L’element <author> es converteix en obligatori si no se n’ha especificat cap en

les metadades del canal.
Taul a 1. 8. Elements molt recomanats a ’entry’
Element Ús
author Nom de l’autor de l’entrada. N’hi pot haver diversos.
summary Resum del contingut. Pot tenir l’atribut que indiqui de

quin tipus és el contingut que té.
I lògicament també hi ha elements opcionals (taula 1.9).

Taul a 1. 9. Elements opcionals a ’entry’
Element Ús
category Categoria de l’entrada. N’hi pot haver diverses.
published Data en què es va crear l’entrada.
rights Informació del copyright associada a l’entrada.
source Informació sobre d’on prové l’entrada. Es fa servir en

cas que l’entrada vingui d’un altre lloc i s’estigui
reaprofitant.
contributor Gent que ha col·laborat en l’entrada. Hi pot haver

diversos noms.
Descripció de persones
Les etiquetes <author> i <contributor> serveixen per a descriure una persona.

Les persones en Atom es defineixen fent servir una estructura XML que pot tenir
els tres elements que es poden veure a la taula 1.10.
Taul a 1. 10 . Descripció de persones
Etiqueta Ús
name Nom de la persona.
email Correu electrònic.
uri Adreça de la seva pàgina web.
De tots tres elements només <name> és obligatori; els altres són opcionals. Per
tant, podem definir el contingut de l’element <author> d’aquesta manera:
1 <author>
2 <name>Pere Garcia</name>
3 </author>
Però mai deixant el nom. I fer-ho d’aquesta manera seria incorrecte perquè no hi
ha l’element <name>.
1 <author>
2 <email>pere@ioc.cat</email>
3 <uri>http://ioc.xtec.cat/pere</uri>
Format de les dates
Atom fa servir l’RFC 3339 (ISO 8601) per definir el format de les dates. Les dates
en Atom han de tenir aquesta forma:
1 Any−Mes−DiaTHora:Minuts:Segons−zonahoraria
De manera que:
• Tots els valors són numèrics excepte la zona horària, que en alguns casos
pot ser el caràcter “Z” per indicar l’hora universal.
• Davant de la zona horària s’especifiquen les hores de retard o d’avançament

amb els símbols de suma o resta.
• Es fa servir la lletra “T” per separar els dies de les hores.
Per tant aquests valors serien correctes:
• 2011-08-13T19:16:20-00:00
• 2011-08-13T19:16:20Z
El contingut
Si no s’especifica cap atribut en l’element <content> o en <summary>, aquest

serà tractat com si fos text pla. Si es vol deixar clar que el contingut és en algun
altre format s’ha d’especificar amb l’atribut type, que normalment tindrà els
valors “text”, “html” o “xhtml”.
1 <content type="text">Contingut</content>
També es pot enllaçar a contingut extern via una adreça en l’atribut src i podem
especificar el tipus d’atribut amb type.
1 <content src="http://ioc.xtec.cat/Hola.mp3" type="audio/mpeg" />
1.4 Validació
Com que tant RSS com Atom són documents XML, es podrà comprovar que
són correctes fent servir les mateixes eines de comprovació que es fan servir
en XML.
Malgrat que és possible fer servir els validadors d’XML, el més normal és fer
servir programes específics per validar RSS i Atom. I com que aquests dos
vocabularis només tenen sentit en xarxa, els validadors més populars d’Atom i
RSS són en línia.
Entre els validadors d’RSS i Atom destaquen:
• Feed Validator (feedvalidator.org)
• Feed Validation Service de W3C (validator.w3.org/feed)
• Validome (www.validome.org/rss-atom)
Com a exemple es veurà com es fa per validar un document RSS fent servir un
d’aquests validadors (el procediment fent servir Atom és exactament el mateix).
Exemple de validació d’un document RSS
Un cop s’ha generat el fitxer del canal, per validar-lo cal accedir a l’adreça del validador
amb qualsevol navegador que suporti Javascript. En aquest cas anem a l’adreça del W3C
(validator.w3.org/feed).
El validador del W3C permet validar els documents RSS tant a partir d’una adreça d’Internet
com copiant el fitxer en el web mateix, tal com es pot veure en la figura 1.5.
Figu ra 1. 5. Possibles maneres de validar RSS en el web del W3C
Independentment de quin sigui el sistema triat, si se li passa aquest codi:
2 <channel>
3 <title>Canal de Llenguatges de Marques</title>
5 <description>Canal per entrar les notes del mòdul 4 d’ASIX
</description>
6 <item>
7 <link>http://ioc.xtec.cat/marques/RSS.html</link>
8 </item>
9 </channel>
10 </rss>
El programa detectarà una sèrie d’errors (figura 1.6). S’ha d’anar amb compte perquè
aquest validador no diferencia gaire l’aspecte dels errors del de les recomanacions.
F igu r a 1 . 6 . Errors detectats en validar el document
Es pot obtenir més informació dels errors detectats clicant en l’enllaç ”[help]”. Aquest enllaç
porta a una nova pàgina on es descriu l’error amb detall i en alguns casos explica com
solucionar-lo. En l’exemple, l’error és que l’element <item> ha de contenir o bé un <title>
o bé un <description>. S’hi afegeixen tots dos i tornem a validar el document.
2 <channel>
</description>
6 </channel>
7 <item>
8 <title>Exemple de com validar RSS</title>
10 <description>
11 Això és un exemple per veure com es fa per validar RSS
12 </description>
13 </item>
14 </rss>
Ara el document ja és vàlid, com es pot veure en la figura 1.7.
F igu r a 1 . 7 . Document vàlid
A pesar d’això encara hi surten les recomanacions per a no tenir problemes de

compatibilitat. En aquest els problemes són:
• Que s’afegeixi l’espai de noms d’Atom.
• Que s’hi defineixi un guid.
Definir el guid és relativament senzill. Es defineix dins de l’element <entry> un identificador

únic que pot ser una URL.
1 <guid>http://ioc.xtec.cat/rss/Marques.html</guid>
I l’altra recomanació és que s’afegeixi l’espai de noms d’Atom i un enllaç al document Atom.
Per tant, s’afegeix l’espai de noms a <rss>.
1 <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
I dins de <entry> s’afegeix l’enllaç Atom.
1 <atom:link href="http://ioc.xtec.cat/rss/Marques.xml" rel="self"

2 type="application/rss+xml" />
El resultat final serà aquest:
1 <?xml version="1.0" encoding="UTF−8" ?>

2 <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
3 <channel>
5 <link>http://ioc.xtec.cat/rss/Marques.xml</link>
</description>
7 <atom:link href="http://ioc.xtec.cat/rss/Marques.xml" rel
="self"
8 type="application/rss+xml" />
9 <item>
10 <title>Exemple de com validar RSS</title>
12 <description>
13 Això és un exemple per veure com es fa per validar
RSS.
14 </description>
15 <guid>http://ioc.xtec.cat/rss/Marques.html</guid>
16 </item>
17 </channel>
18 </rss>
El document ara validarà correctament.
1.5 Agregadors / lectors
Els agregadors i lectors de feeds són programes que permeten a l’usuari

mantenir en un sol lloc tota la informació dels canals que li interessen.
Entre altres coses:
• S’encarreguen d’actualitzar els canvis que s’hi van produint sense que
l’usuari hagi de visitar la pàgina.
• Porten el control dels continguts llegits i no llegits dels canals.
• Permeten veure un resum de les notícies d’un lloc web.
• S’hi poden organitzar les notícies en grups personalitzats.
• Permeten fer cerques d’informació entre la informació del canal.
Tant RSS com Atom són estàndards oberts, i això ha permès que s’hagin creat una
gran quantitat de lectors que els suporten i que ofereixen funcions extra per als
usuaris per intentar millorar-ne l’experiència.
A pesar que es poden llegir els canals des de diferents programes de correu o
els navegadors, normalment s’aconsegueix treballar de manera més còmoda i
personalitzable fent servir programes especialitzats.
En general podem dividir els programes lectors de canals en dos grans grups:
• Lectors web
• Lectors d’escriptori
A pesar de la divisió normalment l’aspecte visual d’aquests programes és relativa-

ment semblant. Tots solen tenir la pantalla dividida en blocs:
• En un dels blocs hi sol haver la llista de subscripcions en la qual es poden

agrupar aquestes subscripcions per temes.
• Un bloc per mostrar el contingut de cada una de les subscripcions.
En la imatge següent podem veure la semblança entre l’aspecte d’un programa

web com el Feedly i un programa d’escriptori com Liferea (figura 1.8).
Fi gur a 1 .8 . Comparació entre el Feedly i el Liferea
La gran diferència sol estar en els filtres o les característiques extra que ofereixen
cada un dels programes per fer l’ús més interessant per als usuaris: visualitzacions
originals, estadístiques, etc.
1.5.1 Lectors via web
Alguns dels agregadors més populars són els que s’executen directament des
d’un lloc web. Aquestes aplicacions se n’encarreguen d’oferir les funcions d’un
agregador sense que l’usuari hagi d’instal·lar res.
Si s’hi afegeix el fet de s’hi pot accedir per mitjà de diferents dispositius (ordina-
dors, telèfons mòbils, etc.) tot plegat ha propiciat que aquests siguin els lectors
més populars.
Hi ha una gran quantitat d’aplicacions web disponibles a Internet i sovint n’apa-

reixen de noves. Alguns exemples són:
• Feedly
• Netvibes
• BlogLines
• FeedLooks
1.5.2 Programari d’escriptori
Són programes tradicionals que requereixen ser instal·lats en el sistema de l’u-

suari. Solen tenir interfícies gràfiques semblants a les dels programes de correu
electrònic.
N’hi ha una gran quantitat i amb les eines de programació actuals no és gaire difícil
programar-ne un. Alguns exemples són:
• Liferea
• SharpReader
• FeedDemon
• FeedReader
1.6 Problemes
No tot són avantatges amb la sindicació de continguts, ja que alguns usuaris s’han
queixat que el fet que sigui més fàcil i ràpid obtenir la informació no sempre fa
que es perdi menys temps per revisar la informació, ja que aquesta facilitat fa
que els usuaris acabin seguint més llocs i, per tant, acabin perdent el mateix temps
que abans, fins i tot més.
D’altra banda, malgrat que la sindicació de continguts s’ha fet molt popular, encara
hi ha molts usuaris que no entenen per a què serveix i no la fan servir.
També alguns usuaris creadors dels continguts han expressat les seves reserves a
la sindicació, ja que sovint els resta ingressos per publicitat: el fet que els usuaris
no hagin de visitar els seus llocs web els resta visites i, per tant, acaben tenint
menys ingressos.
De totes maneres, des d’un punt de vista tècnic i d’utilitat és una tecnologia
que cal tenir en compte, atès que els avantatges són molt superiors als possibles
inconvenients.
2. Conversió i adaptació de documents XML
A pesar que l’XML és un format relativament llegible en ser visualitzat, aquest no

és un dels seus objectius principals, i menys si es té en compte que als humans els
agrada llegir les dades col·locades en determinats formats que els facin la lectura
més agradable –mentre que l’especificació XML exposa que en cap cas no s’ha
d’incloure informació sobre la visualització en els documents.
En determinats casos pot caldre transformar els documents XML perquè siguin
més fàcils de visualitzar, o també adaptar-los perquè puguin ser llegits per
programes específics.
XML està pensat sobretot per a emmagatzemar i intercanviar informació, de

manera que si cal representar les dades d’una manera diferent per optimitzar un
procés o per millorar-ne la visualització hi haurà diverses possibilitats:
1. Desenvolupar un programa: com que és relativament senzill treballar

amb XML, es podria desenvolupar un programa que agafi les dades XML i
generi la sortida tal com la volem. Això té l’inconvenient que caldrà tenir
coneixements de programació i que pot representar molta feina encara que
el que calgui fer sigui trivial.
2. Fer servir CSS: en molts casos una solució senzilla seria fer servir CSS per
representar la informació de manera més amigable fent servir un navegador.
Però només serveix per canviar la visualització, no per canviar el document.
3. Transformar el document: una solució alternativa consisteix a transformar

el document en un altre que estigui pensat per ser visualitzat. Hi ha
molt formats que estan pensats sobretot per ser visualitzats: PDF, HTML,
XHTML, etc.
2.1 Ús de CSS
En molts casos si l’objectiu és que el document sigui visualitzat d’una manera més
agradable la solució més senzilla pot ser visualitzar-lo mitjançant CSS.
CSS és interessant sobretot quan es vulguin fer adaptacions senzilles. Si es té un

document XML com aquest:

2 <professor>
3 <nom>Marcel</nom>
5 <departament>Departament d’Informàtica</departament>
6 <carrecs>
7 <carrec>Cap de Departament</carrec>
8 <carrec>Tutor</carrec>
9 </carrecs>
10 </professor>
...i es vol representar com una targeta de vista, es pot fer servir un document CSS
que contingui aquestes línies:
1 professor {
2 padding: 30px;
3 margin: 30px;
4 border: 4px black solid;
5 width: 40%;
6 }
7
8 nom,cognom {
9 font−size:30px;
10 }
11
12 departament {
13 padding−top:20px;
14 display:block;
15 font−weight:bold;
16 }
17
18 carrec{
19 font−style: italic;
20 padding−left:10px;
21 }
22
23 carrec:after { content:","; }
Així, es representarà el document XML com en la figura 2.1.
F i g ura 2 . 1 . Resultat de la transformació
Malgrat això, CSS té moltes limitacions a l’hora de presentar la informació:
1. La informació no pot ser reordenada con vulguem. L’única manera de

simular el canvi d’ordre és fer servir posicionaments absoluts.
2. Els atributs es poden mostrar però hi ha moltes limitacions per fer-ho.
3. No es poden afegir estructures noves producte de càlculs o de procés de les

dades del document.
4. No té maneres senzilles de formatar les dades en pàgines de text per ser

impreses.
Si l’objectiu final no és simplement decorar el fitxer sinó transformar-lo en un altre

document totalment diferent, CSS no serveix. CSS no transforma el document
sinó que simplement canvia la manera com es visualitza.
2.2 Transformació de documents
Per intentar aconseguir fer tot allò que CSS no podia fer es va crear un nou
llenguatge de plantilles: XSL (extensible stylesheet language).
Inicialment es van concentrar a poder representar la informació de manera que

pogués ser mostrada en documents impresos i en pantalla però després es va acabar
definint un sistema per fer transformacions genèriques de documents XML en
altres coses: documents de text, documents XML, pàgines web, etc.
Actualment XSL és una família de llenguatges que serveixen per definir

transformacions i presentacions de documents XML.
La família XSL està formada per tres llenguatges:
• XSL-FO (XSL formatting objects): un llenguatge per definir el format que

s’ha d’aplicar a un document.
• XSLT (XSL transformations): un llenguatge per transformar documents

XML.
• XPath: un llenguatge per accedir a parts dels documents XML.
2.2.1 XSL-FO
XSL-FO és un llenguatge basat en XML que està pensat per donar format als
documents XML, però a diferència d’altres llenguatges amb objectius similars,
com CSS o XHTML, està pensat per generar sortides tant per a formats de pantalla
com per a formats paginats.
XSL-FO és un llenguatge que:
• Permet especificar amb molta precisió el contingut d’un document (pagina-

ció, organització, estil, etc.).
• Permet crear documents d’alta qualitat.
• És ideal per generar documents amb dades que canvien sovint.
XSL-FO sobretot es fa servir per generar documents en formats pensats per ser
impresos com PDF o Postcript.
Generació de PDF
És corrent que la generació del document es faci en dues fases (figura 2.2): Un dels processadors d’XSL-FO
més populars és l’Apache FOP,
que permet crear documents en
1. Transformació del document XML en un document XSL-FO amb el llen- PDF a partir de documents
XSL-FO.
guatge de transformacions XSLT.
2. Transformació del document XSL-FO en el format que volem amb un

processador XSL-FO.
Fig u ra 2 . 2 . Transformació d’un document XML en PDF i HTML
Per tant, els processadors XSL-FO s’encarreguen de generar el format que volem
a partir de les dades especificades en els documents XSL-FO.
2.3 Processadors XPath o XSLT
En general els processadors XPath o XSLT es proporcionaran per mitjà de

biblioteques que podran ser cridades des dels programes.
Això permet simplificar tot el procés de creació de programes que facin servir
XPath o XSLT, ja que quan una aplicació es vulgui aprofitar de les característi-
ques d’algun d’aquests llenguatges no ho haurà d’implementar tot de nou sinó
simplement fer servir les biblioteques.
2.3.1 Biblioteques
En alguns casos les biblioteques tindran suport tant per a XSLT com per a XPath,
i en d’altres casos s’haurà de recórrer a dues biblioteques diferents. Per exemple,
en el cas del suport XML del projecte Gnome, per poder tenir suport XPath i
XSLT hem de recórrer a dues biblioteques diferents:
• libxml2: ofereix suport per processar XML i XPath.
• libxslt: agafa de base libxml2 per permetre fer transformacions XSLT.
Mentre que amb Saxon el suport XPath i XSLT està en la mateixa biblioteca.
Les biblioteques més usades són:
• libxml2 i libxslt
• Apache Xalan
• Saxon
• MSXML
A l’hora de triar una biblioteca o una altra cal tenir clar si necessitem el suport per
a les versions 2.0 d’aquests llenguatges, ja que no hi sol haver gaire problemes per
fer transformacions amb les versions 1.0, i tots els processadors les solen suportar;
no sempre passa el mateix amb les versions 2.0.
libxml2 i libxslt
Del projecte GNOME han sortit les biblioteques libxml2 i libxslt, que són
biblioteques que permeten tenir suport per a XML, XPath i transformacions XSLT.
La utilitat xmllint de libxml2 permet executar expressions XPath de dues maneres.

De manera interactiva amb el paràmetre –shell. Amb aquest paràmetre entrem
en un entorn d’ordres que ens permet executar ordres contra el fitxer.
Una de les ordres possibles dins d’aquest entorn és xpath, que ens donarà
informació sobre com seran els resultats.
1 $ xmllint −−shell persones.xml

2 / > xpath //nom
3 Object is a Node Set :
4 Set contains 4 nodes:
5 1 ELEMENT nom
6 2 ELEMENT nom
7 3 ELEMENT nom
8 4 ELEMENT nom
Per veure els resultats d’una manera més amigable és més útil fer servir cat.
1 $ xmllint −−shell persones.xml

2 / > cat //nom
3 −−−−−−−
5 −−−−−−−
7 −−−−−−−
8 <nom>Filomeno Garcia</nom>
9 −−−−−−−
L’altra possibilitat consisteix a especificar l’expressió XPath en la línia d’ordres

fent servir el paràmetre –xpath:
1 $ xmllint −−xpath //nom persones.xml

La biblioteca libxslt porta una utilitat des de l’entorn d’ordres que permet fer
transformacions XSLT, que s’anomena xsltproc.
Amb xsltproc es pot transformar un fitxer en un altre passant-li com a paràmetres

el fitxer per transformar i la plantilla.
1 $ xsltproc fitxer.xml fitxer.xsl −o sortida
Es poden trobar versions d’xsltproc compilades per a Windows i que funcionaran

de la mateixa manera.
Apache Xalan
Apache Xalan és un intent de fer unes biblioteques de C++ i de Java de qualitat
comercial, lliures i multiplataforma.
En els exemples que vénen amb la biblioteca es pot trobar un programa d’exemple
amb el qual es poden fer transformacions XPath anomenat XPathResolver.
En el mateix paquet es pot trobar una utilitat d’entorn d’ordres que permet fer
transformació de documents.
1 $ xalan −in fitxer.xml −xsl fitxer.xsl −out sortida
Saxon
Saxon és el processador més complet de tots, ja que està desenvolupat per un dels
especificadors d’XSLT, i per tant segueix fidelment l’estàndard.
Hi ha dues versions de Saxon, una per a Java i una per a .NET. Té una versió de
les biblioteques de codi obert, Saxon-HE (Home Edition), i dues de comercials,
Saxon-PE (Professional Edition) i Saxon-EE (Enterprise Edition).
Amb la biblioteca es poden trobar exemples d’ús que es poden fer servir per fer
proves i transformacions.
En sistemes basats en Debian, com l’Ubuntu, després d’instal·lar el paquet

libsaxonb-java es pot executar una consulta XPath passant l’expressió amb echo
a saxonb-xquery.
1 $ echo //nom | saxonb−xquery −s persones.xml −
Es poden fer transformacións XSLT amb l’ordre saxonb-xslt passant-hi el fitxer

XML i el fitxer de plantilles XSLT
1 $ saxonb−xslt −o sortida persones.xml persones.xsl
Microsoft XML Parser

Es tracta del més usat en el món de la programació en .NET. Es pot descarregar
des del web de Microsoft.
L’execució des de consola no difereix gaire de les dels altres processadors. Per
exemple, per fer transformacions podem fer:
1 c:\> msxml fitxer.xml fitxer.xsl −o sortida
2.4 XPath
XPath (XML path language) és una manera d’especificar parts d’un

document XML que té eines per manipular el contingut de les dades de text,
numèriques, etc.
XPath és una recomanació del W3C (www.w3.org/TR/xpath), que tot i que serveix
per treballar amb XML no és un llenguatge XML. La idea és que en no estar basat
en XML es podrà incloure en altres llenguatges XML sense haver de preocupar-se
de si el resultat està ben format o no.
La base del funcionament d’XPath és l’avaluació d’expressions. Una expressió

que s’avaluarà contra un document XML i ens donarà un resultat que pot ser de
diferents tipus:
1. Un boleà: cert o fals
2. Un nombre
3. Una cadena de caràcters
4. Un grup d’elements
XPath està desenvolupat pels comitès de creació d’XSL i XQuery i s’ha convertit
en un component essencial per a diferents llenguatges XML com XLinks, XSLT
i XQuery, com es pot veure en la figura 2.3.
Fig ur a 2. 3. Relació d’XPath amb diferents llenguatges

XML
La versió 2.0 d’XPath està tan integrada dins d’XQuery que qualsevol expressió
XPath és també automàticament una expressió XQuery correcta.
2.4.1 Vista d’arbre
XPath tracta tots els documents XML des del punt de vista d’un arbre de nodes en
què hi ha una arrel que no es correspon amb l’arrel del document, sinó que és el
document i es representa amb el símbol “/”.
A part de l’arrel també hi ha nodes per representar els elements, els atributs, els
nodes de dades, els comentaris, les instruccions de procés i els espais de noms.
L’exemple següent XML:
1 <?xml version””=1.0 ?>

2 <classe>
3 <assignatura>Llenguatges de marques</assignatura>
4 <professor Especialitat="507">
5 <nom>Marcel</nom>
6 <cognoms>Puig</cognoms>
7 </professor>
8 <alumnes>
9 <alumne>
11 <cognoms>Pi</cognoms>
12 </alumne>
13 <alumne>
15 <cognoms>Garcia</cognoms>
16 </alumne>
17 </alumnes>
18 </classe>
Es representarà en XPath amb un arbre com el de la figura 2.4.
Fig u ra 2 . 4 . Arbre XPath
En un arbre XPath els atributs no són considerats nodes fills sinó que són
“propietats” del node que els conté i els nodes de dades són nodes sense nom
que només contenen les dades.
2.4.2 Programari per avaluar XPath
Molts programes permeten executar una consulta XPath contra un document

XML. Hi ha programes específics, editors XML, components dels navegadors web,
pàgines web online, etc.
És impossible mostrar tots els programes que permeten treballar amb XPath i, per
tant, només se’n mostraran alguns exemples.
"xpath"
La instal·lació per defecte d’Ubuntu instal·la automàticament una ordre basada en

Perl anomenada xpath que permet comprovar les ordres XPath des de la consola.
L’expressió es posa rere el paràmetre -e.
1 $ xpath −q −e //nom persones.xml
XPath Checker
Una utilitat molt interessant és un component del Firefox anomenat XPath

Checker, que permet fer consultes XPath interactivament, tant en pàgines HTML
com en documents XML que s’hagin visualitzat en el navegador.
Un cop instal·lat el component i carregat el document per avaluar amb el botó dret
del ratolí, es tria l’opció “View XPath” (figura 2.5).
Fi g ura 2 .5. Engegar XPath Checker
S’obrirà una finestra nova on es poden anar executant expressions XPath i també
es mostra el resultat de la consulta en la part inferior de manera interactiva (figura
2.6).
Fig u ra 2 . 6 . Els resultats van canviant en funció de l’expressió que s’especifiqui
Editors XML
L’opció més professional és fer servir algun dels editors especialitzats en XML.
Aquests editors permeten avaluar expressions XPath des d’un entorn gràfic amb
tot tipus d’assistències en la creació de les expressions, possibilitats de depuració,
etc. En la imatge següent es pot veure un exemple de l’assistent de l’oXygen XML
Editor (figura 2.7).
Fig u ra 2 . 7 . Assistent de creació d’expressions XPath
2.4.3 Navegació
Expressar camins en XPath
s’assembla tant a com ho
fan els sistemes operatius
que fins i tot es fan servir Com que la representació interna del document XML per XPath serà un arbre,
símbols semblants. s’hi pot navegar especificant-hi camins d’una manera semblant a com es fa en els
directoris dels sistemes operatius.
El més important per tenir en compte a l’hora de crear una expressió XPath és
saber el node en el qual està situat el procés (node de context), ja que és des
d’aquest que s’avaluarà l’expressió. El node de context al principi és en l’arrel
però es va movent a mesura que es van avaluant les expressions, i per tant podem
expressar els camins XPath de dues maneres:
• Camins absoluts
• Camins relatius
Els camins absoluts són camins que sempre comencen en l’arrel de l’arbre. Es
poden identificar perquè el primer caràcter de l’expressió sempre serà l’arrel ”/”.
No importa quin sigui el node de context si es fan servir camins absoluts, perquè
el resultat sempre serà el mateix.
En canvi, els camins relatius parteixen des del node en el qual estem situats.
Per exemple, es pot obtenir el node <nom> del professor de l’exemple que hem
especificat anteriorment fent servir l’expressió XPath següent:
1 /classe/professor/nom
Podem veure com s’avalua l’expressió en l’arbre XPath en la figura 2.8.
Fi g ura 2 .8. Avaluació de l’expressió /classe/professor/nom
Cal tenir en compte que el resultat d’aquesta expressió no és només el contingut

de l’element sinó tot l’element <nom>.
1 <nom>Marcel</nom>
Mai no s’ha d’oblidar que l’expressió sempre intenta aconseguir el nombre màxim
de camins correctes i, per tant, no necessàriament ha de retornar només un sol
valor. Per exemple, si l’expressió per avaluar fos la següent:
1 /classe/alumnes/alumne/nom
XPath l’avaluaria intentant aconseguir tots els camins que quadrin amb l’expressió,
tal com podeu veure visualment en la figura 2.9.
Fig u ra 2 . 9 . Avaluació de l’expressió /classe/alumnes/alumne/nom
El resultat seran els dos resultats possibles:
A pesar que en els exemples anteriors sempre s’han retornat nodes finals això no
necessàriament ha de ser així, ja que XPath pot retornar qualsevol tipus d’element
com a resultat.
1 /classe/alumnes
La navegació per l’arbre no difereix gaire dels altres casos (figura 2.10):
Fig u ra 2 . 1 0 . Avaluació de l’expressió /classe/alumnes
En aquest cas el resultat no és un element simple sinó que és tot un subarbre

d’elements.
1 <alumnes>
2 <alumne>
5 </alumne>
6 <alumne>
9 </alumne>
10 </alumnes>
Si se sap que una expressió retornarà diversos resultats però només se’n vol un
d’específic es pot fer servir un nombre envoltat per claudàtors quadrats ”[]” per
indicar quin és el que es vol aconseguir. Per retornar només el primer alumne
podeu fer el següent:
1 /classe/alumnes/alumne[1]
Dels dos nodes disponibles com a fills de <alumnes>, només se seleccionarà el

primer (figura 2.11).
Fi g ura 2 .11 . Avaluació de l’expressió /classe/alumnes/alumne/nom
O sigui:
1 <alumne>
4 </alumne>
Es poden fer servir els claudàtors en qualsevol lloc de l’expressió per fer determi-
nar quina de les branques es triarà. Per exemple, es pot obtenir només el nom del
segon alumne amb una expressió com aquesta:
1 /classe/alumnes/alumne[2]/nom
Sempre s’ha d’anar en compte en escriure les expressions XPath, ja que si el camí
especificat no es correspon amb un camí real dins de l’arbre no es retornarà cap
resultat.
1 /classe/nom
Com que en arribar al node classe no n’hi trobarà cap d’anomenat <nom>, no
retornarà cap resultat, com podeu veure si seguiu l’arbre (figura 2.12).
Fig u ra 2 . 1 2 . Avaluació de l’expressió /classe/alumnes
Obtenir els atributs d’un element
Els valors dels atributs es poden aconseguir especificant el símbol @ davant del
nom un cop s’hagi arribat a l’element que el conté (figura 2.13).
1 /classe/professor/@especialitat
Fig u ra 2 . 1 3 . Avaluació de l’expressió /classe/professor/@especialitat
S’ha de tenir en compte que a diferència del que passa amb els elements, en obtenir
un atribut no tindrem un element sinó només el seu valor:
1 507
Obtenir el contingut d’un element
Per a aquells casos en què només vulguem el contingut de l’element, s’ha definit la
funció text() per obtenir aquest contingut. Això s’ha fet així perquè d’altra manera,
com que els nodes de text no tenen nom, no s’hi podria accedir.
De manera que si a un element que tingui contingut de dades se li afegeix text():
1 /classe/professor/nom/text()
...retornarà el contingut del node sense les etiquetes:
1 Marcel
Comodins
De la mateixa manera que en els sistemes operatius, es poden fer servir comodins
diversos en les expressions XPath. Es poden veure els comodins en la taula 2.1.
Taul a 2. 1. Comodins en XPath

Comodí Significat
* L’asterisc es fa servir per indicar tots els elements

d’un determinat nivell.
.
Com en els directoris dels sistemes operatius el punt
serveix per indicar el node actual.
..
Es fa servir per indicar el pare del node en el qual
estem.
// Les dobles barres indiquen que quadrarà amb

qualsevol cosa des del node en el qual estem. Pot
ser un sol element o un arbre de nodes.
Amb l’asterisc es poden obtenir tots els elements d’un determinat nivell. Amb
aquesta expressió es poden obtenir tots els elements de dins del node professor.
1 /classe/professor/*
Aquesta expressió retornarà per separat els dos nodes fills de <professor> (<nom>
i <cognom>).
1 <nom>Marcel</nom>
O bé fer servir les dobles barres (//) per obtenir tots els elements <nom> del fitxer
independentment del lloc on siguin dins del document XML.
1 //nom
El resultat serà:
1 <nom>Marcel</nom>
Es poden posar les dobles barres en qualsevol lloc dins de l’expressió per indicar
que hi pot haver qualsevol cosa enmig a partir del lloc on apareguin.
1 /classe/alumnes//nom
Donarà els dos noms dels alumnes:
Tot i que facilita la creació d’expressions no és gaire recomanable abusar del

comodí // per motius d’eficiència. Les expressions amb aquest comodí requeriran
molts més càlculs per ser avaluades, i per tant les expressions trigaràn més a donar
resultats.
Eixos XPath
Per avaluar les expressions XPath s’explora un arbre, de manera que també es
proporcionen una sèrie d’elements per fer referència a parts de l’arbre. Aquests
elements s’anomenen eixos XPath (taula 2.2).
Taul a 2. 2. Eixos XPath

Eix Significat
self:: El node en el qual està el procés (fa el mateix que el

punt)
child:: Fill de l’element actual
parent:: El pare de l’element actual (idèntic a fer servir ..)
attribute:: Es fa servir per obtenir un atribut de l’element actual

(@)
Alguns d’aquests eixos pràcticament no es fan servir perquè generalment és més

còmode i curt definir les expressions a partir del símbol. Tothom prefereix fer
servir una expressió com aquesta:
1 /classe/professor/nom
Que no pas la seva versió equivalent fent servir els eixos:
1 /child::classe/child::professor/child::nom
A part dels vistos en la taula 2.2 n’hi ha d’altres, que en aquest cas no tenen cap
símbol que els simplifiqui (taula 2.3).
Taul a 2. 3. Eixos XPath
Eix Significat
descendant:: Tots els descendents del node actual
desdendant-or-self:: El node actual i els seus descendents
ancestor:: Els ascendents del node

Eix Significat
ancestor-or-self:: El node actual i els seus ascendents
prededint:: Tots els elements precedents al node actual
preceding-sibling:: Tots els germans precedents
following:: Elements que segueixen el node actual
following-sibling:: Germans posteriors al node actual
namespace:: Conté l’espai de noms del node actual
Condicions
Un apartat interessant de les expressions XPath és poder afegir condicions per a

la selecció de nodes. A qualsevol expressió XPath se li poden afegir condicions
per obtenir només els nodes que compleixin la condició especificada.
La selecció de nodes es fa especificant un predicat XPath dins de claudàtors.
Per exemple, aquesta expressió selecciona només els professors que tinguin un
element <nom> com a fill de <professor>:
1 /classe/professor[nom]
Si s’aplica l’expressió a l’exemple que hem fet servir per fer la vista d’arbre, el
resultat serà el node <professor> que té dins seu <nom>.
1 <professor especialitat="507">
2 <nom>Marcel</nom>
4 </professor>
En el valor de l’expressió s’hi especifiquen camins relatius des del node que tingui
la condició. Fent servir condicions es pot fer una expressió que només retorni el
professor si té alumnes.
1 /classe/professor[../alumnes/alumne]
Normalment la complexitat de les condicions va més enllà de comprovar si el

node existeix, i es fan servir per comprovar si un node té un valor determinat. Per
exemple, per obtenir els professors que es diguin “Marcel”:
1 /classe/professor[nom="Marcel"]
Les condicions es poden posar en qualsevol lloc del camí i n’hi pot haver tantes
com calgui. Per obtenir el cognom del professor que es diu “Marcel” es pot fer
servir una expressió com aquesta.
1 /classe/professor[nom="Marcel"]/cognoms
Que donarà de resultat:
De la mateixa manera que per obtenir-ne els valors, es poden fer comparacions
amb els valors dels atributs especificant el seu nom rere el símbol @. Per saber si
un element té l’atribut ‘especialitat’:
1 /classe/professor[@especialitat]
Retornarà:
1 <professor especialitat="507">
2 <nom>Marcel</nom>
4 </professor>
De la mateixa manera que amb els elements, es poden posar condicions als atributs
per saber si el seu valor té un determinat valor, etc.
1 /classe/professor[@especialitat="507"]
1 /classe/professor[@especialitat>=507]
Es poden mesclar les expressions amb condicions sobre atributs i sobre elements
per aconseguir expressions més complexes especificant-les una al costat de l’altra.
Per exemple, podem obtenir el professor que té l’atribut especialitat a “507” i que
es diu “Marcel” amb l’expressió:
1 /classe/professor[@especialitat="507"][nom="Marcel"]
La funció not() es fa servir per negar les condicions:
1 /classe/professor[not(@especialitat)]
L’expressió pot ser tan complexa com calgui. Per exemple es pot obtenir la llista
dels cognoms dels alumnes del professor de tipus “507” que es diu “Marcel”:
1 /classe/professor[@Especialitat="507"][nom="Marcel"]/../alumnes/alumne/cognoms
Que retornarà els dos cognoms:
1 <cognoms>Pi</cognoms>
2 <cognoms>Garcia</cognoms>
2.4.4 Seqüències
Una seqüència és una expressió XPath que retorna més d’un element. S’assemblen
bastant a les llistes d’altres llenguatges:
• Tenen ordre
• Permeten duplicats
• Poden contenir valors de tipus diferent en cada terme

La creació dinàmica de
seqüències funciona a partir
d’XPath 2.0.
És fàcil crear seqüències, ja que només cal tancar-les entre parèntesi i separar cada
un dels termes amb comes. L’expressió següent aplicada a qualsevol document:
1 (1,2,3,4)
Retorna la seqüència de nombres d’un en un:
1 1
2 2
3 3
4 4
També es poden crear seqüències a partir d’expressions XPath. En aquest cas

s’avaluarà primer la primera expressió, després la segona, etc.
1 (//nom/text(), //cognoms/text())
Aplicat al nostre exemple retornarà primer tots els noms i després tots els cognoms:
1 Marcel
2 Frederic
3 Filomeno
4 Puig
5 Pi
6 Garcia
Unió, intersecció i disjunció
També es pot operar amb les seqüències d’elements. Una manera seria fer servir
els operadors d’unió (union), intersecció (intersec) o disjunció (except).
Per exemple, l’expressió següent ens retornaria els cognoms dels alumnes que
coincideixin amb els d’un professor:
1 (//alumne/nom) intersect (//professor/nom)
Amb la unió es poden unir les llistes de manera que en quedi una de sola sense
duplicats:
1 (//alumne/nom) union (//professor/nom)
I amb la disjunció obtenim els noms de la primera seqüència que no surten en la

segona:
1 (//alumne/nom) except (//professor/nom)

2.4.5 Funcions
XPath ofereix una gran quantitat de funcions destinades a manipular els

resultats obtinguts.
Les funcions que ofereix XPath es classifiquen en diferents grups:
• Per manipular conjunts de nodes: es pot obtenir el nom dels nodes,

treballar amb les posicions, comptar-los, etc.
• Per treballar amb cadenes de caràcters: permeten extreure caràcters,

concatenar, comparar... les cadenes de caràcters.
• Per fer operacions numèriques: es poden convertir els resultats a valors

numèrics, comptar els nodes, fer-hi operacions, etc.
• Funcions boleanes: permeten fer operacions boleanes amb els nodes.
• Funcions per dates: permeten fer operacions diverses amb dates i hores.
És impossible especificar-les totes aquí, de manera que el millor és consultar

l’especificació XPath (http://www.w3.org/TR/xpath-functions) per veure quines
funcions es poden fer servir.
Entre totes les funcions podem destacar les que surten en la taula 2.4.
Taul a 2. 4. Funcions XPath destacades
Funció Ús
name() Retorna el nom del node
sum() Retorna la suma d’una seqüència de nodes o de

valors
count() Retorna el nombre de nodes que hi ha en una

seqüència
avg() Fa la mitjana dels valors de la seqüència
max() Retorna el valor màxim de la seqüència
min() Dóna el valor mínim de la seqüència
position() Diu en quina posició es troba el node actual
last() Retorna si el node actual és l’últim
distinct-values() Retorna els elements de la seqüència sense

duplicats
concat() Uneix dues cadenes de caràcters
starts-with() Retorna si la cadena comença amb els caràcters

marcats
contains() Ens diu si el resultat conté el valor
string-length() Retorna la llargada de la cadena
substring() Permet extreure una subcadena del resultat

Funció Ús
string-join() Uneix la seqüència amb el separador especificat
current-date() Ens retornarà l’hora actual
not() Inverteix el valors booleans
Amb les funcions es podran fer peticions que retornin valors numèrics. Per
exemple, “quants alumnes tenim?”:
1 count(/classe/alumnes/alumne)
Que tornarà el nombre d’alumnes del fitxer:
1 2
O bé retornar cadenes de caràcters. Per exemple, unir tots els noms separant-los
per una coma:
1 string−join(//nom,",")
Que retornarà en un únic resultat els noms separats per una coma:
1 Marcel,Frederic,Filomeno
També es poden posar les funcions en els predicats. Per exemple, aquesta
expressió ens retornarà els alumnes amb cognom que comenci per p.
1 /classe/alumnes/alumne[starts−with(cognoms,"P")]
En aquesta expressió volem obtenir el segon alumne de la llista:
1 /classe/alumnes/alumne[position()=2]
2.5 XSLT
XSLT (extensible stylesheet language for transformations) és un llenguatge

de plantilles basat en XML que permet convertir l’estructura dels elements
XML en altres documents.
Es tracta d’una recomanació del W3C (World Wide Web Consortium), com ho
és CSS, però XSLT va molt més enllà, ja que supera moltes de les limitacions de
CSS.
Amb XSLT es poden fer transformacions que canviïn totalment l’estructura del
document, pot reordenar la informació del document XML, afegir-hi informació
nova on sigui, prendre decisions en funció de la informació que s’hi trobi, fer
càlculs, etc.
XSLT es recolza en altres tecnologies XML per funcionar:
• Fa servir XPath per determinar les plantilles per aplicar en cada moment (i
per tant s’integra en XQuery).
• Suporta XML Schemas per definir els tipus de dades.
Tot i que hi ha la versió 2.0 d’XSLT, la que es fa servir més és la 1.0.
La versió 2.0 de XSLT afegeix tota una sèrie de característiques que encara fan
més potent XSLT:
• Suporta els tipus de dades d’XML Schemas
• Inclou elements nous que permeten agrupar resultats, etc.
• Pot generar múltiples sortides en una sola transformació
• Afegeix un grup de funcions noves a més de les d’XPath 2.0
• Pot processar fitxers que no siguin XML
Cada vegada es fan servir més les plantilles XSLT per generar vistes perso-
nalitzades d’un document XML per ser visualitzades en diferents destinacions
(impressora, pantalla d’ordinador, telèfon mòbil...). D’aquesta manera n’hi ha
prou només tenint el document XML original, i els altres es crearan sota demanda
(figura 2.14).
Fig u ra 2 . 1 4 . L’ús més corrent és transformar documents en funció de la destinació
Una de les limitacions d’XSLT és que el document d’entrada ha de ser sempre

XML, a pesar que la sortida no té aquesta limitació i pot acabar essent en qualsevol
format: text, HTML, XML, etc.
2.5.1 Programes
A pesar que les biblioteques XSLT tenen utilitats que es poden fer servir en
temps de creació per provar que la plantilla fa el que ha de fer, normalment les
transformacions es faran internament des de programes. És per aquest motiu que
la majoria de les implementacions XSLT estan en forma de biblioteques.
Uns dels programes d’ús corrent que tenen incorporades biblioteques XSLT són
els navegadors web (Firefox, Internet Explorer, Google Chrome, i d’altres). Si
es carrega un document XML que té associada una transformació XSLT en
un navegador web es transformarà automàticament i s’hi mostrarà el resultat
transformat.
Les plantilles XSLT són documents XML que es poden crear fent servir editors
de text o bé editors especialitzats en XML. En la creació de plantilles XSLT,
els avantatges que ofereixen els editors XML són tan importants (depuradors
d’expressions, ajudes...) que els fan una eina molt valuosa per treballar-hi
professionalment (figura 2.15).
Fi g ura 2 .15 . El depurador XSLT incorporat a l’oXygen XML Editor
2.5.2 El procés de transformació
Una transformació XSLT consisteix a passar un document XML i una plantilla

per un processador XSLT, el qual aplicarà les regles que trobi en la plantilla al
document per generar un document nou (figura 2.16). El fitxer de resultat de la
transformació pot ser tant un document XML com en qualsevol altre format.
Per associar un document XML a una plantilla XSLT específica es fa servir

l’etiqueta <?xml-stylesheet ?>.
Per exemple si volem associar la plantilla XSLT alumnes.xsl a un document cal

editar-lo i afegir-hi l’etiqueta <?xml-stylesheet ?> rere la declaració xml:
1 <?xml−stylesheet href="alumnes.xsl" type="text/xsl" ?>

Fig u ra 2 . 1 6 . Processar XSLT
L’arrel del document XSLT
Les plantilles XSLT són documents XML, i per tant, han de complir les regles
dels documents XML. Això vol dir que han de tenir un element arrel:
L’arrel de les plantilles XSLT és l’element <stylesheet>.
L’element arrel <stylesheet> ha de tenir obligatòriament dos atributs:
• L’atribut version, que especificarà quina és la versió d’XSLT que s’ha fet
servir per crear la plantilla i que es farà servir per fer la transformació.
• L’espai de noms de XSLT, que normalment s’associa amb l’àlies ‘xsl’.
Per exemple, per a la versió 2.0 d’XSLT la definició de l’arrel seria una cosa com
aquesta:

2 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
3 xmlns:xs="http://www.w3.org/2001/XMLSchema"
4 version="2.0">
5
6 </xsl:stylesheet>
Dins de l’arrel es definiran les plantilles que determinaran quina és la transforma-

ció que es vol fer en el document original.
Crear una plantilla
El procés de transformació es farà intentant aplicar alguna plantilla als nodes del
document original.
Qualsevol element que no es pugui processar amb una plantilla es

transformarà amb el funcionament per defecte:
• Si el node té contingut es retornarà el contingut del node
• Si el node no té contingut es retornarà sense escriure res
Per tant l’element bàsic per fer les transformacions són les plantilles. Les plantilles
es defineixen amb l’element <xsl:template>.
L’element de plantilla pot tenir diversos atributs però el més corrent és match.
L’atribut match serveix per determinar a quins nodes s’ha d’aplicar aquesta
plantilla per mitjà d’una expressió XPath.
En el contingut de l’element de plantilla s’especificarà quina és la transformació

que cal aplicar als elements. La transformació més senzilla consisteix a escriure
un text literal. Per exemple, en la plantilla següent s’està definint que en arribar
algun element <nom> es desi en el fitxer de destinació la lletra A:
1 <xsl:template match="nom">
2 A
3 </xsl:template>
Per tant si s’aplica la plantilla anterior a aquest document:

1 <persona>
3 </persona>
El processador anirà analitzant els nodes del document original i primer intentarà
buscar una plantilla per a l’element <persona>, i com que no en trobarà cap
recorrerà al comportament per defecte i escriurà una línia en blanc.
Després intentarà trobar una plantilla per a l’element <nom> que, segons la
plantilla, s’ha de transformar en una lletra A.
Com que no hi ha més nodes el resultat serà aquest:

1 _
2 A
Cal tenir en compte que un cop un element ha estat processat per una plantilla
se’n processa tot el seu contingut amb ell (i, per tant, també els elements que
pugui contenir). Si canviem la plantilla anterior per la següent:
1 <xsl:template match="persona">
2 Persona
3 </xsl:template>
4
6 A
7 </xsl:template>
En aplicar-la al mateix XML primer processarà l’element <persona> i el trans-

formarà en “Persona” en el document de sortida, però com que <persona> conté
tots els altres elements, la transformació s’acabarà.
1 Persona
Afegir elements
El fet de poder fer transformacions fent servir text literal fa que també es pugui
fer servir el mateix sistema per crear etiquetes noves. Si es modifica la plantilla
anterior per una com la següent:
2 <senyor>Manel</senyor>
3 </xsl:template>
El resultat serà que el transformarà en aquest:
1 <senyor>Manel</senyor>
S’ha d’anar amb compte quan s’especifiquen etiquetes literals, ja que no es poden
crear etiquetes que deixin la plantilla mal formada. La plantilla següent que
només obre l’etiqueta <senyor> no es pot fer servir, perquè deixa la plantilla mal
formada:
2 <senyor>Manel
3 </xsl:template>
Una manera alternativa de crear elements en una transformació és fer servir

<xs:element>. Entre els atributs que pot tenir, l’únic obligatori és name, que
defineix el nom que tindrà l’etiqueta.
Per exemple, amb la plantilla següent creem un element <senyor> que sempre
tindrà de contingut “Pere” per a cada element <nom> que es trobi en el document.
2 <xs:element name="senyor">Pere</xs:element>
3 </xsl:template>
O sigui, que la sortida de cada element <nom> serà:
1 <senyor>Pere</senyor>
Afegir atributs
Els atributs es poden definir dins d’un nou element amb <xsl:attribute> i de
la mateixa manera que amb els nous elements, l’únic atribut obligatori és name.
Una transformació que tingués això:
2 <xsl:attribute name="home">Si</xsl:attribute>
3 Marcel
4 </xsl:element>
Generaria el següent:
1 <persona home="Si">Marcel</persona>
Control de les sortides de text

En comptes de fer servir literals també es poden fer transformacions en text
fent servir l’element <xsl:text>. Aquest element és important quan es volen
controlar millor els espais i els salts de línia que hi haurà en les sortides.
Podem fer que surtin 5 espais darrere de la lletra A definint la plantilla de la manera
següent:
2 <xsl:text>A </xsl:text>
3 </xsl:template>
Si no ho féssim amb <xsl:text> els espais de darrere la A es perdrien.
Obtenir valors
Una tasca habitual a l’hora de fer una transformació sol ser obtenir els valors dels
elements del document d’origen per posar-los en l’element de destinació. Es poden
obtenir el valor dels elements d’origen fent servir <xsl:value-of>.
Aquest element avalua l’expressió XPath de l’atribut select i en genera una sortida
amb el seu contingut.
Per exemple, a partir de l’XML següent:
1 <xsl:template match="persona">
2 <xsl:value−of select="nom">
3 </xsl:template>
Afegirà el valor de l’element <nom> en el fitxer de sortida:
1 Pere Garcia
Però s’ha de tenir en compte que només avalua el primer element que compleixi
la condició, o sigui, que si el fitxer de mostra fos el següent:

2 <persona>
3 <nom tipus="Professor">Pere Garcia</nom>
5 <nom>Manel Puig</nom>
6 </persona>
...la sortida d’aplicar la mateixa plantilla només seria el primer dels noms i no tots
dos, perquè agafaria només el primer <nom> de <persona>:
1 Pere Garcia
Per tant és molt important triar bé quines són les expressions XPath de les plantilles
per evitar aquest comportament. En aquest cas la solució podria ser escollir <nom>
en comptes de <persona>:
2 <xsl:value−of select="."/>
3 </xsl:template>
Com a resultat de l’element <xsl:value-of> s’hi pot posar qualsevol expressió

XPath. Per tant, també es poden obtenir els valors dels atributs afegint ”@” davant
del nom.
2 <xsl:value−of select="."/> ( <xsl:value−of select="@tipus" /> )
3 </xsl:template>
Que generarà:
1 Pere Garcia ( Professor )

2 Frederic Pi ( )
3 Manel Puig ( )
I també es poden fer servir les funcions XPath. Per tant, es pot generar una sortida
amb el total de les persones del fitxer:
1 <xsl:template match="/">
2 Total: <xsl:value−of select="count(//nom)"/>
3 </xsl:template>
Que donarà de resultat:
1 Total: 3
Reenviar nodes a una altra plantilla
Un altre ús habitual de les plantilles és el de fer-les servir per cridar-ne d’altres

quan es volen processar alguns dels nodes obtinguts per la plantilla quan aquesta
n’obté diversos.
Les crides a plantilles es poden fer amb l’element <xsl:apply-templates>.

Amb aquest element es pot fer que el diferents resultats d’una expressió XPath
es vagin processant un a un, buscant una plantilla on aplicar-se.
Si partim d’aquest codi XML:
1 <classe>
5 </classe>
I el full de plantilles següent:

2 <xsl:apply−templates select="classe/nom"/>
3 </xsl:template>
4
7 </xsl:template>
Al executar-se l’apply-templates s’avalua l’expressió XPath que conté, classe/nom,

que retorna tres resultats:
1. <nom>Frederic Pi</nom>
2. <nom>Filomeno Garcia</nom>
3. <nom>Manel Puigdevall</nom>
Cada un d’aquests resultats individualment intentarà trobar una plantilla on aplicar-

se. De manera que es processarà tres vegades el segon <xsl:template>, ja que és
qui captura nom, i donarà com a resultat:
1 Frederic Pi
2 Filomeno Garcia
3 Manel Puigdevall
Una de les característiques interessants és que <apply-templates> també es pot

fer servir per reordenar el contingut. Per exemple, amb l’XML següent:
1 <classe>
2 <professors>
4 <nom>Maria Sabartés</nom>
5 </professors>
6 <alumnes>
10 </alumnes>
11 </classe>
Es poden obtenir tots els nodes amb una plantilla que capturi l’arrel i que primer
mostri els noms dels alumnes i després els dels professors, de la següent manera:
1 <xsl:template match="classe">
2 Alumnes
3 −−−−−−−−−−
4 <xsl:apply−templates select="alumnes/nom"/>
5 Professors
6 −−−−−−−−−−
7 <xsl:apply−templates select="professors/nom"/>
8 </xsl:template>
9
12 </xsl:template>
Que generarà:
1 Alumnes
2 −−−−−−−−−−
3 Frederic Pi
4 Filomeno Garcia
5 Manel Puigdevall
6
7 Professors
8 −−−−−−−−−−
9 Marcel Puig
10 Maria Sabartés
Es pot veure que un dels usos d’aquest element pot ser reordenar els resultats. En
l’exemple, els alumnes en el document original estaven darrere dels professors, i
en canvi en el que hem obtingut estan davant.
Processar els nodes per fer tasques diferents

A vegades pot interessar processar els mateixos nodes diverses vegades per obtenir
diferents resultats. Per poder fer això es poden definir les plantilles que tinguin
l’atribut mode.
Si es defineix una plantilla amb l’atribut mode per activar la plantilla no n’hi haurà
prou que quadri amb l’atribut match, sinó que també caldrà que s’hi passi l’atribut
mode.
1 <template match="nom" mode="resultat">

2 ...
3 </template>
Les plantilles amb l’atribut mode han de ser cridades específicament. Per exemple,
amb <apply-templates>:
1 <xsl:apply−templates select="nom" mode="resultat"/>
Això permet fer dues coses diferents amb l’element <alumnes> de l’exercici
anterior: comptar els alumnes i fer-ne una llista.
1 <xsl:template match="classe">
2 <xsl:apply−templates select="//alumnes" mode="resultat"/>
3 <xsl:apply−templates select="//alumnes"/>
4 </xsl:template>
5
6 <xsl:template match="alumnes">
7 <xsl:apply−templates select="nom" />
8 </xsl:template>
9
10 <xsl:template match="alumnes" mode="resultat">
11 Total: <xsl:value−of select="count(nom)"/>
12 </xsl:template>
13
16 </xsl:template>
El resultat serà:
1 Total: 3
2 Frederic Pi
3 Filomeno Garcia
4 Manel Puigdevall
Forçar el tipus de sortida
XSLT està pensat per generar sortides en text, XML, HTML i XHTML. Per defecte
considera que la sortida serà un altre document XML i, per tant, si es vol generar
un document XML no cal especificar res. Molts processadors
interpreten que la sortida
serà HTML si la primera
Podem forçar que la sortida sigui una altra amb <xsl:output>. Per exemple etiqueta que troben és
<html>.
podem fer que la sortida sigui interpretada com a text pla amb:
1 <xsl:output type="text">
Si l’atribut type no és “xml” no sortirà la capçalera XML en el resultat final.
Però a part de type hi ha altres atributs que permeten controlar de quina manera
es generaran els resultats. Per exemple, indent serveix per formatar les sortides,
encoding per definir la codificació que cal fer servir, etc.
Instruccions de control
XSLT proporciona una manera de processar els resultats molt semblant a com
ho fan els llenguatges de programació. Com molts llenguatges de programació,
incorpora instruccions per processar els resultats.
Expressions condicionals
<xsl:if> permet afegir els resultats al fitxer només si es compleix una determi-
nada condició.
Per exemple, davant d’un document com el següent:
1 <alumnes>
2 <alumne nota="5">Pere Garcia</nota>
3 <alumne nota="3">Manel Puigdevall</nota>
4 </alumnes>
Amb <xsl:if> es pot aconseguir posar algun text només en els alumnes que
tinguin una nota superior a 5.
1 <xsl:if test="@nota>=5">
2 (aprovat)
3 </xsl>
Hi ha altres funcions per expressar alternatives, com <xsl:choose>, que permet

explicitar múltiples alternatives.
1 <xsl:choose>
2 <xsl:when select="@nota=10"> (excel · lent) </xsl:when>
3 <xsl:when select="@nota>=5"> (aprovat) </xsl:when>
4 <xsl:otherwise> (suspès) </xsl:
5 otherwis
6 e>
7 </xsl:choose>
Iteracions
<xsl:for-each> serveix per processar una seqüència de nodes un per un per fer
alguna acció en cada un:
1 <xsl:for−each select="/classe/alumnes/nom">
3 </xsl:for−each>
Altres
Hi ha etiquetes que permeten fer tasques de transformació elaborades per poder

ajustar les transformacions als diferents requisits que es puguin donar:
• Ordenar: <xsl:sort>.
• Numerar una llista de resultats: <xsl:number>.
• Crear variables: <xsl:variable>.
• Passar paràmetres a les plantilles: <xsl:param>, <xsl:with-param>,

<xsl:call-template>.
• Copiar dades directament: <xsl:copy>, <xsl:copy-of>.
• Carregar XSL des d’altres arxius: <xsl:import> / <xsl:include>.
• Definir les nostres funcions: <xsl:function>.
En cas que calgui alguna tasca molt específica, és important tenir a mà l’especi-
ficació per comprovar si hi ha algun element que pugui simplificar el procés de
creació de la plantilla:
• XSLT 1.0: www.w3.org/TR/xslt
• XSLT 2.0: www.w3.org/TR/xslt20/
A més, com que XSLT està basat en XML també s’hi poden afegir extensions per
ampliar-ne les possibilitats a l’hora de fer transformacions. En aquest sentit són
bastant populars les extensions que afegeix el grup EXSTL o les del processador
Saxon.
2.5.3 Exemple
Per poder traspassar les dades d’un programa a un altre hem de convertir l’estruc-
tura d’un document XML en una altra de diferent.
En una editorial reben les comandes dels llibres en un format XML. El format en
què es reben les comandes és un XML agrupat per autors com aquest:
1 <peticio biblioteca="Fantastica SL">

2 <data>15−11−2011</data>
3 <autor>
4 <nom>Frédérik McCloud</nom>
5 <llibres>
6 <llibre>
7 <titol>Les empentes</titol>
9 </llibre>
10 </llibres>
11 </autor>
12 <autor>
13 <nom>Corsaro Levy</nom>
14 <llibres>
15 <llibre>
16 <titol>Marxant de la font del gat</titol>
18 </llibre>
19 <llibre>
20 <titol>Bèstia!</titol>
22 </llibre>
23 </llibres>
24 </autor>
25 </peticio>
Però com que l’editorial té els llibres organitzats per títols i no per autors, volen
que es converteixi en un format que els faci més còmode treballar-hi.
L’editorial vol que tingui una part en què s’identifiqui la data de la comanda i el
nom de la llibreria i després que hi hagi la llista de llibres. L’equivalent de l’arxiu
anterior seria aquest:
1 <comanda>
2 <llibreria data="15−11−2011">Fantastica SL</llibreria>
3 <llibre quantitat="2">
4 <nom>Les empentes</nom>
5 <autor>Frédérik McCloud</autor>
6 </llibre>
8 <nom>Marxant de la font del gat</nom>
9 <autor>Corsaro Levy</autor>
10 </llibre>
12 <nom>Bèstia!</nom>
13 <autor>Corsaro Levy</autor>
14 </llibre>
15 </comanda>
Resolució
Es crea un arxiu amb la capçalera XML i s’hi defineix l’arrel dels fitxers XSLT.

3 version="2.0">
4
5 </xsl:stylesheet>
Com que es vol tenir totalment controlada tota la sortida el més fàcil és capturar
tot el document amb una plantilla que capturi l’arrel.
2
3 </xsl:template>
Dins d’aquesta plantilla ja es pot definir la primera part de l’estructura del

document, l’arrel <comanda> i l’element <llibreria>. En ser definits de nou
no cal obtenir les dades del fitxer i es poden especificar com a literals.
2 <comanda>
3 <llibreria>
4
5 </llibreria>
6
7 </comanda>
8 </xsl:template>
Dins d’aquesta plantilla caldrà aconseguir la llista de tots els llibres i les dades de
la llibreria. Com que s’ha capturat l’arrel, les dades de l’etiqueta <llibreria>
són fàcils d’aconseguir amb XPath:
• El nom de la llibreria està a /peticio/@llibreria.
• La data de la petició a /peticio/data.
Com que la data ha d’estar en un atribut, la posem dins d’un element

<xsl:attribute> en el qual es defineix el nom dia:
2 <comanda>
3 <llibreria>
4 <xsl:attribute name="dia">
5 <xsl:value−of select="/peticio/data"/>
6 </xsl:attribute>
7 <xsl:value−of select="/peticio/@llibreria"/>
8 </llibreria>
9 </comanda>
10 </xsl:template>
Si provem el codi que hem fet veurem que ja genera la primera part del que es vol
obtenir. Apareix l’element llibreria i té els valors del document.
1 <comanda>
2 <llibreria data="15−11−2011">Fantastica SL</llibreria>
3 </comanda>
Només ens falta obtenir la llista de llibres. Com que es tracta d’una repetició de
dades ho podem fer de dues maneres, amb un for-each o cridant una plantilla
nova amb apply-templates que s’encarregui de fer cada llibre.
El més simple és fer-ho amb una plantilla a la qual anirem passant els nodes
<titol> del document, i a partir d’aquests nodes obtindrem les dades.
Per tant darrere del tancament de l’element <llibreria> es fa una crida a una
plantilla que capturarà tots els elements <titol> del document (en XPath ho
podem expressar com ”//titol”:
1 <xsl:apply−templates select="//titol"/>
Falta definir la plantilla que rebrà la llista d’elements <titol>. Com que tots els
títols estan dins d’una etiqueta <llibre> ja es pot definir:
1 <xsl:template match="titol">
2 <llibre>
3 </llibre>
4 </xsl:template>
Els valors que ens calen es poden aconseguir fàcilment:
• El títol és el valor del node en el qual estem. O sigui, en XPath seria .
• La quantitat de llibres demanats és el node germà del qual estem. Per

tant, reculem fins al pare amb .. i després entrem en el node quantitat.
L’expressió XPath és ../quantitat.
• El nom de l’autor es pot aconseguir amb una expressió una mica més llarga.
Cal recular tres nivells fins a arribar al node <autor>, com es pot veure en
la figura (figura 2.17). Per tant, l’expressió XPath serà ../../../nom.
Fig ur a 2 . 1 7. Per obtenir l’autor reculem tres nivells i

entrem a ”nom”
Només falta emplenar les dades dins de la nova plantilla: posar la quantitat com a
atribut i crear les noves etiquetes per a l’autor i el títol, que podem definir com a
literals.
2 <llibre>
3 <xsl:attribute name="quantitat">
4 <xsl:value−of select="../quantitat"/>
5 </xsl:attribute>
6
7 <nom><xsl:value−of select="."/></nom>
8 <autor><xsl:value−of select="../../../nom"/></autor>
9 </llibre>
10 </xsl:template>
La plantilla final quedarà d’aquesta manera:

3 version="2.0">
4 <xsl:output indent="yes"/>
6 <comanda>
7 <llibreria>
8 <xsl:attribute name="data">
9 <xsl:value−of select="peticio/data"/>
10 </xsl:attribute>
11 <xsl:value−of select="peticio/@llibreria"/>
12 </llibreria>
13 <xsl:apply−templates select="//titol"/>
14 </comanda>
15 </xsl:template>
16
18 <llibre>
19 <xsl:attribute name="quantitat">
20 <xsl:value−of select="../quantitat"/>
21 </xsl:attribute>
22 <nom><xsl:value−of select="."/></nom>
23 <autor><xsl:value−of select="../../../nom"/></autor>
24 </llibre>
25 </xsl:template>
26 </xsl:stylesheet>
3. Bases de dades natives XML. Llenguatge de consultes (XQuery)
Els fitxers en XML estan en un format de text estandarditzat que serveix per
representar, emmagatzemar i transportar informació estructurada. Per tant l’XML
es pot fer servir com a mètode d’emmagatzematge de dades neutre, ja que la
informació emmagatzemada en fitxers XML es pot moure d’una màquina a una
altra sense que hi hagi problemes. Això el fa un mètode ideal per emmagatzemar
dades històriques que ens assegura que es podran tornar a llegir en el futur sense
problemes.
Això ha fet que les organitzacions cada vegada tinguin una quantitat més gran de
documents XML, i que en conseqüència localitzar els documents en el moment
adequat sigui cada cop més complicat. Per tant cal alguna manera d’organitzar
les dades XML que permeti localitzar-les ràpidament.
Però no solament n’hi ha prou de localitzar els documents, ja que sovint el que es
busca estarà repartit en diferents documents. També cal alguna manera de poder
consultar i manipular les dades que contenen els fitxers XML. Aquest sistema
de consulta ha de ser capaç de fer cerques en els documents i modificar-ne dades
si cal, però sempre mantenint uns mínims d’eficiència.
Davant d’aquestes necessitats la solució se sol donar de dues maneres:
1. Com que majoritàriament les organitzacions ja tenen sistemes d’emmagatze-

matge organitzats de dades basats en dades relacionals una possible solució
podria ser convertir els fitxers XML a dades relacionals:
• L’emmagatzematge de dades serà totalment organitzat i centralitzat en

un punt on ja hi ha les altres dades de l’organització.
• El seu llenguatge de consulta, SQL, és molt conegut i es fa servir molt,
de manera que no caldrà que els usuaris aprenguin un nou llenguatge.
2. Una altra solució consisteix a crear un sistema d’emmagatzematge pen-

sat només per als fitxers XML. Són els sistemes coneguts com a bases de
dades natives XML. Aquests:
• Proporcionen un lloc per emmagatzemar ordenadament fitxers XML.

• Tenen el seu llenguatge de consulta propi: XQuery.
Tot i que en la teoria és fàcil fer aquesta distinció, en la pràctica molt sovint les
organitzacions fan servir sistemes d’emmagatzemament mixtos, en els quals desen
en dades relacionals aquelles dades que han de ser emmagatzemades o consultades,
i en XML aquelles dades que han de ser representades en entorns web o que s’han
d’intercanviar o transportar a altres sistemes.
L’objectiu d’aquest mòdul no és ser expert en bases de dades, per tant només
veurem alguns exemples de coses que es poden fer en base de dades per treballar
amb XML
3.1 Bases de dades relacionals
Gairebé totes les organitzacions tenen les seves dades organitzades amb algun
sistema relacional, ja que els sistemes gestors de bases de dades s’han convertit
en un element indispensable en el funcionament de les empreses. Es fan servir
per controlar moltes de les dades de funcionament de les empreses: facturació,
comptabilitat, estocs...
Per tant, davant de l’aparició d’un nou tipus de dades, un dels raonaments fàcils
seria: “si ja tenim un sistema d’organització de dades que funciona bé, per què
no podem posar aquestes dades en el mateix sistema?”. D’aquesta manera, les
dades que s’obtinguessin dels fitxers XML aconseguirien un sistema molt eficient
d’emmagatzematge i un mètode de manipulació d’informació que ha estat molt
provat durant molts anys i que coneix molta gent.
La inclusió dels fitxers XML en els sistemes gestors de bases de dades relacionals
es pot fer de dues maneres:
1. Convertir les dades dels fitxers XML en dades relacionals:
• Aquest sistema té l’avantatge que les dades, un cop dins del sistema
relacional, seran idèntiques a les ja existents.
• L’inconvenient més important és que si torna a fer falta el document
XML original pot ser molt difícil regenerar-lo, ja que sovint hi haurà
informació sobre l’estructura XML que no s’emmagatzemarà.
2. Emmagatzemar els documents XML sencers en les bases de dades:
• Es posaran els fitxers XML sencers en un camp d’una taula de la base

de dades, de manera que serà com les altres dades.
• Per poder-hi treballar bé caldrà que la base de dades ofereixi alguna
manera mitjanament eficient de poder fer cerques en el contingut dels
documents XML.
3.1.1 Convertir les dades XML en relacionals
Una solució que pot semblar senzilla però que en realitat no n’és tant consisteix a
agafar les dades dels fitxers XML i transformar-les en dades relacionals. Un cop
s’hagin incorporat les dades a la base de dades es podran eliminar els fitxers XML.
Com que en el document XML ja hi ha definida l’estructura de les dades, i sovint

els documents XML estaran associats a un vocabulari, tindrem que:
• Generar l’estructura de taules relacionals es pot fer analitzant l’estructura

del document XML.
• Es poden obtenir els camps de la definició del vocabulari o simplement

observant el contingut del document XML.
Vegeu XSLT en l’apartat
“Conversió i adaptació de
I a més hi ha sistemes que permeten transformar dades XML en altres tipus de documents XML”
d’aquesta unitat.
fitxers (per exemple, XSLT).
Convertir un document XML en dades relacionals
Si es parteix del document XML següent:
2 <alumnes>
3 <alumne>
6 </alumne>
7 <alumne>
10 </alumne>
11 </alumnes>
És relativament senzill veure que l’estructura del document consisteix en una llista
d’elements <alumne>. I que els <alumne> tindran dos camps de dades que són <nom> i
<cognom>.
Per tant, l’estructura relacional d’aquest fitxer serà simplement crear una taula ‘alumne’ que
tingui com a dades un nom i un cognom. Això és trivial amb l’ordre CREATE TABLE d’SQL:
1 CREATE TABLE alumne (nom VARCHAR(30), cognom VARCHAR(30))
Obtenir les dades per emplenar la taula tampoc no ha de ser un problema gaire gran.
Simplement cal fer INSERT de cada camp de dades:
1 INSERT INTO alumne VALUES("Frederic", "Pi");

2 INSERT INTO alumne VALUES("Filomeno", "Garcia");
Per no haver-ho de fer manualment el més fàcil seria crear una plantilla XSLT que faci la
transformació del fitxer XML en les regles SQL.
A pesar de l’aparent senzillesa d’aquest sistema, no sempre és senzill fer aquesta

conversió, ja que els sistemes relacionals i XML parteixen de conceptes bastant
diferents:
• El sistema relacional està basat en dades bidimensionals sense jerarquia ni

ordre, mentre que el sistema XML està basat en arbres jeràrquics en què
l’ordre és significant.
• En un document XML hi pot haver dades repetides, mentre que els sistemes
relacionals fugen de les repeticions.
• Les relacions i les estructures dins dels documents XML no sempre són
òbvies.
• Què passa si necessitem tenir el document XML de nou? Fer el procés

invers no sempre és trivial. Un dels conceptes difícils és determinar quines
dades eren atributs i quines elements.
Per tant, normalment aquest no és el sistema més aconsellable però és un sistema

vàlid que pot ser útil en casos concrets.
3.1.2 Sistemes relacionals amb extensions XML
Fins a l’aparició d’XML pràcticament tothom emmagatzemava les dades que s’ha-
vien de consultar o modificar ràpidament per mitjà d’algun sistema relacional. Els
sistemes gestors de bases de dades han estat durant anys els reis de l’administració
de dades en les organitzacions.
Però l’increment d’informació en XML que s’havia de poder consultar o que

es requeria per fer tasques que abans estaven reservades a les bases de dades
relacionals ha provocat que s’hagi hagut d’incloure algun tipus de suport XML
en els sistemes gestors de bases de dades.
Tots els grans sistemes de bases de dades importants com Oracle, IBM DB2 o
Microsoft SQL Server tenen algun tipus de suport per a XML, que normalment
es concreta en el següent:
• Permetre exportar les dades relacionals en algun format XML per transpor-
tar les dades.
• Tenir alguna manera de poder emmagatzemar documents XML com a

camps en taules relacionals.
• Permetre fer cerques i canvis en els documents XML emmagatzemats.

A pesar que SQL/XML
forma part de l’estàndard
SQL, no tots els gestors de • Generar XML a partir de les dades relacionals de la base de dades.
bases de dades el suporten.
Com que SQL (el llenguatge de consulta de dades relacional per excel·lència) no
tenia suport per a XML el 2003, es va modificar l’estàndard del llenguatge SQL
per afegir l’extensió SQL/XML.
SQL/XML
SQL/XML és una extensió de l’estàndard SQL que permet treballar amb el

llenguatge XML per mitjà d’instruccions SQL.
A pesar de participar en
l’elaboració de l’estàndard, Aquesta extensió va ser desenvolupada per un grup en el qual hi havia les
Microsoft va anunciar que
no tenia intenció grans empreses de bases de dades (Microsoft, Oracle, IBM, SyBase, DataDirect
d’incorporar SQL/XML en el
Microsoft SQL Server. En Tecnologies...) i ja està implementada en algun sistema de bases de dades.
comptes d’això, el Microsoft
SQL Server fa servir un
sistema propi anomenat SQL/XML defineix tota una sèrie de funcions per a publicació de fitxers XML
Microsoft SQLXML o
OPENXML per treballar a partir de dades relacionals, defineix un tipus de dades XML i una manera de
amb SQL i XML.
consultar i manipular les dades XML emmagatzemades.
SQL/XML a Oracle
Oracle és un dels sistemes gestors de bases de dades més importants del mercat
i, per tant, no podia no donar suport als documents XML. Per fer-ho defineix el
tipus de dades XMLType, que serveix per emmagatzemar XML com si es tractés
d’un tipus de dades més en les taules.
Per tant, fent servir XMLType es pot crear una taula amb un camp amb documents
XML i treballar-hi com si fossin dades relacionals normals.
1 CREATE TABLE alumnes(ID INT NOT NULL, document XMLTYPE);
En la figura 3.1 podem veure la descripció d’una taula SQL que conté XML en
Oracle.
Figur a 3. 1. Descripció de la taula amb un camp XMLType
XMLType permet emmagatzemar els documents XML amb la definició de l’es-

quema o sense.
1. Amb l’esquema XSD el sistema pot saber de quin tipus són les dades de cada
element XML, i per tant, internament pot organitzar les dades de manera que
sigui possible fer-hi cerques més eficients. A més, en conèixer el contingut
de les etiquetes es podran fer operacions amb aquestes de la mateixa manera
que es fa amb les altres dades
2. Si no es proporciona l’esquema els XML seran tractats com un camp de text

i les cerques seran menys eficients.
L’entrada de dades XML a una taula Oracle es pot fer amb la instrucció habitual
però especificant el camp XML amb el tipus XMLTYPE.
1 INSERT INTO alumnes VALUES (1,

2 XMLTYPE(’<persona><nom>Pere</nom></persona>’));
També es poden consultar els valors XML de la manera habitual (figura 3.2).
F igu r a 3. 2 . Consulta dels valors de la base de dades
Per fer cerques Oracle proporciona una sèrie de funcions que permeten que a un
camp XML se li puguin extreure dades fent servir XPath, comprovar l’existència
de determinats nodes, crear-hi nodes nous, etc...
Per exemple, es poden extreure tots els elements <nom> d’un camp XML d’una
taula fent servir una ordre com la següent (figura 3.3):
1 SELECT EXTRACT(document,’//nom/text()’) "noms"
2 FROM alumnes;
F igu r a 3. 3 . Consulta SQL amb XPath
També pot caldre generar documents XML a partir de les dades que hi ha
emmagatzemades en la base de dades. Oracle ho pot fer de diverses maneres:
• Per mitjà d’SQL/XML.
• Per mitjà del paquet DBMS_XMLGEN, que permet crear XML a partir de
consultes.
• Amb la funció SYS_XMLGEN, que crea un document XML per a cada

registre resultat d’una consulta.
• Fent servir la utilitat XSU, que és específica per desenvolupar en Java.
Per exemple, fent servir l’estàndard SQL/XML disposem d’una sèrie de funcions
per generar contingut XML, especificant-les en la consulta SQL (taula 3.1).
Taul a 3. 1. Algunes funcions SQL/XML
Funció Ús
XMLELEMENT Permet crear un element amb un nom determinat
XMLATTRIBUTES Es fa servir per crear atributs dins d’un element
XMLCONCAT Concatena múltiples etiquetes
XMLFOREST Crea elements XML a partir d’un grup de resultats
Amb aquestes funcions es pot generar XML a partir una taula SQL que contingui
els camps nom i cognom com la (figura 3.4).
Fig u ra 3 . 4 . Taula relacio-

nal ’Professors’
Amb la instrucció següent:
1 SELECT xmlelement(’alumne’, xmlforest(a.nom, a.cognom))

2 FROM alumnes;
La figura 3.5 mostra quin és el resultat d’executar-la en l’Oracle.
Figur a 3. 5. Generar XML a partir de dades relacionals
3.2 XQuery
Una de les necessitats més bàsiques a l’hora de poder fer cerques en les dades és
disposar d’un llenguatge per fer consultes que sigui prou potent per poder cobrir
les necessitats dels que l’han de fer servir. Per aquest motiu es va desenvolupar el
llenguatge XQuery.
XQuery és un llenguatge de consultes pensat per convertir-se en la manera

estàndard de recuperar dades de col·leccions de documents XML.
Es tracta d’un llenguatge funcional, de manera que en comptes de dir-li quines

són les passes per fer una tasca el que es fa és avaluar les expressions contra el
fitxer XML i generar un resultat. A diferència dels llenguatges de programació
habituals, en XQuery s’especifica què és el que es vol i no la manera com ho ha
Xquery 3.0
de fer per obtenir-ho.
Ja està en desenvolupament una
nova versió d’XQuery que Entre les característiques més interessants d’XQuery, aquest permet:
permetrà incrementar la potència
de les consultes tot afegint
clàusules noves com group by o
el control d’errors dinàmics. La • Seleccionar la informació segons criteris. Ordenar, agrupar, afegir dades.
podeu consultar a
www.w3.org/TR/xquery-30
• Filtrar la informació que es vulgui del flux de dades.
• Cercar informació en un document o en un grup de documents.
• Unir dades de múltiples documents.
• Transformar i reestructurar XML.
• No estar limitat a la cerca, ja que pot fer operacions numèriques i de

manipulació de caràcters.
• Pot treballar amb espais de noms i amb documents definits per mitjà de DTD
o XSD.
Una part important d’XQuery 1.0 és el llenguatge XPath 2.0, que és la part que li
permet fer les seleccions d’informació i la navegació pel document.
3.2.1 Processadors XQuery
L’avaluació d’expressions XQuery requerirà disposar d’algun processador

XQuery.
Els processadors XQuery agafen els documents XML d’entrada i els

apliquen una transformació per generar un resultat.
En la figura 3.6 es pot veure quin és el funcionament d’un processador XQuery.
Fig u ra 3 . 6 . Funcionament dels processadors XQuery

Normalment els processadors XQuery venen en forma de biblioteques que es

poden incorporar als programes. Molts sistemes de base de dades o programes
incorporen aquestes biblioteques per poder donar suport XQuery en els seus
productes.
Saxon
Probablement una de les biblioteques més usades i amb millor suport per a XQuery
és Saxon.
En la seva versió gratuïta (Saxon Home Edition) a part de les biblioteques

s’instal·len dos executables que serveixen per fer transformacions i per avaluar
expressions XQuery: Transform i Query.
Podem executar XQuery simplement executant l’executable amb el fitxer amb les
expressions:
1 C:\> Query consulta.xquery
Normalment la majoria de distribucions Linux tenen la versió lliure de Saxon en

el seu repositori d’aplicacions. Per exemple, per al sistema Ubuntu, es troba en la
biblioteca libsaxonb-java i la instrucció és saxonb-xquery.
1 $ saxonb−xquery consulta.xquery
Kernow
Fi g ura 3 .7. Avaluació amb el Kernow
El Kernow és un programa molt popular que fa servir Saxon i que permet fer
avaluacions XQuery des d’un entorn gràfic per mitjà del que anomena XQuery
Sandbox (figura 3.7). Es pot baixar des de http://kernowforsaxon.sourceforge.net/.
A part d’avaluar expressions XQuery aquest programa també ofereix altres possi-
bilitats de la biblioteca Saxon, com fer transformacions XSLT, etc.
XQilla
L’XQilla és un programa que corre sobre la biblioteca Xerces i que permet fer
avaluacions Xquery des de l’entorn d’instruccions.
1 $ xqilla consulta.xquery
Altova
Altova és l’empresa que desenvolupa un editor XML anomenat Altova XMLSpy,

que és bastant popular en entorns Windows. Entre les eines gratuïtes que ofereix
hi ha unes utilitats per processar XQuery i XSLT des de consola.
Es pot processar una petició XQuery amb:
1 C:\> altovaxml /xquery consulta.xquery
Editors XML
Molts dels editors XML estan enllaçats amb biblioteques per processar XQuery i
des de l’entorn mateix de l’editor permeten editar, provar i depurar les peticions
XQuery (figura 3.8).
F igu r a 3. 8 . Prova d’edicions XQuery en l’oXygen XML Editor
A més d’altres avantatges com els assistents d’ajuda, hi ha la possibilitat de fer

consultes connectant amb bases de dades XML locals o remotes, etc.
Bases de dades XML
Lògicament, com que les bases de dades natives fan servir XQuery com a base en
les seves consultes, resulten ideals per provar expressions XQuery.
És corrent que aquestes tinguin alguna consola o un entorn en el qual es podran

executar les ordres i veure’n el resultat.
3.2.2 Consultes XQuery
Generalment una consulta XQuery consistirà a aconseguir les dades amb les quals
es vol treballar, filtrar-les i retornar el resultat com a XML. L’expressió més simple
que es pot fer en XQuery és escriure un element buit:
1 <Hola />
En executar aquesta ordre el resultat serà el següent:

2 <Hola/>
Aquesta és una de les característiques importants d’XQuery: que escriu literalment

el text; mentre que si en el resultat s’hi defineixen etiquetes l’expressió només
serà correcta si el resultat final és ben format. Per exemple, executar el següent en
XQuery donarà un error, ja que el resultat final no és ben format:
1 <a>
Però a pesar de poder escriure text, el més corrent és recuperar algun tipus de
dades, avaluar-les i retornar el resultat amb un return. La instrucció return
s’encarrega de generar les sortides.
Una altra característica important és que fa servir variables. Per exemple la

següent és una expressió XQuery correcta que assigna el valor 5 a $a i després
en retorna el valor:
1 let $a:=5
2 return 5
El resultat d’executar-ho amb XQuery serà:

2 5
A diferència del que passa amb els literals, el return s’executa una vegada per
cada valor que rebi, de manera que si hi hagués una expressió que es fes més d’un
cop:
1 for $a in (1,2)
2 return <Hola/>
El return s’executaria més d’un cop:

2 <Hola/>
3 <Hola/>
3.2.3 Comentaris
Com en gairebé tots els llenguatges, en XQuery també es permeten els comentaris.
Com que XQuery no té sintaxi XML els comentaris no es fan de la mateixa manera
que en XML sinó que es defineix el seu sistema propi.
Els comentaris es defineixen posant-los entre el símbol ”(:” i el ”:)”.
1 (: Comentari :)
També es poden fer comentaris multilínia
1 (:
2 Això també
3 és un comentari
4 :)
Tot el que estigui dins d’un comentari serà ignorat pel processador.
3.2.4 Càrrega de documents
Una de les coses que caldrà per interrogar un fitxer o fitxers XML és establir
específicament a quins documents es vol fer la petició. La càrrega dels fitxers
la podem fer amb dues funcions que podem veure a la taula 3.2.
Taul a 3. 2. Funcions per carregar fitxers XML
Funció Ús
doc() Dir quin és el document que volem consultar.
collection() Especificar un grup de documents alhora.

Generalment serà un document amb enllaços a
d’altres o una adreça d’una base de dades XML.
Per tant, podem fer servir la funció doc() per carregar un document XML. Amb
aquesta instrucció XQuery tornarà tot el document alumnes.xml.
1 return doc("alumnes.xml")
XQuery conté completament XPath, de manera que es pot fer servir qualsevol
expressió XPath per filtrar resultats quan faci falta, i per tant es pot fer que en
en el mateix procés de càrrega s’hi apliqui un filtre. Per exemple una expressió
XQuery que retorna quins són els noms dels alumnes del fitxer alumnes.xml pot
ser la següent:
1 return doc("alumnes.xml")//nom
Els documents poden estar en qualsevol lloc al qual es pugui arribar. En aquest
cas, per exemple, l’expressió XQuery pot ser una URL:
1 return doc("http://ioc.xtec.cat/alumnes.xml")
3.2.5 Variables
XQuery és un llenguatge pensat per fer cerca en documents XML, però no

solament es pot fer servir per fer cerca, ja que té suport per fer operacions
aritmètiques i per treballar amb cadenes de caràcters.
En aquest exemple fem servir XQuery per fer una operació matemàtica senzilla:
1 let $x := 5
2 let $y := 4
3 return $x + $y
El resultat serà:
2 9
Una característica d’XQuery que el diferencia d’altres llenguatges de cerca és que

disposa de variables:
• Les variables en XQuery s’identifiquen perquè comencen sempre amb el

símbol $.
• Poden contenir qualsevol valor: literals numèrics o caràcters, seqüències de

nodes...
• La instrucció per assignar valors a una variable és let.
Un dels usos fonamentals de les variables és emmagatzemar elements per poder-

los fer servir posteriorment. En l’exemple següent s’emmagatzemen els elements
<nom> en la variable $alumnes i després en retorna la quantitat d’alumnes:
1 let $alumnes := doc("alumnes.xml")//alumnes/nom
2 return count($alumnes)
Es poden aplicar filtres XPath a les variables:

1 let $tot := doc("classe1.xml")
2 let $profe := $tot//professor
3 let $alum := $tot//alumne
Els valors de les variables els podrem comparar amb els operadors de comparació
habituals que podem veure a la taula 3.3.
Taul a 3. 3. Operadors de comparació
Operador Operador2 Ús
= eq Dos valors són iguals
!= ne Dos valors són diferents
> gt És més gran que l’altre
>= ge És més gran o igual
< lt Més petit
<= le Més petit o igual
Els operadors eq, ne, gt, ge, lt i le només es poden fer servir per comparar valors
individuals, i per tant només es podran fer servir si hi ha un esquema definit.
3.2.6 Expressions avaluables
XQuery està pensat per poder mesclar les consultes amb qualsevol altre tipus de
contingut. Si es mescla amb contingut, les expressions que s’hagin d’avaluar s’han
de col·locar entre claus ”{...}”.
Per exemple, podem mesclar HTML i XQuery per tal que el processador XQuery
generi una pàgina web amb les dades d’un document XML.
1 <html>
2 <head><title>Llista de classe</title></head>
3 <body>
4 <h1>
5 {
6 doc("classe1.xml")//assignatura
7 }
8 </h1>
9 </body>
10 </html>
En mesclar contingut, el processador XQuery només avaluarà les instruccions que

estiguin dins de les claus, i per tant deixarà les etiquetes HTML tal com estan.
Creació d’elements i atributs
Fent servir les expressions avaluables és fàcil crear nous elements.
1 <modul>
2 { doc("classes.xml")//modul/text()}
3 </modul>
També es poden crear atributs (s’ha d’anar en compte de no deixar-se les cometes
al voltant del valor que obtindran els atributs).
1 <modul nom="{doc("classes.xml")//modul/text()}"/>
Una manera alternativa i més potent de definir elements i atributs és fer servir
les paraules clau element i attribute. Aquestes instruccions permeten crear
elements i definir-ne el contingut especificant-lo dins de les claus.
1 element modul {
2 }
Crearia un element <modul> buit:
1 <modul />
Si volem crear nous elements o atributs dins d’un element definit d’aquesta manera
s’han d’especificar dins de les claus. Per exemple, el codi següent:
1 element modul {
2 attribute nom {"Llenguatges de marques"},
3 element alumnes { }
4 }
Generarà el següent:
1 <modul nom="Llenguatges de marques">

2 <alumnes />
3 </modul>
No hi ha cap limitació a l’hora d’imbricar els elements i atributs per generar

resultats tan complexos com calgui, i en qualsevol moment s’hi pot posar una
expressió XQuery.
1 element modul {
2 attribute nom { doc("classe.xml")//modul/text() }
3 }
3.2.7 Expressions FLWOR
Les expressions FLWOR són la part més potent d’XQuery. Estan formades per
cinc instruccions opcionals que permeten fer les consultes i alhora processar-les
per seleccionar els ítems que interessin d’una seqüència (taula 3.4).
Taul a 3. 4. Expressions FLWOR
Caràcter Comanda Ús
f for Permet passar d’un element a un

altre de la seqüència
l let Serveix per assignar valors a una

variable
w where Permet filtrar els resultats segons

condicions
Caràcter Comanda Ús
o order by Usat per ordenar els resultats

abans de mostrar-los
r return Retorna el resultat de tota

l’expressió
"for ... return"
La instrucció for es fa servir per avaluar individualment cada un dels resultats

d’una seqüència de nodes. En un for es defineixen dues coses:
• Una variable, que serà la que anirà agafant els resultats de la seqüència un
per un.
• La paraula clau in, en la qual es defineix quina és la seqüència d’elements

per processar.
La manera més senzilla d’expressió FLWOR és combinar el for amb el return

per retornar els valors obtinguts de manera seqüencial:
1 for $i in (’Hola’, ’Adéu’)
2 return $i
Generarà:
1 Hola Adéu
Les seqüències de valors poden ser de qualsevol tipus. Per exemple, poden ser
nombres:
1 for $i in (1,2,3)
2 return $i*$i
Que retorna:
1 1 4 9
O bé una seqüència de nodes. Per exemple amb l’expressió següent capturem una
seqüència de nodes <alumne> i els fem servir per obtenir-ne el cognom:
1 for $alumne in doc("classe.xml")//alumne
2 return <alumne> { $alumne/cognom } </alumne>
El resultat serà quelcom així:

2 <alumne>
4 </alumne>
5 <alumne>
7 </alumne>
S’hi pot veure que els valors del return s’han anat processant un per un i per
aquest motiu es repeteixen les etiquetes <alumne>.
Un aspecte important és que no cal que el for sigui la primera expressió de la

consulta. També es pot posar com a paràmetre en una funció XPath.
Per exemple, l’expressió següent ens tornarà el nombre d’alumnes:

1 count (
2 for $alumne in doc("alumnes.xml")//nom
3 return $alumne
4 )
"for ... at"

En el for es pot incloure l’operador at, que permet obtenir la posició del node
que s’està processant. Amb aquest operador es pot fer que surti el número d’ordre
en els resultats.
1 for $alumne at $pos in doc("classe.xml")//alumne
2 return <alumne numero="{$pos}">
3 { $alumne/cognom/text() }
4 </alumne>
Que donarà:
2 <alumne numero="1">Pi</alumne>
3 <alumne numero="2">Garcia</alumne>
4 <alumne numero="3">Puigdevall</alumne>
"for" amb múltiples variables

Fins ara només s’ha fet servir una variable en el for però se n’hi poden posar
tantes com faci falta separant-les per comes:
1 <resultats>
2 {
3 for $tot in doc("classe.xml")/classe,
4 $nom in $tot/alumnes,
5 $modul in $tot/assignatura/text()
6 return
7 <modul nom="{ $modul }"
8 alumnes="{ count($nom/alumne)}">
9 { $nom/alumne/nom }
10 </modul>
11 }
12 </resultats>
Que donarà el resultat següent:

2 <resultats>
3 <modul alumnes="3" nom="Llenguatges de marques">
6 <nom>Manel</nom>
7 </modul>
8 </resultats>
"for" niuat
Imbricant les instruccions Les ordres for es poden imbricar entre elles d’una manera similar a com ho fa
for entre elles es poden
aconseguir el que SQL SQL per poder aconseguir resultats més complexos que es basin en els resultats
anomena outer joins. O
sigui que es retonaran obtinguts anteriorment.
sempre tots els resultats de
la primera consulta i, només
en el cas que hi hagi alguna 1 for $selec in doc("classe.xml")//alumne
relació, s’uniran amb els de 2 return
la segona consulta. 3 <persona>
4 { $selec/nom }
5 {
6 for $selec2 in $selec
7 return $selec2//cognom
8 }
9 </persona>
let
let permet declarar variables i assignar-los un valor. Sobretot es fa servir per

emmagatzemar valors que s’han de fer servir més tard.
1 let $num := 1
2 let $nom := "manel"
3 let $i := (1 to 3)
En les expressions FLWOR hi pot haver tants let com calgui.
1 for $alumne in doc("notes.xml")//alumne

2 let $nom := $alumne/nom
3 let $nota := $alumne/nota
4 return <nom>concat($nom,":",$nota)
S’ha d’anar amb compte amb let perquè el seu funcionament és molt diferent del
de for:
• for s’executa per a cada membre d’una seqüència.
• let fa referència al seu valor en conjunt. Si és una seqüència el que es

processa són tots els valors de cop.
Podem veure la diferència amb un exemple. Aquesta instrucció amb for:
1 for $selec in doc("classes.xml")//alumne

2 return <persona>{$selec/nom}</persona>
Dóna:

2 <persona><nom>Frederic</nom></persona>
3 <persona><nom>Filomeno</nom></persona>
4 <persona><nom>Manel</nom></persona>
I en canvi amb let:
1 let $selec := doc("classes.xml")//alumne

2 return <persona>{$selec/nom}</persona>
Donarà:
2 <persona>
5 <nom>Manel</nom>
6 </persona>
Els resultats són bastant diferents! Es pot veure clarament que let ha tractat tots
els valors de cop.
Condicions
La instrucció where és la part que indicarà quin filtre s’ha de posar a les dades
rebudes abans d’enviar-les a la sortida del return. Normalment en el filtre es fa
servir algun tipus de predicat XPath:
2 where $alumne/@aprovat="si"
3 return $alumne/nom
Com que XPath forma part d’XQuery moltes vegades el mateix filtre es pot definir
de diverses maneres. Per exemple, aquesta expressió és equivalent a l’anterior:
1 for $alumne in doc("classe.xml")//alumne[@aprovat="si"]
2 return $alumne/nom
En un where hi pot haver tantes condicions com calgui simplement encadenant-les

amb les operacions lògiques and, or o not().
Aquesta expressió retorna el cognom dels alumnes que han aprovat i que es diuen
Pere:
2 where $alumne/@aprovat="si" and nom="Pere"
3 return $alumne/cognom
El where afegeix més potència del que sembla, ja que ens permet fer els inner
joins d’SQL en fitxers XML. Per exemple, a partir de dos fitxers amb les dades
de dues classes diferents es poden obtenir només els alumnes que es repeteixen
entre les dues classes amb:
1 for $alum1 in doc("classe1.xml")//alumne
2 let $alum2 in doc("classe2.xml")//alumne
3 where $alum1 = $alum2
4 return $alum1
Quantificadors existencials
A vegades cal comprovar si algun o tots els elements d’una seqüència compleixen
una determinada condició, i per això s’han definit les expressions quantificades.
Amb les expressions quantificades es poden fer comprovacions sense haver de
recórrer a comptadors (taula 3.5).
Taul a 3. 5.
Quantificador Serveix per
every .. satisfies Comprovar que tots els elements compleixin una

condició determinada.
some .. satisfies Comprovar que algun dels elements de la llista

compleixin la condició.
A aquestes expressions els passem una variable que capturarà el valor concret
respecte al qual es vol fer la comprovació. Per exemple, amb aquesta expressió
només donarà el nom de la classe si tots els alumnes de la seqüència tenen de
cognom Pi:
1 for $s in doc("classe.xml")//alumnes
2 where some $e in $s//cognom satisfies ($e="Pi")
3 return $s/modul
Canviant every per some retornarà el nom de la classe si algun dels alumnes es
diu de cognom Pi”:
1 for $s in doc("classe.xml")//alumnes
2 where some $e in $s//cognom satisfies ($e="Pi")
3 return $s/modul
Aquestes expressions per si soles no serveixen per filtrar contingut, ja que sempre
retornen cert o fals. Per aquest motiu sempre se solen fer servir dins d’una clàusula
where.
Ordenació
Una de les operacions habituals en les cerques és representar els resultats en un

ordre determinat. Aquesta és la funció que fa order by.
Es pot ordenar de manera ascendent amb ascending (que és el que fa per defecte)
o bé descendent amb descending.

2 order by $alumne/cognom
3 return $alumne
També es poden especificar diferents conceptes en l’ordenació. En aquest exemple

els resultats s’ordenaran primer per cognom i després per nom:

2 order by $alumne/cognom, $alumne/nom
3 return $alumne
En aquest altre el cognom s’ordena de manera descendent i el nom de manera

ascendent.

2 order by $alumne/cognom descending, $alumne/nom ascending
3 return $alumne
Per defecte ordena com si el contingut de les etiquetes fos text. Si cal obtenir una
ordenació numèrica caldrà convertir els valors a nombres amb la funció d’XPath
number().
2 order by number($numero)
3 return $alumne
3.2.8 Alternatives
La instrucció if ens permetrà fer una cosa o una altra segons si es compleix la
condició especificada o no. Per exemple, podem fer una llista d’alumnes en què
s’especifiqui si han aprovat o no a partir del valor que hi ha en l’element <nota>.
1 let $doc := doc("classe1.xml")
2 let $aprovat := 5
3 for $b in $doc//alumne
4 return
5 if ($b/nota >= 5) then
6 <data>
7 { $b/nom/text() } està aprovat
8 </data>
9 else
10 <data>
11 { $b/nom/text() } no està aprovat
12 </data>
Això generarà el resultat següent:

1 <data>Frederic està aprovat</data>
2 <data>Filomeno no està aprovat</data>
3 <data>Manel està aprovat</data>
La instrucció else és habitual en llenguatges de programació, però a diferència

del que passa normalment, en XQuery, encara que no es vulgui fer res, en cas que
la condició falli s’hi ha d’especificar l’else. Si no es vol que faci res es deixa en
blanc.
1 for $classe in doc("classe1.xml")//alumne
2 return if ($classe/nota > 5) then
3 <aprovat/>
4 else ()
3.2.9 El pròleg XQuery
A pesar que en moltes expressions XQuery no s’especifica cap pròleg, les

expressions XQuery estan formades per dues parts:
• Pròleg: és una part opcional i serveix per donar informació al processador

per saber com s’ha d’avaluar l’expressió. Exemples típics són declarar
espais de noms, variables o funcions, importar esquemes, o definir com

s’han de tractar els espais en blanc.
• Cos: és on hi ha el que es vol fer amb l’expressió.
Un valor que se sol especificar en el pròleg és la versió d’XQuery que s’ha de fer
servir en la consulta. És opcional, però si s’hi posa ha de ser la primera línia del
fitxer.
1 xquery version "1.0";
També s’hi poden definir altres coses com informació sobre la consulta o dades
que posteriorment es podran fer servir en el cos de l’expressió.
En aquest exemple, en la capçalera es passa informació al processador sobre com

ha de tractar els espais, s’hi declara una variable $alum que contindrà una part
del document XML i es defineix un espai de noms ioc. Les variables i l’espai de
noms es poden fer servir en l’expressió.
1 xquery version "1.0";
2 declare boundary−space preserve;
3 declare namespace ioc="http://ioc.xtec.cat/alum";
4 declare variable $alum := doc("alumnes.xml")//alumne;
5
6 <ioc:llista>
7 {
8 for $nom in $alum/nom
9 return <alumne>{$nom}</alumne>
10 }
11 </ioc:llista>
En executar la consulta el processador afegirà automàticament l’espai de noms al

resultat de l’expressió en la definició de <llista>:
2 <ioc:llista xmlns:ioc="http://ioc.xtec.cat/alum">
3 <ioc:alumne>
5 </ioc:alumne>
6 <ioc:alumne>
8 </ioc:alumne>
9 <ioc:alumne>
10 <nom>Manel</nom>
11 </ioc:alumne>
12 </ioc:llista>
Un dels usos interessants del pròleg és que permet passar paràmetres a les
expressions. Si es declara una variable com external, per poder executar la
consulta s’haurà de proporcionar un valor a la variable:
1 declare variable $entrada as xs:string external;
2
3 <resultat>
4 { $entrada }
5 </resultat>
Per executar la consulta anterior amb la utilitat Query de Saxon s’haurà d’especi-
ficar el valor de la variable entrada de la manera següent:
1 C:\> Query prova.xquery entrada=Hola

2 <?xml version="1.0" encoding="UTF−8"?><resultat>Hola</resultat>
Un altre ús interessant del pròleg és que permet definir funcions:
1 declare function quadrat($numero as xs:integer) return xs:integer

2 {
3 return ($numero*$numero)
4 };
Aquestes es poden cridar de la mateixa manera que les funcions normals d’XPath:
1 quadrat($alumne/nota)
3.2.10 Actualitzacions de dades
Un llenguatge que pretengui ser un estàndard de consulta ha de poder gestionar

completament les dades, i per tant necessita alguna manera de fer consultes però
també canviar, afegir o esborrar dades. XQuery 1.0 és bàsicament un llenguatge
de consultes, i tot i que la majoria de les operacions que es fan en els sistemes
de base de dades són consultes, necessita alguna manera de poder actualitzar les
dades.
Per aquest motiu en el W3C s’ha posat en marxa la creació d’un sistema d’actualit-
zacions anomenat xqupdate (XQuery Update Facility 1.0), que ha de permetre
a XQuery fer les actualitzacions. Alhora també hi ha altres iniciatives per crear un
estàndard per actualitzar valors en sistemes XML com el que promociona el grup
XMLDB, que s’anomena XUpdate (XML update language).
La falta d’existència d’un estàndard clar fa que els programes que implementen
XQuery, si volen oferir la possibilitat de fer actualitzacions, no sempre tinguin clar
quin sistema d’actualitzacions han de fer servir i es decantin pel que els agrada més,
per incloure’n diversos o fins i tot per crear el seu propi sistema.
Fer servir XQuery per respondre preguntes sobre documents XML
Partint d’aquest XML d’exemple que representa comandes de llibres:

2 <petició llibreria="Fantastica SL">
3 <data>15−11−2011</data>
4 <autor>
6 <llibres>
7 <llibre>
8 <titol>Les empentes</titol>
10 </llibre>
11 </llibres>
12 </autor>
13 <autor>
15 <llibres>
16 <llibre>
17 <titol>Marxant de la font del gat</titol>
19 </llibre>
20 <llibre>
21 <titol>Bèstia!</titol>
23 </llibre>
24 </llibres>
25 </autor>
26 <autor>
27 <nom>Marc Blairet</nom>
28 <llibres>
29 <llibre>
30 <titol>Tres de tres</titol>
32 </llibre>
33 </llibres>
34 </autor>
35 </petició>
Es vol respondre la pregunta següent: de quins autors s’han demanat tres o més
llibres?
Per respondre aquesta pregunta el primer que cal és separar el document en blocs d’autor
i processar-ne cada un de manera diferent. Per tant, es defineix un bucle amb un for per
cada autor i s’escriu el nom per pantalla
1 for $autor in doc("llibres.xml")//autor

2 return $autor/nom
Si es passa l’expressió per un processador XQuery el resultat serà una llista de tots els
autors:

Es vol definir una restricció amb la quantitat de llibres que s’han demanat de cada autor;
per tant, ho podríem intentar fer amb el where

2 where $autor/llibres/llibre/quantitat >= 3
3 return $autor/nom
Aquesta és la llista dels autors que tenen alguna petició de 3 o més llibres

Però es pot veure que encara no és el demanat, ja que no surt l’autor Corsaro Levy, del qual
s’han demanat dues unitats llibres diferents. Per tant, agrupem les quantitats per obtenir el
resultat correcte

2 where sum($autor/llibres/llibre/quantitat) >= 3
3 return $autor/nom
Ara el resultat sí que és el correcte:

Podem fer que el resultat sigui més “bonic” mostrant les quantitats venudes al costat de
cada autor i ordenant de més a menys els resultats.

2 let $suma := sum($autor/llibres/llibre/quantitat)
3 where $suma >=3
4 order by $suma descending
5 return concat($autor/nom," : ", $suma)
Es pot veure que per no haver d’escriure diverses vegades l’expressió de suma s’ha definit
una variable $suma i d’aquesta manera l’expressió ha quedat més fàcil d’escriure

2 Corsaro Levy : 4
3 Marc Blairet : 3
La funció concat() ha eliminat les etiquetes XML i ha generat un resultat de text. Si

es volgués mantenir una estructura XML es pot crear manualment amb l’ajuda de les
expressions avaluables:

2 let $suma := sum($autor/llibres/llibre/quantitat)
3 where $suma >=3
4 order by $suma descending
5 return <autor> { concat($autor/nom," : ", $suma) } </autor>
Que generarà:

2 <autor>Corsaro Levy : 4</autor>
3 <autor>Marc Blairet : 3</autor>
3.3 Bases de dades natives XML
Si no entrem en detalls tècnics, la definició d’una base de dades és un lloc en

el qual es poden emmagatzemar dades. En el cas d’una base de dades en XML,
consistiria simplement en emmagatzemar els fitxers XML en un punt concret del
sistema operatiu.
L’increment de documents XML a emmagatzemar ha fet que, malgrat que l’emma-

gatzematge es pugui fer manualment, sigui interessant disposar d’alguna manera
d’automatitzar el procés. Per facilitar aquesta automatització han aparegut les
bases de dades natives XML (NXD).
Quan es parla de bases de dades natives XML es fa referència a bases de

dades dissenyades per contenir i emmagatzemar dades en format XML.
A diferència del que passa amb les bases de dades relacionals, que fa molts anys
que funcionen i tenen darrere seu una base teòrica important, les NXD no tenen
uns estàndards definits per fer les coses i la teoria que les suporta no està gaire
definida. Això fa que sovint cada base de dades faci les coses d’una manera que
pot ser totalment diferent de com ho fa una altra.
Les bases de dades natives XML es fan servir sobretot per emmagatzemar dades
que contenen:
• Contingut narratiu.
• Que són menys previsibles que les que s’emmagatzemen normalment en

bases de dades relacionals.
• Que han de generar sortides per a entorns web.
• Que s’han de transportar d’un sistema a un altre.
3.3.1 Característiques més importants
Els sistemes NXD són molt heterogenis i sovint s’estan desenvolupant en direcci-
ons que no sempre coincideixen. Tot i la dispersió, sempre podem trobar punts en
comú en la majoria de les bases de dades.
Llenguatge de consulta
Tots els sistemes NXD suporten com a mínim XPath com a llenguatge de consultes,
tot i que la tendència general és adoptar XQuery; és lògic si es té en compte que
XPath no va ser pensat per ser un llenguatge de consulta de base de dades, mentre
que XQuery sí.
Tots els sistemes suporten algun tipus d’interfície que permet accedir-hi per mitjà
d’algun llenguatge de programació, com ara la interfície XML:DB, o bé per mitjà
d’algun protocol de xarxa com HTTP, WebDAV, SOAP...
Organització i emmagatzematge
L’organització més habitual de les dades és mitjançant col·leccions de documents

XML que sovint intenten generar una estructura semblant a la que ofereixen els
directoris dels sistemes operatius. En aquests sistemes una col·lecció és com una
carpeta que conté un conjunt de documents XML o fins i tot altres carpetes (figura
3.9).
Fi gura 3 .9. Les col·leccions en eXist són carpetes que contenen fitxers
El tractament de les col·leccions sol ser una de les diferències que hi ha entre
bases de dades XML. Algunes forcen que dins d’una col·lecció hi hagi documents
del mateix tipus, mentre que altres permeten que s’hi posi qualsevol tipus de
document.
L’emmagatzematge de les dades sol ser el que diferencia més les NXD, ja que la
naturalesa dels fitxers XML no els fa ideals per ser emmagatzemats de manera
eficient (tenen repeticions, ocupen molt d’espai...). Per aquest motiu totes les
NXD intenten optimitzar d’alguna manera aquest emmagatzematge: convertint
les dades en fitxers binaris (amb simples compressions de dades o codificant-les),
creant estructures d’arbre, o simplement emmagatzemant els fitxers XML sense
fer-hi res confiant que la reducció de costos de l’emmagatzematge farà que ocupar
espai no sigui un problema.
Indexació
A l’hora de fer servir una base de dades el que importa realment a l’usuari és que
faci la cerca en un temps acceptable. Els fitxers de text no són la millor manera
d’emmagatzemar dades si l’objectiu és fer-hi cerques, i per tant les bases de dades
XML s’han esforçat a intentar crear algun sistema per fer aquestes cerques més
eficients.
El més habitual sol ser:
• Organitzar de manera eficient les col·leccions
• Fer servir índexos

Si som prou organitzats a
l’hora de desar els
documents XML podria ser
Com passa en el món real, pot ser més senzill trobar el que busquem si tenim les que ni ens fes falta tenir una
base de dades XML.
dades ben organitzades i ben classificades que si les tenim de manera caòtica. Per
tal per buscar les dades només caldrà accedir a la col·lecció adequada i des d’allà
fer la cerca.
Un altre punt de vista consisteix a indexar les dades d’alguna manera per poder
aconseguir recórrer la informació en un ordre determinat que permeti accedir a
les dades d’una manera més ràpida. A diferència del que passa amb les bases de
dades relacionals, en les d’XML no hi ha desenvolupades gaire teories sobre com
s’han de crear els índexs, i això fa que els diferents productes facin servir filosofies
d’indexació totalment diferents.
A pesar d’això el mètode d’indexació més corrent és crear una estructura d’arbre
paral·lela als documents XML que contingui les dades que cal que siguin indexa-
des.
Seguretat
La seguretat és un altre aspecte per tenir en compte en els sistemes NXD.

Generalment en un entorn empresarial no tothom pot accedir a les dades que
vulgui sinó que a la informació poden accedir només les persones autoritzades
(figura 3.10).
Fig u ra 3 . 1 0 . eXist demana autorització per permetre la connexió
La identificació d’usuaris permet implementar els mecanismes bàsics per perme-

tre controlar a quins documents pot accedir cada un dels usuaris de l’organització
(figura 3.11).
Fi gura 3 .11 . Permisos de fitxers
Actualitzacions de les dades XML
La falta d’un sistema d’actualitzacions dels fitxers XML en la primera versió

d’XQuery ha fet que molt sovint els sistemes NXD, en comptes d’actualitzar les
dades que han canviat, optin per substituir totalment el document cada vegada que
s’hi produeixin canvis.
Per aquest motiu se solen oferir sistemes de transferència de fitxers via HTTP
com WebDAV (figura 3.12) (Web-based distributed authoring and versioning) o
per mitjà de serveis web (SOAP o REST).
Fi g ura 3 .12 . Connexió amb eXist per mitjà de WebDAV
A pesar d’això la tendència és que els sistemes s’acullin a alguna de les propostes
d’estàndards d’actualització de dades XML com xqupdate o XML:DB XUpdate.
3.3.2 Exemples de bases de dades natives XML
Hi ha moltes bases de dades XML que s’estan fent servir actualment en entorns
professionals:
• Tamino: permet tenir un sistema híbrid d’emmmagatzematge XML i

relacional.
• eXist-db: es tracta d’un sistema de codi obert que fa servir una indexació
de dades amb BTree en fitxers dividits en pàgines.
• TigerLogic XDMS: es pot fer servir tant per emmagatzemar documents

XML com dades multimèdia.
• EMC xdb: una base de dades per a documents XML molt escalable.
• Apache XIndice: es tracta d’un sistema pensat per emmagatzemar grans

col·leccions de petits fitxers XML. És de codi obert.
• MarkLogic: ofereix una solució empresarial per emmagatzemar qualsevol

tipus de documents, metadades, RSS, correus electrònics, XML...
Generalment totes ofereixen:
• Emmagatzematge eficient de documents XML
• Suport per a consultes XQuery o XPath
• Alguna forma orientada a recursos d’accés a les dades: HTTP, webDAV,

serveis web...
• Transformació de documents
• Diverses interfícies d’usuari
3.3.3 eXist-db
De les bases de dades XML de codi obert disponibles, probablement eXist-db és

la que està més preparada per ser usada en un entorn professional. Es tracta d’una
base de dades nativa XML que està desenvolupada en llenguatge Java, i que:
• Permet fer operacions amb els llenguatges XQuery 1.0, XPath 2.0 i XSLT
2.0.
• Pot funcionar tan com una biblioteca que s’incorpora als programes com ser
executada per mitjà d’un servidor.
• Es pot accedir a la base de dades per mitjà de múltiples interfícies estàndards

com REST, WebDAV, SOAP, XML-RPC o ATOM.
• Permet actualitzacions de dades per mitjà de l’API XMLDB, XUpdate i

XQuery Update Facility.
• Porta incorporat un sistema de gestió d’usuaris de la base de dades i dels

permisos d’accés a les col·leccions semblant al dels sistemes Unix (figura
3.13).
Fi g ura 3 .13 . Cada fitxer té permisos d’usuari i de grup
L’organització de les dades és per mitjà de col·leccions de fitxers XML que

s’organitzen d’una manera pràcticament idèntica a com es fa en els fitxers d’un
sistema operatiu. Igual que en els sistemes operatius, es poden fer col·leccions
dins de col·leccions i s’hi pot navegar amb un sol clic (figura 3.14).
Fi g ura 3 .14 . L’organització es fa en col·leccions i són navegables

Instal·lació
La instal·lació es fa per mitjà d’un senzill sistema d’instal·lació basat en finestres

(figura 3.15).
F igu ra 3 .1 5 . Instal·lació d’eXist
En la instal·lació per defecte a més de l’eXist s’hi instal·la el servidor Jetty,

que permetrà accedir a la gestió web del sistema amb un navegador en l’adreça
http://localhost:8080/exist/.
Si es fa servir el servidor, l’accés a les consultes i l’administració del sistema es

pot fer per mitjà d’un client Java que proporciona, o bé per mitjà de l’entorn web
(figura 3.16).
Figu r a 3 . 16 . Client Java per connectar amb la base de dades

Tant el client com el client web disposen d’un entorn per poder elaborar consultes
XQuery (figura 3.17).
Fi gura 3 .17 . Consultes Xquery des del client
Treballar interactivament amb l’eXist
Abans de poder començar a treballar amb l’eXist cal que s’hagin entrat les dades
en la base de dades. En aquest exemple ens concentrarem en com es pot fer des
de l’entorn web però es pot fer d’una manera semblant des del programa client.
Crear una col·lecció

Amb l’eXist en marxa, des de la mateixa màquina on s’ha instal·lat l’eXist obriu
un navegador i aneu a l’adreça http://localhost:8080/exist/ (figurafigura 3.18).
F ig ur a 3. 18 . Pàgina inicial de l’eXist

En la part inferior de la columna de l’esquerra hi ha un enllaç dins de la secció

“Administration” que es diu “Admin” (figura 3.19).
Fig u ra 3 . 1 9
En clicar-hi us portarà a una finestra on es demana la identificació de l’usuari. El

primer cop que s’hi accedeix no hi ha usuaris, i per tant caldrà entrar amb l’usuari
admin i la contrasenya especificada en la instal·lació (figura 3.20).
F igu ra 3 .2 0
Fig u ra 3 . 2 1 . Pantalla d’administració de l’eXist

Un cop esteu identificats, entreu en la zona d’administració; al costat esquerre hi

ha un menú que permet fer diverses coses, com navegar per les col·leccions i els
índexs, aturar el servidor, instal·lar els fitxers d’exemple, crear usuaris... (figura
3.21).
Per crear una col·lecció nova cal anar al menú de l’esquerra i clicar en l’opció
“Browse collections”. Això farà que aparegui tota la llista de les col·leccions
instal·lades en el sistema. Per crear una nova col·lecció anomenada classes, cal
que escrigueu el nom en el quadre de text i premeu el botó (figura 3.22).
Fi g ura 3 .22 . Fer una llista de les col·leccions
En entrar-hi la col·lecció no té cap fitxer XML: els podeu afegir amb l’ajuda del
botó “Upload”; i ja tindreu la col·lecció creada (figura 3.23).
Fi gura 3 .23 . Creada la col·lecció classes
Fer consultes XQuery

Les consultes XQuery també es poden fer des de qualsevol dels entorns que
proporciona l’eXist-db. Per fer-ho des de l’entorn web cal anar a la pàgina
principal i en el menú de l’esquerra, dins de l’opció “Example”, escollir l’opció
“XQuery SandBox”.
Aquesta opció us portarà a una pàgina en la qual es poden fer consultes XQuery
de les col·leccions o els fitxers XML que hi ha en el sistema (figura 3.24).
Fig u ra 3 . 2 4 . XQuery SandBox
A partir de la versió 1.5 s’ha afegit l’opció “XQuery IDE (eXide)”, que és un
sistema molt més potent que ofereix tota una sèrie d’avantatges afegits: comprova
interactivament els errors, permet autoemplenar en temps de disseny, etc. (figura
3.25).
F igu ra 3 . 2 5 . eXide
Sigui quina sigui l’opció triada, en la finestra superior sortirà un espai destinat a
escriure la consulta que es vol fer en XQuery (o XPath), i en la part inferior es
podran veure els resultats.
Per exemple, per fer una consulta que retorni el nom dels alumnes de dins de la
col·lecció “classes”, podem escriure una expressió XQuery com la següent:
1 for $alumne in collection("/db/classes")//alumne/nom

2 return $alumne/text()
Que donarà el que es veu en la figura 3.26.
Fi g ura 3 .26 . Noms dels alumnes de la col·lecció

Sistemes de gestió
empresarial
Xavier Sala

d’informació
Llenguatges de marques i sistemes de gestió d’informació Sistemes de gestió empresarial
Índex
Introducció 5
1 Sistemes empresarials de gestió d’informació 9

1.1 Objectius bàsics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Presa de decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.2 Facilitar les tasques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Programari empresarial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 Aplicacions genèriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.2 Programari a mida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Programari estàndard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.4 ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.5 Implantació d’un ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3 Funcionament d’un ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.1 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.4 Tendències . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2 Serveis web 37
2.1 La web programable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2 Els serveis web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.1 Característiques dels serveis web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.2 Tipus de serveis web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3 Big Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.1 Funcionament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.3 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.4 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.5 Provar serveis web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4 Arquitectures basades en REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.4.1 Els recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.4.2 Representacions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.4.3 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.5 Desenvolupament de serveis web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5.1 Desenvolupament de serveis basats en SOAP . . . . . . . . . . . . . . . . . . . . . . 61
2.5.2 Desenvolupament de serveis basats en REST . . . . . . . . . . . . . . . . . . . . . . 63
2.5.3 Entorns de desenvolupament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3 Informàtica en núvol 69
3.1 Característiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.1.1 Ubiqüitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.1.2 Infraestructura informàtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.1.3 Adaptació a les necessitats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.1.4 Reducció de costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Llenguatges de marques i sistemes de gestió d’informació Sistemes de gestió empresarial
3.2 Classificació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.2.1 Segons la propietat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.2.2 Segons els nivells de servei ofert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.3 Resistències a l’adopció de la informàtica en núvol . . . . . . . . . . . . . . . . . . . . . . . 82
3.3.1 Privacitat i seguretat de les dades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.3.2 Captivitat en el proveïdor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.3.3 Aspectes Legals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Llenguatges de marques i sistemes de gestió d’informació 5 Sistemes de gestió empresarial
Introducció
La informàtica ha canviat completament la manera com es fan les tasques en

les empreses. Primer es va començar fent que els ordinadors s’encarreguessin
de les tasques repetitives i monòtones però de mica en mica ha anat absorbint
cada vegada tasques més importants i relacionades amb la presa de decisions. La
importància és tan gran que si bé inicialment es veia la informàtica com una ajuda,
actualment pràcticament ningú no es planteja la creació d’una empresa sense tenir
equipaments informàtics.
En l’apartat “Sistemes empresarials de gestió d’informació” es deixen una mica

de banda els llenguatges de marques per fer una repassada al programari que s’està
fent servir en les empreses i en la revolució que han comportat els sistemes ERP.
Els serveis web han estat decisius en la possibilitat de dissenyar programari que
es pugui comunicar amb altre programari independentment del llenguatge i el
sistema operatiu en què estiguin dissenyats cadascun. En l’apartat “Serveis web”
es descriuen dues tecnologies basades en XML per la interacció entre programari:
els serveis web basats en SOAP i els serveis d’estil REST.
Si l’aparició dels ordinadors va representar una revolució en les empreses, Internet

ha estat i està essent un altre dels factors que provoca canvis profunds en el món
de l’empresa. El darrer apartat, anomenat “Informàtica en el núvol”, explica
una de les tendències en el programari empresarial. Si fins ara les empreses
externalitzaven alguns dels serveis que oferien, ara la informàtica en núvol
els permet arribar a externalitzar fins i tot la seva infraestructura informàtica.
D’aquesta manera les empreses poden obtenir els recursos informàtics que els
calguin sense haver de suportar importants inversions en equipament informàtic.
En general la tendència en el programari empresarial és ajudar a aconseguir que

les empreses puguin tenir processos empresarials més flexibles i dinàmics que els
permetin optimitzar-ne el funcionament.
En acabar aquesta unitat, l’alumne:
1. Treballa amb sistemes empresarials de gestió d’informació fent tasques

d’importació, integració, assegurament i extracció de la informació.
• Reconeix els avantatges dels sistemes de gestió i planificació de

recursos empresarials.
• Avalua les característiques de les principals aplicacions de gestió
empresarial.
• Instal·la aplicacions de gestió empresarial.
• Configura i adapta les aplicacions.
• Estableix i verifica l’accés segur a la informació.
• Genera informes.
• Fa tasques d’integració amb aplicacions ofimàtiques.
• Porta a cap procediments d’extracció d’informació per tractar aquesta
informació i incorporar-la a diversos sistemes.
• Acompleix tasques d’assistència i resolució d’incidències.
• Elabora documents relatius a l’explotació de l’aplicació.
1. Sistemes empresarials de gestió d’informació
Els sistemes informàtics han canviat la manera de treballar de les empreses en

molts aspectes però sobretot en el camp de la informàtica de gestió. Però la La informàtica de gestió és
informatització de les empreses no acaba en la informàtica de gestió, ja que una de les branques més
importants de la informàtica
actualment es fan servir sistemes informàtics per controlar pràcticament qualsevol ja que és l’encarregada de
donar suport als sistemes
dels aspectes del seu funcionament, des de la facturació fins al detall més mínim d’informació de les
empreses.
de la relació amb els clients; i tot amb l’objectiu d’aconseguir que les empreses
siguin més competitives i eficients.
1.1 Objectius bàsics
Si bé inicialment els programes informàtics només es feien servir per agilitzar les
tasques de l’empresa, actualment tenen un paper fonamental en moltes empreses.
Essent molt generalistes podem dir que els sistemes informàtics s’han implantat
amb dos objectius bàsics:
• Facilitar les tasques als treballadors.
• Facilitar les preses de decisions dels dirigents.
És des d’aquest prisma que sovint es fan les valoracions sobre l’èxit o el fracàs de
la implantació d’un sistema informàtic en una empresa.
1.1.1 Presa de decisions
Un dels objectius comuns en gairebé totes les organitzacions és obtenir i mantenir

un avantatge competitiu, que a la vegada proporciona un avantatge a llarg termini.
Això planteja un seguit de qüestions, com ara:
• S’ha d’invertir?
• S’ha de produir més?
• S’ha de contractar més personal?
• ...
Malgrat que totes les empreses són diferents, tenen en comú que aquest avantatge
competitiu sovint es basa en la presa de decisions en el moment adequat, i
normalment en un curt espai de temps, ja que descobrir tard les necessitats del
mercat pot fer que algú altre se n’aprofiti i aconsegueixi posicionar-se i sigui molt
difícil competir-hi.
El fet que les decisions que es prenguin puguin afectar directament el futur de
l’empresa i que s’hagin de prendre en el moment adequat fan dels sistemes
informàtics un recurs valuosíssim per a qualsevol organització. Les decisions ja no
s’han de prendre per intuïcions ni de manera aleatòria, sinó basades en les dades
que es poden obtenir dels sistemes informàtics.
Podem dividir les dades en dos grans grups:
• Dades internes: generades per l’empresa mateixa, com ara nombre de

vendes, preus dels proveïdors i capacitat de producció de l’empresa.
• Dades de l’entorn: la situació del mercat, els competidors, la legislació...
Una de les funcions determinants de les empreses és extreure informació a

partir de les dades que pugui recollir però s’hi ha d’afegir un factor important:
aquesta informació ha d’estar disponible en el moment oportú.
El problema més gran rau en el fet que la societat de la informació està fent que
tothom rebi una gran quantitat de dades al dia i a pesar que moltes d’aquestes dades
són irrellevants per als objectius de l’empresa n’hi ha moltes que són o podrien
ser importants en la presa de decisions i per tant s’han de poder detectar.
Això fa que les empreses es vegin obligades a tractar una gran quantitat d’informa-
ció, i la gestió d’aquesta informació és una pràctica costosa tant en l’ús de recursos
com en persones.
Per aquest motiu els sistemes informàtics són bàsics per proporcionar els mecanis-
mes per destriar les dades que serveixen de les que no serveixen, per organitzar
i classificar les dades amb vista a obtenir la informació necessària en el moment
adequat.
1.1.2 Facilitar les tasques
El fet que la informatització ha facilitat les tasques que havien de dur a terme els
treballadors es veu molt clarament en el que ha passat en el procés de transaccions
de les empreses. El procés de transaccions comprèn tota una sèrie de tasques
rutinàries com control d’estocs, elaboració d’albarans, elaboració de factures, o
comptabilitat que s’han de fer en una empresa i que abans requerien molts recursos
El fet que les activitats del
procés de transaccions per desenvolupar-se, com mostra la figura 1.1.
siguin rutinàries no vol dir
que no siguin importants ja
que el mal funcionament Aquest procés es caracteritza pel fet de tenir una gran quantitat de dades d’entrada
d’alguna d’aquestes
tasques pot portar greus a les quals s’aplica un procés, que no sol ser gaire complex, i que genera una gran
problemes a les empreses.
quantitat de sortides.
Fi gura 1 .1. Procés de transaccions d’una empresa
Abans de l’aparició de la informàtica, aquests processos, tot i que no solen ser

complexos, consumien una gran quantitat de recursos: s’hi havia de destinar molt
de personal, calia lloc per emmagatzemar les dades...
La informatització va agilitzar notablement aquests processos, alliberant molts

dels recursos que es dedicaven al procés de transaccions per destinar-los a
altres tasques. L’èxit va ser tan gran que actualment el procés de transaccions
informatitzat està implementat en qualsevol empresa.
Els sistemes informàtics han contribuït i estan contribuint a fer les tasques més
ràpides i menys propenses a errors i per tant permeten a les empreses reduir
costos i oferir més bon servei.
1.2 Programari empresarial
Hi ha una gran i molt variada quantitat d’aplicacions que es poden fer servir en les
empreses. Els programes que es fan servir en les empreses van des de programes
d’ofimàtica fins a programes totalment especialitzats per a una empresa d’un sector
concret.
Per programari empresarial s’entén qualsevol tipus de programari que ajudi

a mesurar o millorar la seva activitat.
És molt difícil fer una classificació del programari empresarial però una de
possible és basar-se en quina és la idea base per crear-lo. Des d’aquest punt de
vista podem dividir el programari que es fa servir per gestionar una empresa en:
• Aplicacions genèriques.
• Programari a mida.
• Programari estàndard.
• ERP (programari de gestió integrada o enterprise resource planning).

En general les empreses grans solen tenir un control més gran sobre tots els
aspectes del negoci, mentre que les més petites tendeixen a tenir un programari
amb funcions similars però amb un cost i funcions inferiors.
1.2.1 Aplicacions genèriques
En les empreses també es fan servir tota una sèrie d’aplicacions que no estan
desenvolupades específicament per a la gestió de l’empresa sinó que són de
caràcter més general, com aplicacions ofimàtiques, navegadors web o programes
de correu.
Aquestes aplicacions, tot i que no estan desenvolupades específicament per a la

gestió de l’empresa, a vegades hi tenen un paper molt important; els navegadors
web, per exemple, són vitals per a l’accés a alguns serveis web; o pel que
fa a l’exportació de dades, se solen importar en algun paquet ofimàtic per fer
estadístiques o anàlisi de resultats que no estan definits en el programa de gestió
principal.
Fins i tot es donen casos d’empreses molt petites que poden fer servir programes
genèrics com per exemple aplicacions ofimàtiques per portar un control simplificat
de la seva activitat empresarial.
1.2.2 Programari a mida
En els principis de l’adopció de la informàtica per part de les empreses el més

corrent era que aquestes empreses definissin els seus sistemes informàtics fent un
programa que s’adaptés perfectament al seu funcionament o a les seves necessitats.
El programari a mida consisteix a desenvolupar un nou programa informàtic

que permeti informatitzar l’activitat de l’empresa.
La idea és contractar informàtics per desenvolupar un programa que permeti

informatitzar les tasques de la gestió de l’empresa. Com que es tracta de programes
específics per a l’organització, aquests programes s’adapten perfectament a les
seves necessitats.
Però aquests programes també presenten una sèrie de problemes:
• S’ha d’analitzar amb detall el funcionament de l’empresa per comprendre

perfectament què es vol fer.
• La implantació és un procés llarg i propens a errors, ja que el programa no

s’ha provat abans.
• S’adapten tan bé a l’empresa que qualsevol canvi en el funcionament

normalment provoca que també s’hagin de fer canvis en el programari. Això
fa que aquest tipus de programari sigui molt car de mantenir.
1.2.3 Programari estàndard
El programari estàndard de gestió d’empreses és un programari desenvolupat

específicament per poder funcionar en la majoria d’organitzacions.
El programari estàndard està pensat específicament per fer tasques concretes en

una empresa genèrica global o d’un sector concret. La idea que hi ha al darrere
d’aquestes aplicacions és intentar abaratir els costos i minimitzar els errors que es
produeixen en el desenvolupament d’aplicacions a mida oferint un paquet que faci
les funcions tan genèricament com sigui possible perquè es pugui usar en diferents
empreses. Tot i la semblança entre les
tasques de les empreses,
les petites especificitats que
Tot i que les empreses són totes diferents, la realitat és que hi ha una part molt les fan diferents són les que
les defineixen realment.
important de tasques que és comuna a totes. I gràcies a això es poden crear paquets
genèrics que es poden reutilitzar en diferents empreses.
Aquest sistema permet:
• Abaratir molt els costos perquè el programari ja està desenvolupat i provat.
• Reduir el temps d’implantació del programari. Generalment n’hi ha prou

amb entrar les dades i ja es pot començar a treballar.
Existeixen molts programes d’aquest tipus que normalment es concentren en les

necessitats de les petites i mitjanes empreses, oferint en un sol paquet control
d’estocs, punt de venda, comptabilitat i facturació.
Els inconvenients d’aquests programes estan en l’adaptació:
• Totes les funcions estan pensades per funcionar “en qualsevol lloc” i per
tant no solen adaptar-se perfectament a les especificitats de cap empresa.
• Poden provocar que sigui l’empresa la que s’hagi d’adaptar al funcionament

del programa i no al revés.
A més, a vegades els programes que s’adaptarien més bé als diferents departaments
d’una empresa no són del mateix desenvolupador. Per exemple, es pot donar el
cas que el programa de comptabilitat que va més bé sigui el de la companyia A,
mentre que el de gestió de magatzem sigui el de la companyia B.
Tenir programari de diferents empreses generalment provoca tota una sèrie de pro-
blemes però normalment el més important és “com ho fem perquè els programes
es comuniquin les dades entre si sense problemes?”
Fins i tot quan s’aconsegueix aquesta comunicació hi sol haver tota una sèrie de
dades d’un programa que no es passaran mai a l’altre (sia perquè no les fa servir
o perquè no li calen). I això genera el que anomenem illes informàtiques.
Es produeix una illa informàtica quan en una empresa hi ha diferents

departaments que tenen les seves pròpies dades i només en comparteixen
una part amb la resta de l’empresa.
A més s’ha de tenir en compte que els programes no són perfectes, i regularment
s’hi solen detectar problemes, evolucionen, i en surten noves versions. Pot passar
que una actualització d’algun dels programes faci que es generin problemes en
l’intercanvi de dades amb els altres programes, que a partir d’una determinada
funció es facin tasques de manera diferent...
Malgrat aquests inconvenients, el programari estàndard és una opció molt vàlida

que s’està fent servir en la gestió d’una gran quantitat d’empreses petites i mitjanes.
1.2.4 ERP
En el moment en què va fer falta unir les diferents aplicacions dels diferents
departaments d’una empresa es va veure que tenir un sistema d’emmagatzematge
únic milloraria l’eficiència de l’organització.
Els programaris de gestió integrada o enterprise resource planning (ERP) van

sorgir a partir dels sistemes industrials de planificació de recursos de fabricació o
material requeriment planning (MRP i MPR II) amb l’objectiu d’integrar tots els
sistemes d’informació de les empreses en un de sol (figura 1.2).
F igu ra 1 .2 . Evolució dels sistemes informàtics empresarials
El que fan els ERP és expandir el concepte d’MRP II a totes les àrees de negoci,
des de finances i control de projectes fins a recursos humans.
Els ERP són sistemes integrals per a la gestió de l’empresa. Es tracta d’un
programa integrat que permet avaluar i gestionar el negoci.
Són sistemes de gestió d’informació que automatitzen moltes de les tasques
d’operació i producció dels negocis d’una empresa.
Estan formats per diferents components o mòduls que ofereixen solucions a

determinats processos de negoci i que es poden integrar lliurement per formar
l’aplicació final. El funcionament modular permet a qualsevol empresa poder
adaptar el programa als canvis i a les necessitats de cada moment, integrant-hi

o eliminant-ne mòduls segons les noves necessitats.
A més, el fet de funcionar de manera modular permet que els ERP es puguin
adaptar a un conjunt diferent d’empreses i sectors ja que cada empresa només
cal que integri els mòduls que realment necessita.
Molts dels ERP, mitjançant algun tipus d’eines de desenvolupament, permeten

adaptar mòduls concrets a les necessitats particulars de l’empresa.
La gran diferència entre els ERP i les aplicacions tradicionals està en el fet que els
ERP intenten abastar tots els processos de l’empresa i no solament una part, com
feien les aplicacions tradicionals. Això fa que es puguin integrar totes les àrees i
procediments de l’empresa en una sola aplicació i permet obtenir-ne una visió
global d’una manera més senzilla.
La integració de tots els aspectes del negoci en una mateixa aplicació fa que se
simplifiquin les comunicacions entre els processos. Si partim d’un sistema
tradicional els diferents departaments han d’establir múltiples comunicacions amb
els altres departaments per poder fer la seva feina (figura 1.3).
Fi g ura 1 .3. Comunicacions entre processos amb sistemes tradicionals
En canvi, amb un ERP, els mòduls no cal que es comuniquin amb els altres mòduls;
simplement ho han de fer amb la font de dades comuna (figura 1.4).
Els ERP són conscients de l’ús d’aplicacions de propòsit general en les empreses
i solen estar pensats per interactuar amb paquets d’ofimàtica o navegadors.
Tampoc no han quedat aliens a l’explosió d’èxit que ha estat Internet:
• Pràcticament tots permeten que s’hi pugui treballar des de navegadors web
(i eliminen així la necessitat de clients específics).
• S’integren perfectament amb els programes de correu electrònic i comencen

a oferir integració amb xarxes socials o correu electrònic.
Fig u ra 1 . 4 . Comunicacions entre processos amb un ERP
Característiques dels ERP
Simplificant molt podem dir que un ERP està format per dos components bàsics
(figura 1.5):
Fig u ra 1 . 5 . Esquema bàsic d’un ERP
• Una base de dades centralitzada.
• Un grup de mòduls o aplicacions.
Base de dades centralitzada

Els ERP funcionen amb una base de dades centralitzada en què interactuen tots
els programes de manera que les dades només s’emmagatzemen una sola vegada
i mai no hi ha dades disgregades.
Aquest repositori central de dades garanteix que, com que la informació és en un

sol punt, en qualsevol moment es pugui obtenir una imatge de l’estat en què es
troba l’empresa. Això elimina la possibilitat de creació d’“illes informàtiques”.
També es minimitza l’intercanvi d’informació entre departaments i la possibili-

tat que algú treballi amb dades desactualitzades ja que la informació és la mateixa
per a tothom.
Mòduls
Els mòduls són un conjunt d’aplicacions que es poden integrar per formar el
sistema de programari. És bastant habitual que cadascun d’aquests mòduls
coincideixi amb les unitats funcionals de l’empresa (compres, vendes, inventari,
finances...).
Per tant, un dels grans avantatges dels ERP respecte als altres sistemes és que amb
un sol programa s’integra tota la gestió de l’empresa. Això porta avantatges
associats:
• El temps d’aprenentatge es redueix ja que no cal aprendre com funcionen

diferents entorns, perquè és el mateix en tots els programes.
• El sistema es pot adaptar a les necessitats de cada moment de l’empresa,

afegint nous mòduls per fer noves tasques o canviant la manera en què
funcionen els mòduls instal·lats.
Tots els mòduls comparteixen la informació que van generant amb els altres
mòduls de manera que en qualsevol punt es pot obtenir informació fiable i veraç.
Inconvenients
No tot són avantatges en els ERP; també tenen alguns inconvenients, com ara:
• La implantació sol ser complexa ja que cal que hi intervingui i s’hi impli-
qui tota la empresa. Hi ha nombrosos exemples d’implantacions d’ERP que
han fallat perquè no s’ha implicat tota la empresa en la implantació o per
resistències al canvi d’alguns departaments.
• És bastant habitual que la implantació de l’ERP comporti que s’hagi de

canviar la manera de funcionar d’algun procés de l’empresa per adaptar-
lo a la manera de fer-ho de l’ERP, o bé que s’hagi de reprogramar algun
mòdul per adaptar-se al funcionament l’empresa. Tot això fa que les
fases de desenvolupament i prova dels canvis que s’han dut a terme siguin
més importants, i que per tant el temps d’implantació encara sigui llarg.
Normalment el temps
d’implantació d’un ERP en
una empresa supera l’any.
Però hi ha altres factors que poden fer que el temps d’implantació sigui més llarg,
com ara:
• Problemes en la integració de les dades existents en el nou sistema.
• Resistència d’alguns departaments al canvi.
• Problemes d’aprenentatge de les noves eines per part dels treballadors.

Un altre problema que s’ha de tenir en compte és que es passa a dependre d’un sol
proveïdor de programari, i això converteix l’empresa en dependent del proveïdor
i del seus costos de llicències i de manteniment, que sovint són importants.
Per tant, els ERP ofereixen molts avantatges però no són recomanables per a
empreses que canviïn sovint o que siguin molt descentralitzades.
Tipus d’ERP
Mentre inicialment els ERP estaven pensats per funcionar en qualsevol empresa,
independentment del sector en què treballaven, actualment es concentren més a
adaptar-se per cobrir les necessitats de les petites i mitjanes empreses. D’aquesta
manera han anat apareixent ERP destinats específicament a determinats sectors
empresarials.
Es podria fer una classificació dels ERP des d’un punt de vista de les empreses a
què van dirigits en:
• ERP horitzontals: aplicacions pensades per poder funcionar en qualsevol

empresa.
• ERP verticals: aplicacions pensades per treballar en una activitat concreta.
ERP verticals
Un ERP vertical és una solució amb totes les funcionalitats estàndard com control
de magatzem, compres, vendes o finances, però a més s’hi afegeixen les necessitats
concretes d’un sector determinat i s’hi adapten.
Un dels motius pels quals els ERP horitzontals tenen un temps d’implantació tan
gran és perquè resolen molt bé tot el que és generalista però no solen resoldre gaire
bé aquelles parts que són més específiques d’un sector industrial en concret. És
en aquest punt que els ERP verticals prenen força ja que, com que són adaptats
per desenvolupadors amb coneixements sobre l’entorn i el negoci, el temps
d’implantació es redueix considerablement.
En el cas dels ERP horitzontals, és corrent que el cost d’adaptació del programa
sigui fins i tot superior al cost de les llicències, ja que calen moltes hores
d’adaptació per aconseguir la integració amb l’empresa. En canvi, en el cas dels
verticals, l’adaptació requereix pocs canvis i per tant el resultat final també té
un cost inferior.
Tot i això, els ERP verticals tenen més tendència que els horitzontals a fer que
sigui l’empresa la que s’hagi d’adaptar a l’ERP i no al revés; això acostuma a
ser degut al fet que fa les coses d’una manera diferent de com es fan en l’empresa,
i portar a terme un canvi en l’àmbit de desenvolupament eliminaria l’avantatge de
tenir un ERP vertical.
Principals programes d’ERP
No hi ha cap ERP perfecte i tots tenen punts forts i punts febles, i per tant un dels
aspectes fonamentals perquè la implantació d’un ERP tingui èxit en una empresa
és triar-lo adequadament.
Hi ha diversos productes ERP disponibles en el mercat, entre els quals destaquen

els oferts per les tres grans empreses desenvolupadores d’ERP: SAP AG, Oracle
i Microsoft. Però hi ha moltes més solucions, com les que integren les empreses
Sage (molt populars pels productes Contaplus o Facturaplus), Epicor, IFS o Ross
(figura 1.6).
F ig ur a 1 . 6 . Distribució dels ERP en el mercat l’any 2011 segons

Panorama Consulting Group
Els ERP més populars són:
• SAP R/3.
• Oracle e-Bussines Suite.
• Oracle JD Edwards.
• Oracle Peoplesoft.
• Microsoft Dynamics.
• Epicor ERP.
• Sage.
• Infor ERP.
• Lawson M3 ERP.
Codi obert
També en el món del programari lliure s’hi pot trobar programari ERP, els
fabricants del qual sovint aconsegueixen els ingressos per mitjà de l’oferta de
serveis als clients.
Entre els programes ERP de codi obert destaquen:

• OpenBravo.
• OpenERP.
• Compiere.
• ADempière.
• Opentaps.
El codi obert ofereix unes característiques extres que sempre s’han de tenir en
compte a l’hora de valorar si cal implantar aquestes solucions o no:
• L’avantatge més clar és el preu. Els ERP de codi obert es poden

aconseguir sense cap mena de cost i per tant es redueixen els costos
d’implementació i les llicències d’usuari.
• No crea cap dependència d’un proveïdor informàtic ja que el programari

passa a ser controlat per l’empresa i es pot fer servir per crear un ERP propi
amb molts menys recursos dels necessaris en un sistema de pagament.
• Com que disposa del codi les possibilitats d’adaptació del programa a
les necessitats de l’empresa són màximes. Les solucions de pagament
generalment permeten personalitzar els mòduls però sempre dins d’uns
límits. En el cas dels sistemes de codi obert aquests límits no existeixen.
Però el programari lliure no és exempt de problemes, la qual cosa fa que moltes

empreses no s’atreveixin a fer-los servir:
• No sempre hi ha prou documentació del funcionament dels programes.

Això pot incrementar el temps d’aprenentatge.
• Les actualitzacions del programari solen ser imprevisibles i no sempre

es documenten els canvis que es fan.
• Els projectes a vegades desapareixen. La desaparició d’un projecte

normalment acaba obligant a canviar de producte.
• A pesar que gairebé tots ofereixen el producte lliure però amb una versió
de pagament on s’inclou suport, en alguns casos el suport no sol ser tan
important com el que s’ofereix en el cas del programari propietari.
Els ERP de codi obert són una alternativa totalment vàlida i que s’ha de valorar a
l’hora de triar quin és l’ERP que s’adapta més a les necessitats de l’empresa, però
sempre tenint en compte les fortaleses i les debilitats que té.
Informàtica en núvol
La majoria d’aquests ERP s’estan adaptant o ja s’han adaptat per poder funcionar
en el que es coneix com a informàtica en núvol o més concretament com a SaaS
(software as a service).
La idea és no haver de fer cap mena d’instal·lació de programari en els servidors de

l’empresa sinó accedir al programa per Internet, normalment amb un navegador
web. Això permet que les tasques d’instal·lació i manteniment s’externalitzin, ja
que és el proveïdor el que se n’encarregarà (figura 1.7).
F igur a 1 . 7 . ERP en núvol
Aquesta característica permet:
• Fer servir el programa sense haver d’instal·lar cap programari, ja que

aquest programari està instal·lat en els servidors del venedor.
• Que no sigui necessari per a l’empresa fer cap mena de despesa en

infraestructura de maquinari (no cal comprar un servidor, implementar
mecanismes de còpia de seguretat...) ni en personal informàtic qualificat.
N’hi ha prou amb un ordinador i una connexió a Internet per poder treballar
amb l’ERP.
Generalment el cost d’aquest tipus de serveis es paga via subscripció, la qual

cosa implica un preu molt inferior al que es demana per comprar el paquet de
programari i el lloguer dels tècnics responsables de la instal·lació.
Funcionar d’aquesta manera garanteix que el programari sempre està actualit-

zat ja que l’empresa desenvolupadora s’encarrega de fer-ho en els seus propis
servidors. No cal que l’empresa prengui riscos ni tingui despeses extres fent
actualitzacions en els seus servidors.
Però sempre s’ha de tenir en compte que treballar d’aquesta manera implica uns
riscos:
• Requereix que hi hagi una connexió permanent a Internet i per tant fa

més dependent l’empresa de la companyia de telefonia.
• Una fallada en els servidors de l’empresa allotjadora pot provocar

que s’aturi completament el funcionament de l’empresa ja que no es pot
accedir al programa que ho gestiona tot.
• Com que les dades estan emmagatzemades en un lloc remot, en cas de

problemes no és possible recuperar-les.
A més, l’ús de serveis en núvol pot comportar problemes legals ja que les dades
deixen d’estar emmagatzemades en l’empresa per passar a estar-ho en els servidors
del proveïdor, i a vegades aquests proveïdors no són en el mateix país en què
treballa l’empresa.
Per tant es pot infringir la llei de Protecció de Dades de Caracter Personal (LOPD)
a causa de les limitacions imposades en l’ubicació d’emmagatzematge ja que entre
les dades amb les que treballa l’empresa n’hi sol haver de caràcter personal.
La LOPD defineix entre altres coses en quins casos es pot permetre a un

tercer accedir a les dades d’una organització o quines condicions s’han de
complir per moure les dades d’un país a un altre.
Això obliga, abans de contractar un servei en núvol, a assegurar-se que l’empresa

proveïdora del servei garanteixi que les dades que seran emmagatzemades en els
seus servidors es desaran sense infringir la llei.
1.2.5 Implantació d’un ERP
Els ERP són programes complexos d’implantar i no és rar que la implantació

en una empresa pugui esdevenir un fracàs. Des d’un punt de vista empresarial
un fracàs pot passar perquè calgui molt més temps o diners del que s’havia previst
per implantar una determinada solució, perquè aquesta solució no funcioni com
ho hauria de fer, que no es faci servir perquè és massa complicada o perquè no hi
hagi confiança en les dades obtingudes.
En el mercat hi ha centenars d’ERP amb característiques i preus diferents. És

bàsic que abans de triar un ERP es tingui clar com és l’empresa i quines són
les seves necessitats concretes. La tria adequada de l’ERP és un dels factors
determinants perquè tingui èxit la implantació. Els ERP són programes molt
específics, i que un ERP tingui èxit en una empresa no és garantia que tingui èxit
en una altra, encara que les dues siguin semblants.
Els ERP no són un tipus de programari que es compra i s’instal·la i comença

a funcionar sinó que requereix que sigui adaptat per usar-lo en l’empresa.
Sempre cal un temps de parametrització i modificació dels ERP abans de poder
fer-los servir. No n’hi sol haver prou amb instal·lar el programari, sinó que cal una
fase per fer totes les adaptacions necessàries per poder engegar el sistema.
És rar que no s’hagi de modificar res en un ERP. Normalment sempre hi ha algun

aspecte del funcionament que va més bé si es canvia, o que s’ha de canviar per
força. Per exemple, les llistes de resultats normalment solen ser molt genèriques
perquè es confia que es modificaran en la fase d’implantació.
Amb la implantació d’un ERP generalment el que es busca és optimitzar els

processos de l’empresa i en aquest sentit és fàcil que també s’hagi de canviar algun
dels processos actuals de l’empresa o bé hagi de desaparèixer. Per aquest motiu
un dels factors clau en l’èxit de la implantació és que s’hi impliquin totes les
àrees del negoci. La resistència dels usuaris acostumats a treballar d’una manera
a canviar-la és un altre factor determinant perquè no hi hagi èxit en la implantació.
El temps d’adaptació varia segons diferents aspectes però generalment hi

influeix sobretot quin ERP s’ha triat, quins són els mòduls que s’han d’implantar i
la mida de l’empresa on s’implanta l’ERP. L’allargament del temps d’implantació
sovint és un altre dels factors pels quals fallen les implantacions de l’ERP.
Un altre factor que sovint provoca molts problemes en la implantació d’un ERP és
el traspàs de dades. Les empreses ja solen tenir molts programes i molt diversos
per portar la gestió i generalment es requereix que es puguin connectar amb l’ERP
i això a vegades és una tasca molt complexa.
Un factor que s’ha de tenir en compte és que no cal que l’ERP sigui implementat
tot de cop ja que la naturalesa modular que té fa que es pugui implementar mòdul
a mòdul, i generalment seguir aquesta estratègia sol tenir més garanties d’èxit.
Per fer l’adaptació normalment s’ha de recórrer a una empresa integradora que
ajuda en la implementació de l’ERP i ajuda a l’empresa en els aspectes del negoci
relacionats amb el canvi: maquinari, programari o procés de canvi. La tria d’una
bona empresa integradora també és un factor determinant en l’èxit o la fallada
de la implantació. La seva experiència i capacitat d’entendre l’empresa i d’adaptar
adequadament l’eina és un altre factor determinant.
1.3 Funcionament d’un ERP
Per veure amb més detall què ofereixen i com treballen els ERP el que va més bé
és provar-ne un. Per provar-los, n’hi ha molts que permeten de manera gratuïta als
possibles clients usar el seu ERP en línia o baixar-ne una versió de prova per a un
temps limitat (figura 1.8).
Fi g ura 1 .8. Microsoft permet baixar Dynamics en una versió de prova
Els ERP de codi obert no solen tenir cap restricció i es poden fer servir sense haver
de pagar, a menys que es vulgui contractar suport.
Per veure com funciona un ERP heu de fer servir l’OpenERP 6.0
(http://www.openerp.org), un ERP de codi obert.
1.3.1 OpenERP
Es tracta d’un sistema ERP de codi obert multiplataforma desenvolupat en

llenguatge Python.
OpenERP s’ofereix en tres versions:
• OpenERP Community: versió gratuïta sense suport, pensada per a entorns

no professionals.
• OpenERP Enterprise: afegeix suport, solució d’errors, migració i la

possibilitat de fer servir mòduls privats.
• OpenERP Online: versió del programa accessible per Internet. El progra-

ma està allotjat en els servidors d’OpenERP.
De cadascuna d’aquestes versions sempre se’n manté una versió estable i una
de desenvolupament. Generalment les noves funcions s’integren en la versió de
desenvolupament però són més propenses a tenir errors.
En entorns de producció només es recomanen les versions estables. Actualment

es mantenen les versions 5 i 6.
Arquitectura
Les dades en OpenERP s’emmagatzemen en bases de dades en el servidor de

base de dades de codi obert PostgreSQL, que emmagatzema tant les dades com
la configuració del programa.
F igu ra 1 .9 . Esquema simplificat d’OpenERP
El programa servidor està desenvolupat específicament i és el que permet la

integració dels mòduls i s’encarrega de controlar el funcionament. Integra un
servidor web per permetre connexions mitjançant navegadors.
El servidor permet connexions de dues maneres bàsiques que es poden fer servir
indistintament: per mitjà d’un navegador web amb Flash o bé d’un client basat
en les biblioteques GTK. Tots dos sistemes ofereixen més o menys les mateixes
característiques (figura 1.9).
Però també ofereixen interfícies de comunicació mitjançant els protocols SOAP i

XML-RPC de manera que qualsevol pot desenvolupar una aplicació per comunicar
amb el servidor.
Mòduls OpenERP
OpenERP disposa de diferents mòduls de negoci públics que es poden afegir i
treure del sistema i que cobreixen la majoria dels aspectes de gestió d’una empresa:
• Compres.
• Fabricació.
• Gestió de magatzems.
• Gestió de projectes.
• Comptabilitat.
• Recursos humans.
• Màrqueting.
• CRM (gestió de la relació amb els clients o customer relationship manage-

ment).
També disposa de mòduls per funcionar com a ERP vertical en sectors específics
com gestió d’hotels i biblioteques.
No tots els mòduls són gratuïts, ja que OpenERP permet una manera curiosa de
desenvolupar mòduls. Un desenvolupador pot crear un mòdul concret i aquest
mòdul inicialment només és disponible per a qui en pagui una determinada
quantitat (inferior al cost del mòdul). La contrapartida està en el fet que en el
moment en què el desenvolupador ha cobrat la quantitat total estipulada el mòdul
passa a ser lliure i de codi obert.
Instal·lació
La versió Community es pot descarregar des del lloc web d’OpenERP

(www.openerp.com), com es mostra a la figura 1.10.
Fig u ra 1 . 1 0 . Baixar OpenERP
La instal·lació es pot dur a terme instal·lant els components separadament o bé -en

sistemes Windows- instal·lant el paquet que conté tots els components.
• Versió all-in-one: conté tant el programa servidor com la base de dades. A

més, instal·la els servidors com a serveis i els inicia.
• Components separadament: normalment es recomana fer servir els com-

ponents separadament si no interessa algun dels entorns o bé si es vol
instal·lar una versió de PostgreSQL més nova que la que hi ha en el paquet
all-in-one.
Per veure com funciona el procediment d’instal·lació fem servir la versió all-in-
one de Windows, que no difereix gaire de la instal·lació habitual en aquest sistema
operatiu (figura 1.11).
F i g ura 1 . 1 1 . L’instal·lador segueix el sistema habitual en

Windows
Durant el procés d’instal·lació la part que requereix més atenció és la que permet
definir l’usuari i la contrasenya de l’administrador de la base de dades PostgreSQL
(figura 1.12).
Fig ur a 1 . 1 2. Definir l’administrador de la base de dades
L’instal·lador no crea automàticament cap base de dades, de manera que un cop

s’ha instal·lat el progama cal crear una base de dades per emmagatzemar les dades
de l’empresa. Per fer-ho cal obrir un dels clients OpenERP per connectar amb el
servidor.
En l’exemple s’obre el client GTK, que informa que falta la base de dades (figura
1.13).
F igur a 1. 13 . Client GTK d’OpenERP
De la mateixa manera ho fa el client web (figura 1.14).
Fi g ura 1 .14 . Client web d’OpenERP

Tots dos clients, a més de donar l’error, ofereixen alguna manera de crear la base
de dades automàticament. La creació de la base de dades es pot dividir en dos
grans aspectes:
1. Crear l’estructura de la base de dades.
2. Definir l’usuari administrador de l’ERP.
Vegeu-ho en la figura 1.15.
F igu ra 1 .1 5 . Crear la base de dades en OpenERP
Un cop creada la base de dades s’ofereix la possibilitat d’obrir un auxiliar que

permet triar i configurar els mòduls que fan falta en l’empresa (figura 1.16).
Fig u ra 1 . 1 6 . Auxiliar de configuració
Quan es fa servir l’auxiliar, primer es demanen les dades bàsiques de l’empresa.

Posteriorment, un cop s’ha engegat el sistema, es poden modificar o afegir dades
noves (figura 1.17).
F igur a 1 . 1 7. Definir les dades de l’empresa en OpenERP
L’auxiliar continua demanant els mòduls bàsics que es volen instal·lar (figura
1.18).
F ig ur a 1 . 1 8. Triar els mòduls que s’han d’instal·lar
Segons els mòduls triats, surten diverses pantalles que demanen les dades per
configurar-los. Per exemple, els mòduls de facturació i comptabilitat demanen
dades sobre quin sistema comptable farà servir l’empresa (figura 1.19).
F ig ur a 1 . 1 9. Definir l’IVA
I finalment es veu la pantalla del client un cop configurat (figura 1.20).

Fig u ra 1 . 2 0 . Pantalla inicial d’OpenERP configurat en GTK
Independentment de quin sigui el client que s’ha fet servir per fer la configuració
es pot entrar en el sistema indistintament, tant amb el client GTK com amb el
client web (figura 1.21).
Fig u ra 1 . 2 1 . Pantalla inicial d’OpenERP en el client web
Característiques
És difícil resumir en poc espai les característiques de cap ERP però se’n poden fer
ressaltar algunes, relatives a:
• Interfície.
• Automatització de processos.
• Gestió d’usuaris.
• Generació d’estadístiques.
• Dades externes.
Interfície
La interfície del programa client, tant el GTK com el web, tenen sempre un aspecte
similar per a totes les funcions. La idea és que tenir un aspecte comú minimitza
el temps necessari per a l’aprenentatge dels usuaris. Comparant la figura 1.22 i la
figura 1.23 es veu la semblança entre dues pantalles d’OpenERP:
Fi g ura 1 .22 . Llista de clients i de comandes en la interfície web
Fi gura 1 .23 . Llista de clients i de comandes en la interfície web
La base del programa són els formularis, que són la forma estàndard d’entrada de
dades (figura 1.24).
Fig u ra 1 . 2 4 . Formularis d’entrada de dades en l’entorn GTK
OpenERP incorpora eines per adaptar els formularis a les característiques concre-
tes de l’empresa. Es pot eliminar, reordenar o afegir camps en qualsevol formulari
(figura 1.25).
Fig u ra 1 . 2 5 . Adaptar un formulari
Davant dels camps de dades que es poden emplenar mitjançant dades de la base de
dades normalment hi apareix el símbol de la lupa, que permet fer recerques dins
de les dades (figura 1.26).
Fi gura 1 .26 . Clicar a la lupa permet triar els valors d’una llista
Automatització de processos
Un dels objectius bàsics d’un ERP és automatitzar els processos tant com sigui
possible. Els processos automatitzats permeten definir quina és la resposta que
s’ha de donar davant de determinades situacions.
Per exemple, es pot automatitzar que, si un article està per sota d’un determinat
estoc mínim, es creï automàticament una comanda al proveïdor (figura 1.27).
Fi g ura 1 .27 . Definir l’estoc mínim d’un article en l’entorn web
Gestió d’usuaris
El sistema conté un complet sistema de gestió d’usuaris que permet controlar
totalment els usuaris del sistema (figura 1.28).
Fi g ura 1 .28 . Llista d’usuaris

Es poden definir les característiques específiques sobre cadascun dels usuaris

(figura 1.29).
Fig u ra 1 . 2 9 . Control d’usuaris en OpenERP
Es poden personalitzar fins al mínim detall quines són les coses que els usuaris
poden fer o no poden fer. Per facilitar aquesta gestió es poden crear grups d’usuaris
que reben els mateixos privilegis (figura 1.30).
Fig u ra 1 . 3 0 . Personalitzar els permisos d’usuaris
Fig u ra 1 . 3 1 . Resum de vendes en la interfície web

Generació d’estadístiques
La interfície web ofereix una sèrie d’avantatges sobre la interfície GTK ja que
incorpora gràfics i estadístiques de resum dels moviments dels mòduls de manera
que amb un cop d’ull es pot tenir una idea de quina és la tendència (figura 1.31).
Dades externes
Es poden exportar els resultats a diferents formats com PDF, HTML i els propis
de programes d’ofimàtica (figura 1.32).
Fi g ura 1 .32 . Exportar una factura a PDF
Aquest programa ofereix un component d’informes avançats que permet integrar

els diferents informes en Openoffice.org. Instal·lant un component tant en
OpenERP com en OpenOffice.org s’aconsegueix que els informes que es generin
puguin passar al programa ofimàtic (figura 1.33).
Fi g ura 1 .3 3 . L’auxiliar permet generar els informes per modificar-los o usar-los

mitjançant plantilles d’Openoffice.org
També permet sincronitzar les dades amb les que s’obtinguin en plataformes de
botigues electròniques o portals web com OsCommerce, eZPublish, Magento i
Joomla, de manera que aquestes plataformes es puguin aprofitar dels sistemes de
control de facturació i entrega d’OpenERP.
1.4 Tendències
Els ERP, com qualsevol tipus de programari, estan evolucionant i oferint noves
possibilitats que fins ara no oferien.
És difícil dir com seran els ERP dels propers anys però sembla que les tendències
van cap a oferir interfícies d’usuari altament personalitzables que es puguin
usar en diferents dispositius, i permetin integrar eines d’ofimàtica i missatgeria
electrònica i tasques col·laboratives.
La majoria dels ERP ja estan muntats basant-se en arquitectures orientades a

serveis (SOA), que permeten que el programari pugui interactuar per fer tasques
automàtiques sense que calgui intervenció humana. Una part important de
l’arquitectura SOA, els serveis web (web services), facilita les interaccions entre
els que ofereixen un servei i els que el consumeixen, de manera que permeten fer
Mineria de dades
servir les funcions globals de negoci des de programes autònoms.
Es tracta d’una tecnologia
pensada per descobrir La tendència cap als serveis en núvol sembla que ja és imparable; en aquest cas,
informació desconeguda a partir
de les dades que ja té l’empresa es basa a permetre que les empreses puguin fer servir el seu ERP des de qualsevol
fent servir tècniques diverses
relacionades amb la lloc amb una simple connexió a Internet. Les tecnologies en núvol permeten que
intel·ligència artificial.
els usuaris es despreocupin de les actualitzacions i que puguin fer servir llicències
de mòduls flexibles (pagar segons les necessitats del moment).
També hi ha una tendència que cada vegada es facin servir nous mòduls que
s’aprofitin de l’increment de la interoperativitat que ofereixen les arquitectures
orientades a serveis (SOA) per oferir mòduls de simulació d’escenaris (pensats
per preveure “què passaria si...” però amb la possibilitat d’obtenir automàticament
dades externes a l’empresa) o per fer tasques que no s’estaven duent a terme com
poden ser la mineria de dades (data mining).
2. Serveis web
Si Internet ha tingut l’èxit que ha tingut ha estat gràcies a la creació de la World

Wide Web. Però quan es va crear la web durant els anys vuitanta, la idea de manera
com havien de ser les pàgines era molt diferent de l’actual. En el moment en què
es van crear aquestes pàgines, estaven pensades només per mostrar informació
estàtica. Per aquest motiu es va implementar un sistema senzill basat en dos
protocols simples: HTTP i HTML.
El llenguatge de marques HTML és l’encarregat d’especificar de quina manera

s’han de representar les pàgines.
HTTP és un protocol simple basat en ordres simples (GET, POST, PUT, HEAD,
DELETE) que permeten recuperar un recurs mitjançant una simple petició. El
protocol pot ser tan simple perquè el resultat és representat en local pel navegador.
Un client des d’un navegador demana un arxiu i el servidor simplement l’envia
(figura 2.1).
Fi gura 2 .1. Esquema de funcionament de la web
Un aspecte clau d’aquestes pàgines és que un cop representada la pàgina és l’usuari

el que se l’ha de mirar i interpretar el contingut.
L’èxit d’Internet va començar a fer que la gent cada vegada demanés més de les
pàgines web, que van començar a permetre la interacció amb els usuaris mitjançant
el que s’anomenen pàgines web dinàmiques. La idea és que, en comptes de
limitar-se a enviar un fitxer des del servidor web, es generi la pàgina segons la
informació enviada per l’usuari.
Com que la tasca es fa en el servidor això no afecta gens cap dels protocols bàsics.
El fet que la pàgina es generi per encàrrec no canvia gens el fet que en realitat es
continuï enviant amb el protocol HTTP un arxiu HTML (figura 2.2).
Fig u ra 2 . 2 . Web amb pàgines dinàmiques
Si ens ho mirem bé veurem que en realitat el que estan fent les pàgines web
dinàmiques és oferir un servei. Es pot entrar en un cercador qualsevol o en una
botiga d’Internet i escriure-hi una paraula i això generarà una llista de resultats. El
web fa el servei de cercar i presentar els resultats i evita que sigui l’usuari qui ho
hagi de fer.
Així, doncs, el web és un lloc ple de dades (com preus, articles, horaris de trens o
imatges) i de serveis (com cercadors, jocs o botigues) que han estat causa de l’èxit
d’Internet.
El problema del web actual està en el fet que la majoria de les pàgines que
conté comparteixen una idea comuna: estan pensades perquè sigui una
persona la que s’encarregui d’interpretar-ne el contingut.
Per a un programa la informació de les webs és realment complicada d’interpretar

ja que els que han creat les pàgines les han creades pensant de quina manera es
poden representar les dades, i no que aquestes dades s’hagin de processar.
2.1 La web programable
El que es coneix com la web programable és el mateix que la web normal

però pensada per ser interpretada per programes.
En comptes d’estar basada en HTML està basada en documents de marques que

puguin ser processats fàcilment per determinats programes (XML, JSON...) i, per
tant, que serveixin perquè els programes puguin fer tasques automatitzades a partir
de la informació que han recollit.
La idea és aconseguir que un programa d’ordinador, a partir d’una informació

inicial -per exemple que es vol anar a “la platja a Roses”-, s’encarregui automà-
ticament de comprovar quin dia farà, de contractar el bitllet d’autobús i reservar
una taula per dinar en un restaurant. I tot sense que calgui intervenció de l’usuari
(figura 2.3).
Fi g ura 2 .3. Contractar un viatge a Roses amb servei web
La idea és crear una web diferent de l’actual, que algú ha anomenat la web
semàntica, que sigui comprensible per a les màquines i per als humans de manera
que els programes hi pugin fer tasques automatitzades amb el mínim d’intervenció
humana.
Els serveis web ens permeten crear programes amb components distribuïts que
no tinguin cap problema per ser executats en qualsevol tipus de plataformes
o de sistemes operatius. Això ho aconsegueixen basant-se fonamentalment en
protocols estàndard i oberts.
2.2 Els serveis web
Microsoft va definir el terme servei web (Web services) l’any 2000 per descriure
un conjunt d’estàndards que permetien als ordinadors comunicar-se per una xarxa.
El nom prové d’aquí:
• Web va sorgir perquè, tot i que tal com estan especificats aquests serveis no
tenen cap problema per funcionar amb altres protocols, la comunicació es
fa sobretot mitjançant el protocol HTTP.
• La idea que hi ha al darrere de servei és que es pugui aconseguir que el

sistema remot faci una tasca de manera que no calgui que aquesta tasca es
faci en el sistema local.
Un servei web és un programari que ofereix una interfície per fer una tasca,
que pot ser usat per altres sistemes independentment de quina plataforma i
llenguatge faci servir.
Fent servir un llenguatge més proper als programadors també es podria definir
un servei web com un mètode disponible remotament mitjançant una xarxa,
mitjançant un protocol particular que normalment és l’HTTP.
Com que es vol que el sistema sigui multiplataforma cal que tots els sistemes
entenguin i puguin interpretar correctament les dades que s’hi transmeten. Per
aquest motiu el més corrent és que es faci servir un llenguatge de marques (XML,
JSON...) per passar les dades d’un extrem a l’altre de la comunicació.
2.2.1 Característiques dels serveis web
Hi ha unes característiques que distingeixen els serveis web dels altres sistemes
distribuïts:
• Fan servir una infraestructura oberta.
• Són interoperables.
• Fan servir un disseny modular.
O sigui que es desenvolupen fent servir estàndards públics que siguin inde-
pendents del fabricant (com per exemple amb els protocols HTTP o XML) de
manera que s’afavoreix que s’hi pugui accedir des de pràcticament tots els sistemes
i plataformes.
La interoperativitat garanteix que no importi en quin llenguatge de programació

estiguin desenvolupats (C, C#, Java, Python, Perl...) ni tampoc des de quina
plataforma es treballi (Windows, Linux...) ja que si poden interpretar les dades
(i com que estan en un estàndard públic ho faran) poden operar entre si sense
problemes.
El disseny modular és un altre aspecte clau, ja que permet que els serveis web es
pugin integrar amb altres serveis per formar-ne de més grans i complexos, de
manera que permet crear serveis complexos a partir de components més senzills i a
més sense que sigui important en quines plataformes s’estiguin executant cadascun
dels components.
La modularitat dels serveis Un programa pot ser descomposat en tasques més senzilles, algunes de les quals
web és un dels factors
bàsics a l’hora de definir el també les fan altres programes. Si es parteix d’un disseny modular es pot aprofitar
que s’ha anomenat
arquitectura basada en el codi que executen aquests serveis per no haver de reprogramar-los una vegada i
serveis (SOA).
una altra.
Els serveis que s’ofereixen en els serveis web són diferents dels tradicionals a
Internet, que principalment es basaven en el contingut, ja que en aquests serveis
el que es genera són dades que poden ser usades per uns determinats programes
per dur a terme tasques.
2.2.2 Tipus de serveis web
Segons el W3C hi ha dos grans tipus de serveis web: “[E]ls que són compatibles
amb REST, que tenen com a objectiu principal manipular representacions XML
de recursos fent servir un conjunt uniforme d’operacions sense estat; i els arbi-
traris, en què el servei exposa un conjunt arbitrari d’operacions.” De manera que
tenim dos grans grups de serveis web:
• Big Web services: serveis que exposen operacions perquè les facin servir
els servidors. Estan basats en el protocol SOAP.
• Web API: serveis basats en l’arquitectura REST -que basa el seu funciona-
ment en els recursos-.
2.3 Big Web services
Els coneguts com a big Web services són serveis web que envien i reben la
informació empaquetada en un format XML anomenat SOAP. Es poden definir a
partir de tres funcions, tot i que no totes són estrictament necessàries per treballar:
• Una manera de definir i transmetre els missatges.
• Un llenguatge de definició de la manera com es poden fer servir els serveis.
• Un sistema de descobriment de serveis.
2.3.1 Funcionament
Els big Web services es basen molt en XML, ja que fer servir aquest llenguatge
en sistemes distribuïts aporta alguns avantatges amb els quals no es comptava
anteriorment:
• Es poden comunicar dos sistemes totalment diferents ja que XML garanteix

la portabilitat. Com que les dades que s’envien són XML cap sistema no té
problemes per entendre’n la informació.
• En definir el que es vol fer i les respostes en SOAP no importa quin és el

protocol de transport que es faci servir sinó la informació continguda en les
dades XML.
• Es poden definir els tipus de dades fent servir XSD (XML Schemas Defini-
tion) per definir les dades que s’han de passar entre sistemes. Això permet
que es puguin fer comprovacions de tipus, que els programes sàpiguen quins
tipus de dades han d’enviar o han de rebre...
• Es poden expandir les possibilitats del protocol fent servir els espais de
noms. Com qualsevol altre document XML es poden expandir les capacitats
d’aquests protocols per afegir-hi funcionalitats mitjançant els espais de
noms.
Format dels missatges
Per definir el format dels missatges que es transmeten es fa servir el protocol

SOAP, que està basat en XML.
Per transportar aquests missatges se sol fer servir HTTP (protocol de transfe-
rència d’hipertext o hypertext transfer protocol) tot i que es poden fer servir altres
protocols de transport com els de correu electrònic, FTP (protocol de transferència
de fitxers o file transfer protocol) o BEEP (blocks extensible exchange protocol).
Definició del servei
Per poder fer servir un servei web que no s’ha fet servir mai i que fins i tot pot
haver estat descobert automàticament és molt important disposar d’una manera
de conèixer quins serveis ofereix i com s’ha de fer per usar-los.
La manera que tenen aquests serveis web de definir com s’ha de fer per poder
usar el servei i quin serveis s’ofereixen és mitjançant un altre protocol anomenat
WSDL (Web services description language), que també està basat en XML.
Descobriment de serveis
Si es pretén que els programes funcionin sols cal que tinguin alguna manera de
poder descobrir serveis que no coneixien anteriorment de manera automàtica.
Es va definir UDDI (descripció, descoberta i integració universals o universal des-

cription, discovery and integration) per proporcionar la capacitat de permetre
als programes descobrir serveis web que s’adeqüin a les necessitats que tinguin.
Altres protocols
A part dels que s’anomenen protocols bàsics, els big Web services disposen d’un
grup més important de protocols per afegir noves funcions a SOAP.
Aquests protocols, el nom dels quals normalment comença per les lletres WS-,
solen ser definits per tres organitzacions d’estàndard:
• El World Wide Web Consortium (W3C).
• L’Organization for the Advancement of Structured Information Standards

(OASIS).
• La Web Services Interoperatibility Organization (WS-I).
Aquestes organitzacions han definit més de cinquanta estàndards diferents per

permetre definir qualsevol aspecte que afecti els serveis web com seguretat, gestió
de serveis, gestió d’errors, o confiança entre els comunicants (taula 2.1).
Taul a 2. 1. Alguns dels estàndards serveis web
Estàndard Ús
WS-Discovery Defineix un protocol per descobrir serveis en la xarxa

local.
WS-Addressing Defineix un mecanisme per transportar informació

d’adreces.
WS-Security És una extensió per afegir seguretat a SOAP.
WS-Resource És una família d’especificacions que permeten

manipular estructures de dades remotes.
WS-Reliability Permet assegurar l’enviament de missatges crítics.
WS-Policy Permet als serveis web definir les seves

característiques de seguretat, qualitat de servei...
WS-Trust Afegeix extensions de seguretat per gestionar

testimonis d’autenticació (Security-Token) i relacions
entre els participants en un intercanvi segur.
Interoperativitat
Una de les crítiques que es fan a aquest tipus de serveis web és que el fet d’haver-
hi tants estàndards definits per diferents organitzacions crea una dispersió que fa
difícil poder oferir productes que garanteixin la tan volguda interoperativitat. WS-I ara és membre
d’OASIS tot i que no ha
canviat el seu objectiu
fonamental.
Per posar ordre al desgavell, un grup d’empreses el 2002 van crear una organitza-
ció d’estàndards anomenada WS-I. Es tracta d’una organització que no té com a
objectiu definir noves versions dels protocols, sinó que se centra a definir de quina
manera es pot aconseguir desenvolupar serveis web interoperables. Per fer-ho va
definint el que anomena perfils (profiles), que són una sèrie de normes i estàndards
que s’han de fer servir per assegurar que el servei és compatible amb els altres.
Un dels perfils que defineixen i que és més usat és el WSI-BP (WSI Basic Profile)
que només fa servir els protocols més elementals: SOAP, WSDL, WS-Addressing,
UDDI. Amb el WSI-BP es limiten les possibilitats a l’hora de crear serveis web
però s’aconsegueix que aquells que el compleixin siguin interoperables amb total
seguretat. Moltes de les plataformes de generació de serveis web només creen
Web services compatibles amb WSI-BP.
2.3.2 SOAP
SOAP va ser el primer estàndard de serveis web que es va desenvolupar i

actualment és una recomanació del W3C tot i que originalment va ser desenvolupat
per un grup d’empreses. És un acrònim de simple object access protocol (protocol
d’accés d’objecte simple), però actualment aquest nom ha perdut sentit ja que ha
quedat demostrat que SOAP no és simple, i a més no té gaire a veure amb l’accés
a objectes.
Han anat sorgint diferents versions de SOAP al llarg dels anys i actualment se’n
fan servir dues, les versions 1.1 i 1.2, l’especificació de les quals es pot trobar a la
pàgina del W3C (www.w3.org/TR/soap).
És un entorn de missatges que permet la comunicació entre programes que corren

en diferents servidors amb independència del llenguatge i del sistema operatiu en
què funcionin. Un dels avantatges que aporta SOAP és que fa molt més simple la
comunicació entre sistemes que estiguin en xarxes diferents del que es podia fer
abans amb altres sistemes com CORBA o DCOM.
Aconsegueix la independència del llenguatge i de la plataforma basant els missat-

ges en XML i s’aprofita que l’èxit de la web ha fet que tots els sistemes tinguin
implementat el protocol HTTP (tot i que pot funcionar en altres protocols) per
fer-lo servir per l’intercanvi de missatges.
A més de definir el format dels missatges també defineix quines són les regles que
han de regir aquest intercanvi, què passa en cas d’error i com s’ha de lligar amb
els altres protocols.
Amb els serveis web d’aquest tipus s’exposen tota una sèrie de funcions mitjançant
les quals es poden fer programes que poden fer que el servei faci tasques
determinades i retorni resultats amb els quals es pugui treballar.
Big Web services a OpenBravo
Per exemple, en el servei de vendes externes de l’ERP OpenBravo accessibles per mitjà
de SOAP s’hi exposen les funcions següents:
• getProductsCatalog (entitat, organització, origen, usuari, contrasenya).
• uploadOrders (entitat, organització, origen, llistacomandes, usuari, contrasenya).
• getOrders (entitat, organització, usuari, contrasenya, llistacomandes).
Es pot veure que els noms són prou explicatius de quina és la funció que ofereix cadascun
dels serveis: obtenir el catàleg de productes d’una empresa, carregar comandes, i obtenir
les comandes i veure en quin estat es troben.
Per tant, no és difícil fer un programa que comuniqui amb OpenBravo i que n’obtingui
aquestes dades. Gràcies a això els clients d’OpenBravo poden desenvolupar programes
externs que interactuïn amb el sistema.
Per tant, qualsevol missatge que s’enviï cap a un servei web va dins d’un missatge
SOAP en el qual s’especifica quin és el servei que es vol fer servir i quines són les
dades que s’hi envien.
Missatges SOAP
SOAP és un entorn de missatges basat en XML i per tant necessita definir tot allò
que fa referència a la manera com s’han de gestionar els elements següents:
• Tipus de missatges.
• Format dels missatges.
• Protocols de transport.
Tipus de missatges
L’estàndard SOAP defineix dos tipus de patrons de missatges:
El més habitual, que està basat en petició i resposta, que és l’habitual en el protocol
HTTP (figura 2.4).
Fi gu ra 2 .4. Missatge SOAP de petició i resposta
I un altre tipus de només resposta, que l’estàndard anomena SOAP Response. La

idea és que el servei respongui quan rep un missatge no SOAP amb una resposta
SOAP (figura 2.5).
Fi gu ra 2 .5. Missatge SOAP de només resposta
Però els dos patrons també es poden combinar per aconseguir altres patrons, com
definir missatges només d’entrada, o fins i tot establir una conversa.
Composició dels missatges

Un missatge SOAP és bàsicament un document XML i per tant ha de complir totes
les normes de creació de documents XML. Per tant, ha de tenir un element arrel
anomenat Envelope que serveix per identificar els missatges SOAP i la versió que
es fa servir. La versió s’identifica a partir de l’espai de noms especificat. Vegeu
els espais de noms de cada versió en la taula 2.2.
Taul a 2. 2. Espais de noms de SOAP
Versió 1.1
Envelope http://schemas.xmlsoap.org/soap/envelope/
Encoding http://schemas.xmlsoap.org/soap/encoding/
Versió 1.2
Envelope http://www.w3.org/2003/05/soap-envelope
Dins de l’element arrel hi pot haver un element <Header> opcional i un <Body>,

que és el que representa el contingut del missatge.
L’estàndard no defineix cap funció per a l’element <Header> però generalment se

sol fer servir per donar informació o definir el contingut del missatge.
L’exemple següent és un missatge de petició SOAP que crida a una funció

anomenada suma de l’espai de noms privat ioc que rep dos paràmetres, in i in2.

2 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
3 xmlns:ioc="http://ioc.xtec.cat/Bencalculat/">
4 <soapenv:Header/>
5 <soapenv:Body>
6 <ioc:suma>
7 <in>8</in>
8 <in2>5</in2>
9 </ioc:suma>
10 </soapenv:Body>
11 </soapenv:Envelope>
La resposta del servei web pot ser que el servei s’ha dut a terme i ha retornat el
resultat següent:
1 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap−envelope">
2 <env:Body>
3 <ns:sumaResponse xmlns:ns="http://ioc.xtec.cat/Bencalculat/">
4 <ns:return>13</ns:return>
5 </ns:sumaResponse>
6 </env:Body>
7 </env:Envelope>
O bé un error que es defineix amb l’element <Fault>, que sempre va dins de

l’element <Body> i que representa diferents estats d’error:
1 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap−envelope">
2 <env:Body>
3 <env:Fault>
4 <env:Code>
5 <env:Value>soapenv:Receiver</soapenv:Value>
6 </env:Code>
7 <env:Reason>
8 <env:Text xml:lang="en−US">
9 For input string: "A"
10 </senv:Text>
11 </env:Reason>
12 <env:Detail/>
13 </env:Fault>
14 </env:Body>
15 </env:Envelope>
Dins de l’element <Fault> hi ha sempre un codi i un text descriptiu de l’error que

s’ha produït. És mitjançant els codis que es pot saber de quin tipus és el missatge
d’error rebut (taula 2.3).
Taul a 2. 3. Codis d’error de SOAP 1.2
Codi d’error Significat
VersionMismatch Hi ha algun element invàlid o hi ha alguna cosa que

no quadra (típic d’enviar missatges 1.1 a servidors
1.2).
MustUnderstand Un fill del Header no ha estat entès o no compleix les

regles.
DataEncodingUnknown S’ha enviat la informació en un format amb el qual no

és compatible.
Sender El missatge està format incorrectament o hi falten

coses (per exemple, hi falta la identificació de
l’usuari). En la versió 1.1 el nom era Client.
Receiver El missatge no pot ser processat perquè no s’ha

pogut processar (no existeix la funció, per exemple.).
En la versió 1.1 era Server.
Com que SOAP és XML, diem que hi ha un format de missatges que es pot
expandir mitjançant espais de noms.
Protocol de transport
Els missatges poden viatjar en qualsevol protocol però el més usat és HTTP i per
tant és el que explicarem aquí.
Per fer una petició cal enviar un missatge amb el mètode POST al servei web en què
s’identifiqui on és el servei, i en el tipus hi ha d’haver application/soap+xml o
bé text/xml.
1 POST http://ioc.xtec.cat:8080/Calculadora HTTP/1.1
2 Content−Type: application/soap+xml;charset=UTF−8;action="urn:sumar"
3
4 <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap−envelope"
5 ...
La resposta també ens donarà informació de què ha passat. Si rebem un codi 200
és que tot ha anat bé.
1 HTTP/1.1 200 OK
2 Content−Type: application/soap+xml; action="urn:sumarResponse";charset=UTF−8
3
4 <?xml version=’1.0’ encoding=’UTF−8’?>
5 <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap−envelope">
6 ...
I si hi ha algun error hem de rebre un codi 500.
1 HTTP/1.1
2 500 Internal Server Error
3 Content−Type: application/soap+xml; action="urn:sumarResponse";charset=UTF−8
4
5 <?xml version=’1.0’ encoding=’UTF−8’?>
6 <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap−envelope">
7 ...
Problemes
Una de les crítiques que es fa a SOAP és la mateixa que es fa a XML: malgrat

tenir molts avantatges té la tendència a fer-se molt gran i això fa que SOAP acabi
essent més lent que les altres tecnologies existents com CORBA o DCOM, que
fan servir missatges binaris, de manera que són molt més curts i ràpids.
Tot i que aquests problemes són certs, per molta gent els avantatges que aporta
-com la facilitat de lectura per als humans, la facilitat de detecció d’errors i el fet
que solucioni els problemes de compatibilitat entre plataformes- el fan una opció
que s’ha de tenir en compte.
2.3.3 WSDL
El WSDL (Web services definition language) és un llenguatge XML per descriure

quins serveis ofereix un servei web i com s’ha de fer per accedir-hi (figura 2.6).
Normalment l’ús d’un servei web requereix que el client obtingui abans el fitxer
WSDL per saber quin servei s’ofereix i com s’ha de fer servir.
F igu r a 2. 6 . WSDL serveix per obtenir les característiques tècniques d’un servei web
La versió 2.0 és més

senzilla que les versions 1.X
i ofereix compatibilitat amb
un nombre més gran de
característiques, però no
està totalment S’han desenvolupat diverses versions de WSDL: les originals, basades en el
implementada per als
entorns de número 1 (1.0, 1.1); i la nova versió 2.0, que és incompatible amb les versions
desenvolupament.
anteriors.
El format en que està definit el fitxer WSDL, a pesar de ser XML, està pensat per
ser llegit i interpretat per una màquina i no pas per una persona. S’hi defineixen un
ampli ventall d’aspectes: des de les adreces mitjançant les quals es pot comunicar
amb les diferents funcions del servei web, fins al format en què ha d’estar cada
tipus de dades.
El WSDL no és necessari per fer la comunicació, de manera que si ja es té

informació sobre quins serveis ofereix un servei web i de quina manera s’hi pot
accedir es pot desenvolupar un programa que faci servir el servei web sense
problemes.
A pesar d’això obtenir el WSDL abans de comunicar amb un servei web pot servir
per obtenir més informació sobre la manera com funciona el servei, i per detectar
si s’hi han produït canvis.
El fitxer WSDL
El fitxer WSDL és un document XML que té per arrel <definitions> i que fa

servir XSD per definir els tipus de dades implicades en el servei. Dins seu conté
diferents etiquetes que s’encarreguen de definir quins serveis s’ofereixen i com es
pot fer per accedir-hi.
Dins de l’element <definitions> hi podem tenir diferents elements segons si

el document correspon a la versió 1 o a la 2. Vegem una comparació entre les
versions en la figura 2.7.
F ig ur a 2. 7. Comparació entre els WSDL 1.0 i 2.0

L’element <types> es fa servir per definir amb XSD els tipus de dades que
s’empren en tots els serveis oferts. Es defineixen tots els tipus de dades, tant
paràmetres d’entrada com de sortida, tipus complexos...
L’element <portType>, o <interface> en la versió 2, defineix les operacions

que es poden fer en un servei web i els paràmetres que es fan servir per dur-
les a terme. En aquesta part d’un document WSDL veiem que el servei web
ofereix l’operació suma que rep com a paràmetres d’entrada un sumaRequest
i que retorna un sumaResponse. Tots dos tipus han d’haver estat definits en la
definició de tipus <types>, o <messages> en les versions 1.
1 ...
2 <wsdl:portType name="CalculadoraPortType">
3 <wsdl:operation name="suma">
4 <wsdl:input message="ns:sumaRequest" wsaw:Action="urn:suma"/>
5 <wsdl:output message="ns:sumaResponse" wsaw:Action="urn:sumaResponse"/>
6 </wsdl:operation>
7 </wsdl:portType>
8 ...
L’element <binding> defineix el protocol i el format en què es poden fer les

operacions.
L’element <services>, per la seva part, defineix el lloc físic on hi ha el servei

web (adreça URL) mitjançant una col·lecció de punts de connexió <binding>.
2.3.4 UDDI
El protocol UDDI (descripció, descoberta i integració universals o universal

description, discovery and integration) serveix perquè els creadors de serveis web
puguin registrar-los en una base de dades, i alhora permetre als clients localitzar
serveis web que facin allò que volen i proporcionar-los el seu WSDL (figura 2.8).
F igu r a 2. 8 . Funcionament dels serveis web amb UDDI
Des d’un punt de vista d’automatització això és l’ideal. Es pot fer que els
programes automàticament localitzin el servei que busquen sense que ni tan sols
en tinguin informació prèvia, simplement accedint al registre UDDI.
Per aquest motiu, UDDI va ser creat per donar servei a un registre anomenat UDDI
Bussiness Registry o UBR, amb el propòsit de proporcionar una manera senzilla
de localitzar serveis web basats en SOAP a Internet. La idea era crear una mena
de “pàgines grogues” que continguessin tots els serveis web de manera que es
poguessin localitzar a partir de les funcions que oferien.
Però UBR va fracassar i va tancar el 12 de gener del 2006. Era molt difícil crear
categories de serveis que tinguessin prou significat per ser útils; i també s’ha de
tenir en compte que UDDI no és necessari per poder fer servir serveis web.
A pesar d’això algunes organitzacions encara fan servir UDDI internament. Però
també és cert que altres organitzacions fan servir sistemes diferents per localitzar
serveis web: LDAP, bases de dades...
2.3.5 Provar serveis web
Per veure com funcionen els serveis web no hi ha res que vagi tan bé com provar-
ne algun. Malauradament el fracàs de crear un sistema de registre ha fet que no
sigui fàcil localitzar serveis per fer proves, i moltes de les funcions dels serveis
web es fan servir en xarxes locals. Per exemple, molts dels programes de gestió
d’empreses ERP permeten interacció mitjançant SOAP.
També hi ha algunes pàgines que contenen enllaços a serveis web públics acces-
sibles per Internet. S’ha de tenir en compte que aquests enllaços no sempre estan
totalment actualitzats i que per tant no sempre funcionen.
• Seekda (http://webservices.seekda.com/browse)
• xMethods (http://xmethods.net)
• WSIndex (http://www.wsindex.org/Web_Services/)
En aquestes pàgines web s’hi poden trobar serveis web molt diversos, com obtenir
la temperatura de diferents ciutats del món, sistemes de conversió de monedes,
informació sobre països, valors de la borsa, traduccions de textos o comprovacions
de correu electrònic.
Com que per poder fer servir un servei web el primordial és obtenir el seu WSDL
per saber com interactuar-hi, les pàgines solen mostrar un enllaç al WSDL de
cadascun dels serveis que tenen registrat (figura 2.9).
F igu r a 2. 9 . Seekda fa un resum de cada servei
Eines de prova
Per provar els big Web services sense haver de programar ni una línia tenim
diverses alternatives, atès que SOAP i WSDL no deixen de ser llenguatges XML, i
molts dels editors XML ofereixen alguna manera de depurar el funcionament dels
serveis web (figura 2.10).
F igu r a 2. 1 0 . Provar un servei web des d’oXygen XML Editor
Els editors XML normalment es limiten a permetre enviar peticions editables

i recuperar les respostes que arriben des del servei web en SOAP. A part dels
editors XML també hi ha una sèrie de programes que permeten fer tasques molt
més elaborades, com ara fer proves de rendiment o de seguretat, comprovar si el

servei compleix les regles d’interoperativitat de WS-I, o fer proves automàtiques
de rendiment. Alguns d’aquests programes són:
• SoapUI (http://www.soapui.org/)
• SOAPSonar (http://www.crosschecknet.com/)
• Parasoft SOAtest (http://www.parasoft.com/)
Els avantatges que aporten aquests programes són prou importants per tenir-los en
compte a l’hora de dissenyar serveis web SOAP professionals.
Exemple d’ús
Normalment els serveis web es fan servir des de programes desenvolupats ex-
pressament per fer una determinada tasca. Però també es poden fer servir des
de programes dissenyats específicament per provar serveis web.
Programes
El funcionament de la majoria dels programes de prova és molt similar, i tots
permeten fer més o menys les mateixes coses. En aquest exemple farem servir el
SoapUI, una aplicació desenvolupada en Java que permet provar, analitzar, simular
i generar codi de serveis web de manera senzilla i àgil a partir del fitxer WSDL, i
que conté la possibilitat d’automatitzar les proves funcionals.
El SoapUI es distribueix en dues versions: SoapUI Freeware (GNU LGPL) i

SoapUI Pro (comercial), que es poden executar en versió d’escriptori, en línia
i mitjançant connectors que permeten treballar-hi des de diferents entorns de
desenvolupament com Eclipse, IntelliJ IDEA i NetBeans (figura 2.11).
F igur a 2. 11. Entorn del SoapUI

Objectiu
Volem fer un programa que pugui mostrar als usuaris quina és la temperatura de
Barcelona.
Per fer-ho ens valem d’un servei públic i gratuït que proporciona aquesta infor-
mació. Anem a Seekda (http://webservices.seekda.com/browse) i busquem algun
dels serveis de temperatura; ens quedem amb GlobalWeather (figura 2.12).
F igu r a 2. 1 2 . GlobalWeather permet mostrar dades meteorològiques de ciutats amb aeroports
Aconseguir el WSDL
Per poder fer servir el servei web ens cal aconseguir quins són els serveis que
ofereix. Per fer-ho hi ha dues maneres:
• Que el creador del servei web proporcioni la informació.
• Aconseguir el seu fitxer WSDL.
En aquest cas, en el quadre de resum del servei ja tenim el WSDL i per tant podem
fer servir aquest sistema (figura 2.13).
F igu r a 2. 1 3 . El quadre de resum del cercador Seekda ens ofereix un enllaç al WSDL
Provar el servei
Inspeccionant el WSDL es veuen els serveis que s’ofereixen, però el SoapUI ho fa
automàticament i a més permet provar el servei.
El primer que cal fer és crear un projecte nou, en el qual s’han d’especificar
diferents opcions, entre les quals destaca el WSDL (figura 2.14).
Figur a 2. 14. Crear un projecte amb el SoapUI
Com que volem descobrir els serveis que ofereix GlobalWeather només cal que
marquem la primera de les opcions.
Quan el projecte s’hagi creat, en el costat dret hi apareixeran tots els serveis que
ofereix el servidor web i les maneres amb què s’hi pot connectar.
Com en aquest cas, és bastant habitual que els serveis web permetin que s’hi
treballi fent servir diferents versions de SOAP. En aquest servei es pot fer servir
SOAP 1.1 (GlobalWeatherSoap) i SOAP 1.2 (GlobalWeatherSoap12) (figura
2.15).
Figur a 2 . 15 . Les marques verdes indiquen diferents maneres de connectar amb el servei
El servei GlobalWeather només ofereix dues funcions:
• GetCitiesByCountry: com indica el nom, retorna una llista de les ciutats

d’un país determinat que funcioni amb el servei.
• GetWeather: proporciona la informació meteorològica d’una ciutat con-

creta.
El primer que cal fer és descobrir si Barcelona és entre les ciutats disponibles.
Desplegueu la funció GetCitiesByCountry i, si feu doble clic a “Request1”,
es crearà la plantilla d’una petició SOAP. Els valors dels paràmetres que s’han
d’emplenar estan marcats amb un interrogant (figura 2.16).
F igu r a 2. 1 6 . Els interrogants mostren on s’han de posar els paràmetres
En executar la comanda apareixerà una llista amb el resultat de l’execució del

servei en la part dreta de la finestra. Entre els resultats es veu que Barcelona és
una de les ciutats amb què funciona el servei, i per tant aquest servei web és útil
per als nostres propòsits (figura 2.17).
F igu r a 2. 1 7 . Barcelona és entre els resultats
Un cop descobert que es pot fer servir el servei per consultar les dades me-
teorològiques de Barcelona, podem provar d’obtenir la temperatura fent servir
el procediment anterior però clicant a la funció GetWeather. Aquesta funció
necessita dos paràmetres: la ciutat i el país (figura 2.18).
Figur a 2. 18. GetWeather pot tenir dos paràmetres per treballar
Si empleneu la funció amb Barcelona i Spain obtindreu els valors de temperatura,

vent, estat del cel, etc., en un format XML senzill que no costaria gaire que un
programa pogués interpretar (figura 2.19).
F ig ur a 2 . 19 . Temperatura a Barcelona
2.4 Arquitectures basades en REST
Una de les crítiques que es fan als serveis web basats en SOAP és que s’ha de
tractar amb massa protocols per aconseguir qualsevol cosa i això fa que siguin
massa complicats.
Els serveis basats en REST (representational state transfer) intenten capturar

les característiques que han fet que la web tingués èxit, i en especial la seva
senzillesa: resulta fàcil d’entendre i de fer servir. Es parteix de la idea que la
web ha revolucionat la manera d’accedir a les dades perquè és simple i fa servir
un conjunt petit de tecnologies. Però a més ha passat a ser un sistema distribuït,

obert i multiplataforma, i en moltes pàgines web es fan coses tan complexes com
en els serveis web sense fer-ho tan complicat com en els sistemes SOAP.
Mentre els big Web services exposen funcions semblants a les dels llenguatges de
programació mitjançant interfícies més o menys complexes que són diferents per
a cada servei, els serveis web basats en REST exposen les dades mitjançant una
interfície que sempre és la mateixa. Aquests serveis intenten aconseguir el mateix
èxit que ha tingut la web fent servir les mateixes armes: no es defineixen nous
protocols sinó que s’aprofiten els que ja existeixen i tenen èxit. Per què ens hem
de complicar la vida? Per què hem de crear nous protocols complexos?
REST no és un protocol sinó un conjunt de regles i principis que permeten

desenvolupar serveis web fent servir HTTP, i basant-se en el fet que la web és
plena de recursos que es poden manipular mitjançant les seves representacions.
REST obliga a fer que els missatges continguin tot el necessari per poder funcionar,
ja que es parteix del fet que no tenen estat, de manera que no poden recordar les
peticions anteriors. Això implica que el sistema ha de tractar cadascuna de les
peticions com si fos l’única, i per tant ha de tenir tot el necessari perquè el
servidor pugui fer la tasca. El servidor mai no tindrà en compte les peticions
anteriors per tractar l’actual.
Segurament el fet que REST faci servir tecnologies que ja existien -la qual cosa
permet accedir als recursos d’una manera homogènia i simplifica l’ús, ja que no cal
interpretar què fan determinades funcions ni què s’ha de posar en els paràmetres-
, ha estat clau en el fet que els serveis basats en REST s’hagin convertit en els
preferits per desenvolupar serveis web. Molts dels antics serveis basats en SOAP,
com per exemple les recerques de Google, s’han abandonat en favor d’altres
sistemes que sovint estan basats en REST.
2.4.1 Els recursos
L’accés als recursos és el component bàsic en la web, i per tant també ho és de

Actualment les idees d’URI
(identificador uniforme de REST.
recursos o uniform resource
identifier ) i URL
(localitzador uniforme de Per a REST, qualsevol cosa que es pugui identificar amb un URI o un URL dins
recursos o uniform resource
locator ) són pràcticament d’Internet es considera un recurs, i com que pràcticament tot el que hi ha dins
idèntiques i per tant es
poden usar indistintament.
d’Internet es pot identificar mitjançant un URL tenim molts recursos disponibles.
Per a REST tot és un recurs que es pot identificar i que es pot manipular. Per
exemple es pot definir un servei web que identifiqués els alumnes d’una classe a
partir d’adreces URI formades d’una manera especial.
1 http://ioc.xtec.cat/classe/programacio/alumne/*
Fent servir aquesta nomenclatura podem accedir al primer alumne de la classe

de programació de l’IOC amb http://ioc.xtec.cat/classe/programacio/alumne/1,
al segon amb http://ioc.xtec.cat/classe/programacio/alumne/2 i així successiva-

ment. Alhora podem definir la classe de programació d’una manera similar:
http://ioc.xtec.cat/classe/programacio.
Un recurs és un concepte o una idea que es pot associar a un URL o un URI,

però a més per a REST els recursos poden tenir diferents representacions
segons l’estat en què es trobin.
Vegem els conceptes gràficament en la figura 2.20.
Figur a 2. 20. Conceptes de REST
A pesar del que pot semblar, en molts dels exemples de serveis web en REST les
jerarquies d’adreces per a REST d’entrada no impliquen cap tipus de relació entre
els recursos. Això vol dir que les adreces següents no tenen per què tenir cap tipus
de relació:
1 http://ioc.xtec.cat/classe/programacio/
2 http://ioc.xtec.cat/classe
La primera podria mostrar la llista d’alumnes i la segona, informació sobre on es

fan classes en el centre i quan.
En sistemes REST les relacions reals s’estableixen mitjançant els enllaços que
tinguin les pàgines.
2.4.2 Representacions
XML no és l’únic llenguatge
de marques que es fa servir
en serveis web. Un
Per a REST no hi ha cap problema a fer servir la web per comunicar programes, llenguatge que està tenint
molt d’èxit és JSON
ja que en realitat la comunicació d’una pàgina web ja és una comunicació entre (JavaScript object notation).
programes (el servidor i el navegador). L’única cosa que no està pensada per ser
usada per programes és el contingut.
El més habitual és que els recursos de la web estiguin pensats per ser consumits
per humans mitjançant navegadors, i per aquest motiu la informació s’hi sol
representar en HTML. Si l’objectiu és permetre a les màquines fer servir la web
només cal que el contingut de les pàgines estigui en un format més amigable per
als programes, com per exemple XML.
Malgrat fer servir la web, REST no està limitat a fer servir missatges en HTML
o XML sinó que pot emprar recursos en qualsevol format. Per tant, en un servei
web basat en REST es poden generar des de documents en HTML o PDF fins a
imatges en JPG o GIF.
La idea és que no es visualitza el recurs en si sinó només una

representació d’aquest recurs. Quan algú accedeix a l’adreça
http://ioc.xtec.cat/classe/programació/alumne/23 el que està definint és que
vol obtenir l’alumne número 23 de la classe de programació, però el que obtindrà
no serà l’alumne sinó una representació d’aquest alumne que, segons el context,
pot ser una imatge, una pàgina web amb les notes de l’alumne o un fitxer XML
amb les seves dades personals.
Hi ha recursos que només tindran una sola representació i d’altres que en tindran
diverses i per aquest motiu en REST els programes poden demanar quina és la
representació que volen obtenir o els servidors poden enviar la que considerin
més adient segons un determinat criteri (per exemple, segons el programa que ha
demanat el recurs).
Gràcies a les representacions es pot aconseguir que s’uneixi de manera

transparent la web dels humans amb la dels programes.
Per exemple, és habitual que si el servidor detecta que s’hi està accedint amb un
navegador retorni una representació en HTML, mentre que si és mitjançant un
altre programa retorni la representació en XML.
2.4.3 HTTP
REST fa servir HTTP com a sistema de transport (tot i que també podria funcionar
amb altres protocols), però també el fa servir com a sistema de missatges. Per
aquest motiu s’ha de definir quin és el paper que han de tenir els diferents mètodes
HTTP a l’hora de gestionar un recurs.
S’han definit una sèrie d’equivalències entre els mètodes HTTP i la manera de
tractar el recurs especificat, que es veuen en la taula 2.4.
Taul a 2. 4. Equivalències dels mètodes HTTP en REST
Mètode Significat
POST Crear un recurs.
GET Obtenir el recurs.

Mètode Significat
PUT Actualitzar el recurs.
DELETE Eliminar el recurs.
D’aquesta manera es poden fer les operacions bàsiques simplement enviant una
petició HTTP a un URI, triant el mètode HTTP adequat. Enviant una petició
HTTP GET obtindrem la representació de l’alumne 1:
1 GET classe/programació/alumne/1
En canvi, enviant un DELETE definim que s’ha d’eliminar de la llista l’alumne 1:
1 DELETE classe/programació/alumne/1
En HTTP els mètodes POST i PUT s’han definit per poder enviar informació al
servidor i per tant, a més de l’ordre, normalment s’hi envia quina informació conté.
Això els fa candidats ideals per inserir o modificar recursos.
2.5 Desenvolupament de serveis web
Els avantatges que poden aportar els serveis web (web services) no han passat
desapercebuts i ràpidament els llenguatges de programació han anat incorporant
components per desenvolupar-ne. Per exemple, el JDK (Java development kit) de
Java incorpora una API per crear serveis web que s’anomena Java Api for XML
Web Services (JAX-WS), però ja anteriorment se’n podien crear fent servir Java
API for XML-based RPC(JAX-RPC).
La majoria de les biblioteques o entorns de desenvolupament s’especialitzen en un

dels dos grans grups de serveis web, però l’increment de la popularitat dels serveis
REST ha fet que molts dels entorns basats en el protocol SOAP també incorporin
la possibilitat de funcionar de forma compatible amb REST.
2.5.1 Desenvolupament de serveis basats en SOAP
Les biblioteques SOAP estan pensades per ser transparents amb vista als programa-
dors, i per tant aquests programadors no solen tenir gaires problemes per fer-les
servir. És així perquè les llibreries SOAP s’encarreguen de crear i eliminar els
missatges SOAP, i al programa només hi arriben les dades que s’han enviat.
Un client demana un servei i internament la biblioteca crea el paquet SOAP per a

les dades que ha d’enviar i l’hi envia. Quan la biblioteca rep les dades elimina el
paquet SOAP i envia les dades netes al programa (figura 2.21).
F igu r a 2. 2 1 . Les biblioteques SOAP amaguen la implementació als programadors
Per tant, excepte en petits detalls, els programadors es poden despreocupar de

l’existència de SOAP i només s’han de preocupar de quins serveis volen oferir.
Tot i que no és absolutament necessari crear un client SOAP, és molt més senzill
si es té el WSDL del servei ja que es disposa d’auxiliars que s’encarreguen de
preparar els esquelets del programa.
Gairebé sempre es pot obtenir el fitxer WSDL d’un servei web afegint al
darrere de l’adreça del servei les lletres ?wsdl. En alguns entorns aquest
fitxer es genera automàticament en el moment en què és demanat i en d’altres
és simplement un arxiu.
Un exemple d’això el tenim en la figura 2.22.
Fig u ra 2 . 2 2 . Obtenir el WSDL d’un servei
Els entorns de programació solen oferir auxiliars i eines que simplifiquen al màxim
la creació de serveis basats en SOAP, generant automàticament el codi necessari
per implementar o fer servir el web i fent que el programador només s’hagi de
preocupar de definir què ha de fer el servei web.
Malgrat que els llenguatges més usats per desenvolupar serveis web són sobretot
Java i els basats en la plataforma de Microsoft .NET, gairebé tots els llenguatges
de programació tenen alguna biblioteca que els permet desenvolupar servidors i
clients basats en SOAP. I a més s’ha de tenir en compte que el llenguatge usat és
bastant irrellevant, ja que una de les característiques dels serveis web és que no
importa en quin llenguatge o en quin sistema s’executin els servidors i els clients
que podran operar entre si.
Un dels ajuts més habituals consisteix a fer servir el WSDL del servei per crear
automàticament tot el codi que cal per comunicar o generar el servei web. Per
exemple, mitjançant el mòdul ZSI de Python es pot fer servir l’eina wsdl2py per
crear les plantilles que continguin tot el necessari per implementar un client i un
servidor que puguin treballar amb les funcions del servei que defineix el WSDL.
1 $ wsdl2py http://localhost:8080/axis2/services/Bencalculat?wsdl
2 import multifile, mimetools, urllib
3 $ ls
4 Bencalculat_client.py Bencalculat_server.py Bencalculat_types.py
Moltes biblioteques en diferents llenguatges de programació ofereixen eines

similars, que podeu veure en la taula 2.5.
Taul a 2. 5. Crear codi a partir del WSDL
Llenguatge Biblioteca/entorn Eina
Java Apache Axis2 java2wsdl wsdl2java
Java Apache CXF java2wsdl wsdl2java
C# .NET wsdl
C gSoap wsdl2h
Perl SOAP::WSDL wsdl2perl
Python ZSI wsdl2py
2.5.2 Desenvolupament de serveis basats en REST
REST està tan integrat en la web que no hi ha gaire diferència entre desenvolupar
programes client que funcionin amb REST i desenvolupar programes per connec-
tar i treballar amb servidors web.
Els resultats de fer consultes a serveis REST no es diferencien gens ni mica de

les pàgines web excepte en el fet que el resultat obtingut normalment, en comptes
de rebre només resultats HTML, està en un llenguatge de marques diferent com
XML o JSON (figura 2.23).
Per tant, qualsevol biblioteca que permeti crear clients HTTP serveix per desen-
volupar un client de serveis web basats en REST. Es pot fer servir qualsevol
de les biblioteques estàndard per desenvolupar clients HTTP, com per exemple
HTTPClient de Java, la classe WebClient de .NET o httplib de Python.
Els servidors són una mica més complexos però no gaire més, ja que només cal
veure quina adreça es vol visitar per localitzar el recurs i quina instrucció ha fet
servir el client per saber què hi vol fer. Aquesta tasca és molt més simple que el
treball amb SOAP/WSDL i la majoria dels llenguatges de programació ja disposen
d’alguna biblioteca per facilitar el desenvolupament d’aplicacions REST: JAX-RS,
Restlet, Apache CXF, RESTeasy, RESTSharp, openRASTA...
F igu r a 2. 2 3 . Desenvolupament REST
2.5.3 Entorns de desenvolupament
Han aparegut tota una sèrie d’entorns de treball que faciliten encara més la creació
i desplegament dels serveis web. Amb uns quants clics es pot crear i desplegar un
servei web senzill en pocs segons.
Com passa amb moltes de les tecnologies XML, la majoria d’aquests entorns estan
basats sobretot en dues tecnologies de programació: Java i .NET. Vegem una llista
d’aquests entorns en la taula 2.6.
Taul a 2. 6. Entorns de desenvolupament per crear serveis web
Nom Llenguatge Serveis
Apache Axis2 Java / C SOAP, REST
Apache CXF Java SOAP, REST
Spring Web Services Java SOAP
Metro Java SOAP
JAX-WS Java SOAP
JAX-RS Java REST
.NET Framework .NET SOAP, REST
Windows Communication .NET SOAP, REST

Foundation (WCF)
Apache Axis2
L’Apache Axis és una implementació de codi obert de serveis web que proporciona
un entorn d’execució en Java i C. La implementació Axis2 funciona amb SOAP
1.1 i SOAP 1.2, però també ofereix compatibilitat integrada per a REST.
L’Axis2 ha estat durant molt de temps un dels entorns més usats a l’hora de crear
serveis web SOAP.
L’Axis2 proporciona:
• Un entorn d’execució per a serveis web Java.
• Eines per crear WSDL a partir de codi Java.
• Eines per crear clients Java a partir del WSDL.
• Eines per desplegar, provar i monitorar serveis web.
• Integració amb servidors d’aplicacions i contenidors de miniaplicacions de

servidor (servlets).
L’Axis2 inclou un servidor d’aplicacions que es pot usar directament o bé es

pot fer servir com un component integrable en diferents servidors o contenidors
d’aplicacions com el Tomcat o el Glassfish.
Proporciona un entorn web des del qual es poden gestionar, consultar i comprovar
els serveis web que s’ofereixen (figura 2.24).
F igur a 2. 24. Web principal de l’Axis2
L’entorn d’administració permet gestionar els serveis web de manera que se’n
poden afegir de nous, desactivar-los parcialment o totalment, afegir mòduls de
funcionament, etc. (figura 2.25).
F igu r a 2 . 2 5. L’eina d’administració de l’Axis2 permet fer qualsevol cosa amb els serveis web que s’hi
instal·lin
De cadascun dels serveis oferts es mostra quines són les funcions que exporta el
servei i el seu fitxer WSDL (figura 2.26).
F igu r a 2. 2 6 . Informació dels serveis de l’Axis2
L’Axis2 permet que els mateixos serveis siguin consultats tant des de SOAP com
des de REST (figura 2.27).
Figur a 2. 27. Consulta d’un servei SOAP de l’Axis2 des del SoapUI
Per fer servir una funció en REST es defineix la funció en l’adreça com si fos un
recurs (figura 2.28).
Figur a 2 . 28 . Consulta d’un servei REST de l’Axis2 amb Firefox
Per exemple, si en el servidor http://www.prova.cat:8080/ on hi ha instal·lat l’Axis2

hi tenim el servei Calculadora que exposa una funció anomenada Suma(), que
rep els paràmetres in1 i in2 -els valors que s’han de sumar-, hem de fer una petició
com la següent per sumar els nombres 1 i 2:
1 http://www.prova.cat:8080/axis2/services/Calculadora/Sumar?in1=1&in2=2
3. Informàtica en núvol
En l’àmbit de la informàtica s’està posant de moda en els darrers anys el que

s’anomena informàtica en núvol (cloud computing). A pesar del que pot semblar
no es tracta de cap innovació tecnològica, sinó més aviat de l’evolució de diferents
tecnologies.
La informàtica en núvol fa referència a un conjunt de tecnologies que

permeten emmagatzemar tots els recursos a Internet. Allà, els proveïdors
dels serveis s’organitzen per aprofitar al màxim les seves infraestructures i
proveir servei a múltiples usuaris alhora; d’aquesta manera els clients poden
aconseguir serveis que s’adaptin perfectament a les seves necessitats sense
haver de fer despeses en infraestructura informàtica.
La paraula estrella d’aquestes tecnologies és núvol. Es fa servir aquesta idea per

referir-se a totes aquestes tecnologies, ja que el símbol del núvol sempre s’ha fet
servir en els diagrames de xarxa per indicar xarxes o simbolitzar les connexions a
Internet (figura 3.1).
F ig ur a 3. 1. Diagrama de xarxa
BOINC
El programa BOINC
(boinc.berkeley.edu) permet fer
servir el temps d’inactivitat dels
PC, dels usuaris que ho permetin,
Una de les tasques que la informàtica en núvol simplifica és la distribució de per dur a terme projectes
científics com curar malalties,
càrregues de treball. Els programes que s’ofereixen per Internet cada vegada són estudiar l’escalfament global o
descobrir púlsars.
més complexos i requereixen fer tasques que sovint exigeixen distribuir la càrrega
Per exemple, el BOINC el fan
de treball entre diferents màquines. Això no és especialment nou ja que fa anys que servir els projectes SETI@home,
Climateprediction.net,
en els sistemes oberts d’Unix ja existia la idea de processament distribuït. La idea Rosetta@home o World
era combinar diferents sistemes a partir de les xarxes locals o esteses per repartir Community Grid però es pot fer
servir per incrementar la
una tasca entre diversos servidors i estacions de treball, i així obtenir resultats potència de càlcul de qualsevol
tasca.
semblants als que s’obtindrien en una màquina molt potent i que serien impossibles
si es fes servir un sol ordinador.
Tampoc la idea de llogar ordinadors no és especialment nova ja que algunes grans

empreses com IBM o HP fa anys oferien serveis de processament i emmagatze-
matge en bases de dades per a grans empreses en el que anomenaven computing
on demand. Llogaven el temps dels seus ordinadors centrals (mainframes) per fer
tasques complexes que difícilment s’haurien pogut fer amb ordinadors personals
a empreses que no podien pagar la compra d’una d’aquestes computadores.
La gran innovació de la informàtica en núvol és que parteix de l’evolució d’a-

questes tecnologies i d’altres com la virtualització, l’increment de les velocitats
d’accés a Internet, o la proliferació de dispositius mòbils, que han desembocat en
la seva creació. Amb la informàtica en núvol les organitzacions poden construir la
seva infraestructura informàtica d’una manera totalment diferent de com ho feien
fins ara. Ja no cal que les empreses tinguin grans instal·lacions informàtiques, ni
experts en administració de sistemes, ja que això ho poden obtenir del núvol.
La idea es va portar a la pràctica per primer cop a finals dels anys noranta quan
des de la llibreria en línia Amazon es van adonar que tenien una infraestructura
informàtica molt potent per poder donar servei als seus clients, però que en realitat
l’ús que se’n feia era inferior al 20%. La realitat és que la majoria dels sistemes
informàtics no solen anar a ple rendiment (figura ??).
F igu r a 3. 2 . Ús de CPU d’un sistema
Intentant aprofitar d’alguna manera aquesta capacitat “sobrant” es va crear el

primer servei d’informàtica en núvol, que es va anomenar Amazon Web Services.
La idea era mirar de treure un rendiment al 80% dels recursos que no s’estaven
usant en la seva infraestructura, valent-se de la virtualització. Per exemple,
el servei Amazon EC2 (Elastic Compute Cloud) permet llogar els recursos de
maquinari en forma de màquina virtual, ampliables, fent servir els recursos que
Amazon no estigui usant.
A més, la tecnologia de màquines virtuals és prou dinàmica per permetre que els
clients del seu servei puguin anar dimensionant els recursos virtuals que volen
fer servir segons les necessitats de cada moment.
3.1 Característiques
La informàtica en núvol ofereix una sèrie de característiques i possibilitats que

la fan molt atractiva per a les empreses, ja que permet crear amb poca inversió
econòmica infraestructures que s’adapten a les necessitats puntuals de cada
organització i a les quals es pot accedir des de qualsevol lloc per Internet.
3.1.1 Ubiqüitat
Quan es parla d’informàtica en núvol es defineix un sistema d’obtenció de serveis

o recursos sense necessitat de saber en quin lloc es troben. Al client, doncs, no
li cal saber quina és l’arquitectura de xarxa, ni les característiques tècniques del
núvol; simplement hi accedeix i en fa servir els serveis que necessita. Això fa que
el conjunt pugui ser altament escalable, és a dir, que pugui créixer fàcilment.
Els errors del maquinari del proveïdor en principi no afecten el client, ja que, com
que el client no necessita saber on s’estava connectant, en cas de fallada el servei
pot ser reubicat en alguna altra màquina de manera totalment transparent. Això fa
que la informàtica en núvol sigui bastant tolerant a fallades.
El fet que sigui accessible per Internet també aporta tota una sèrie d’avantatges
afegits: es pot accedir al sistema des de qualsevol lloc sempre que es tingui
accés a Internet, i com que normalment es controla des d’un navegador web s’hi
pot accedir amb ordinadors però també des de qualsevol dispositiu que s’hi pugui
connectar (figura 3.3).
F ig ur a 3. 3. Accés des de qualsevol lloc i amb qualsevol dispositiu

3.1.2 Infraestructura informàtica
El cloud computing fa que no calgui una gran infraestructura informàtica en

l’organització. Des del principi de la informàtica els requeriments de maquinari
dels programes no han fet sinó créixer i això ha obligat les empreses a renovar
periòdicament el parc de maquinari per poder-se adaptar als nous requeriments.
Fent servir la informàtica en núvol es pot aconseguir crear una infraestructura

informàtica completa sense pràcticament haver de tenir un parc informàtic
important. Amb un sol ordinador es pot controlar una infraestructura informàtica
completa que abans hauria requerit milers d’euros d’inversió (figura 3.4).
F igu r a 3. 4 . Un PC controla el núvol
Això trenca el cicle de renovació de maquinari que s’ha anat seguint tradicional-
ment per adaptar la infraestructura als nous requeriments del programari. Amb la
informàtica en núvol ja no cal fer grans despeses en maquinari ni s’han de renovar
els equips: n’hi ha prou amb contractar més recursos. Això permet que les
infraestructures en el núvol siguin molt escalables: poden créixer tant com calgui
per fer front a les demandes del servei.
I com que els clients no necessiten màquines importants per gestionar la seva
infraestructura en el núvol el més habitual és fer servir un sistema de gestió que
no en consumeixi gaires. L’accés a la gestió dels recursos gairebé sempre es
fa mitjançant una aplicació web, de manera que no cal instal·lar cap tipus de
programari en l’ordinador del client perquè amb un navegador n’hi ha prou per
poder començar a treballar i gestionar els recursos en el núvol.
3.1.3 Adaptació a les necessitats
Els sistemes d’informàtica en núvol, com que es basen en tecnologia de màquines

virtuals, són molt més àgils que els serveis tradicionals. Fins a l’entrada en escena
de la informàtica en núvol, quan algú volia contractar recursos per Internet definia
quins eren els que estava contractant i aquests eren els que se li assignaven, a menys
que es canviés el contracte (figura 3.5).
Figur a 3. 5. Allotjament tradicional
La informàtica en núvol trenca amb aquesta manera de funcionar, ja que permet

canviar les característiques de la infraestructura contractada en pocs minuts
i sense haver de comunicar-ho al proveïdor (figura 3.6).
F ig ur a 3 . 6. Informàtica en núvol
Com que es basa en la virtualització, aconseguir que la màquina que s’hagi

contractat tingui més o menys recursos de memòria, espai de disc o CPU no
requereix sinó fer uns quants clics. Això aporta un nou avantatge perquè no
cal perdre temps comunicant amb el proveïdor per fer canvis en el contracte
existent (ja que les condicions canvien), ni cal esperar que tingui a punt el nou
pla contractat.
Sovint en molts negocis la demanda sol ser variable fins i tot en un mateix dia,
en què segons l’hora hi solen haver més o menys peticions. Amb la informàtica
en núvol es pot canviar la capacitat de la infraestructura informàtica de l’empresa
perquè reflecteixi aquesta variabilitat i per tant adaptar la infraestructura infor-
màtica a les necessitats de cada moment.
Abans de l’aparició de la informàtica en núvol, intentar fer front als pics de

demanda regulars requeria fer inversions en maquinari el funcionament del qual
era clar que no s’optimitzaria. Amb el cloud computing s’aconsegueix la capacitat
d’ajustar al màxim els costos en infraestructura.
3.1.4 Reducció de costos
Una de les característiques que defineix més bé la manera com s’ha implementat
la informàtica en núvol és en la manera com es paga. Com que els proveïdors el
que fan és revendre capacitat que altrament no farien servir, han optat per fer que
els clients només paguin per l’ús que facin dels serveis. Això ha fet que un bon
nombre d’autors, com Nicholas Carr, afirmin que aquestes tecnologies situen la
informàtica en un punt molt proper al d’altres serveis com l’electricitat o l’aigua.
Però hi ha una diferència molt gran entre els serveis que ofereix la informàtica
en núvol i els altres serveis: la immediatesa. Per fer canvis en el contracte de
potència elèctrica cal anar a la companyia proveïdora a modificar el contracte
i un cop s’han fet les comprovacions adients es proveeix la nova capacitat. En
canvi, en la informàtica en núvol aquest canvi és gestionat directament pel client i
El consum energètic és tan s’aconsegueix en pocs minuts.
important que en el moment
de crear nous CPD (centres
de procés de dades) També s’ha de tenir en compte un dels costos associats a l’ús de sistemes
algunes de les grans
empreses han optat per informàtics, que és el consum d’energia elèctrica. Els centres de procés de
instal·lar-se en els llocs del
planeta on l’energia és més dades són grans consumidors d’energia elèctrica i els departaments d’informàtica
econòmica i fàcil de produir.
de moltes empreses veuen que bona part del seu pressupost s’ha de destinar a
l’energia elèctrica i a mantenir els equips en bones condicions de refrigeració. Per
tant, des del punt de vista econòmic, la informàtica en núvol ofereix un estalvi
afegit en forma d’un consum d’energia elèctrica inferior.
3.2 Classificació
A pesar que les classificacions solen tenir zones difuses, una de les maneres
més senzilles per entendre quines són les diferents possibilitats que ofereix la
informàtica en núvol és mitjançant classificacions. El més habitual en aquest àmbit
és fer la classificació de dues maneres:
1. Segons qui té la propietat del núvol.
2. Segons el nivell de serveis que s’ofereixen.

3.2.1 Segons la propietat
La primera classificació dels sistemes d’informàtica en núvol es basa en qui és el

propietari dels recursos o serveis que s’ofereixen. Si bé la idea general es basa
a fer servir recursos que “són” dins del núvol i que per tant són públics, han
anat apareixent altres alternatives per donar solucions a totes aquelles persones
i organitzacions que no s’acaben de refiar de perdre el control total de les seves
infraestructures.
Resistència als serveis en núvol
La sensació de “pèrdua de poder” és un dels factors que ocasiona més resistència a la

implantació dels serveis en núvol.
Amb el sistema tradicional una organització podia tenir la certesa de que les dades estaven
dins de l’organització, i per tant podia invertir recursos en la seva protecció i control d’accés.
En canvi, al posar-les en el núvol, aquestes dades ja no estan físicament en l’empresa, i
qui s’encarregarà de proporcionar-ne la seguretat serà el proveïdor en núvol. Això fa que
tot i els contractes que hi pugui haver hi hagi la sensació de que es perd una part del poder
sobre les dades, ja que qui les té realment és el proveïdor.
En certa manera és un problema similar al problema amb què es va trobar Microsoft a

l’hora d’intentar que els usuaris de Windows XP no fessin servir el compte d’usuari de
l’administrador. La majoria dels usuaris no en va fer cas perquè implicava perdre un suposat
“poder” en la seva màquina. Per aquest motiu les noves versions de Windows han abordat
el problema des d’una altra perspectiva: el sistema només executa els programes amb
privilegis de l’administrador quan li és absolutament necessari.
Basant-nos en qui té la propietat de les infraestructures del núvol podem definir

tres grans grups de núvols:
• Privats.
• Públics.
• Híbrids.
Públics
Quan algú pensa en la informàtica en núvol el primer que li ve al cap són els núvols
públics.
Es consideren núvols públics tots aquells núvols que són administrats per un
proveïdor i no pel client que en fa ús.
Els núvols públics ofereixen diversos avantatges, entre els quals destaquem que no
requereixen una gran inversió en infraestructura per part del client ja que el
client simplement defineix quina és la infraestructura que li fa falta i al cap de poca
estona ja la pot començar a fer servir. Això fa que qualsevol usuari, sense haver de
proveir cap mena d’espai físic per instal·lar el maquinari i sense haver comprar els
equips informàtics ni haver-hi d’aplicar cap mena de manteniment, pot aconseguir

una infraestructura informàtica que abans poques empreses es podien permetre.
A més, com que la infraestructura és en el CPD del proveïdor també és aquest

proveïdor el qui s’ha d’encarregar del manteniment i de les actualitzacions de
maquinari, de contractar personal tècnic...
El més normal és que els núvols públics es comparteixin entre diferents clients dins
de la infraestructura del proveïdor, de manera que cadascun dels clients obtingui
només els recursos que necessita en cada moment.
L’exemple clàssic són els serveis que ofereix l’empresa Amazon amb el que
anomena Amazon Web Services (AWS). Aquest producte ofereix múltiples serveis
que es poden contractar i que van des del simple espai d’emmagatzematge fins a
màquines virtuals.
Comunitaris
La idea dels núvols comunitaris rau a compartir la infraestructura no amb tot

el món sinó només amb un grup d’organitzacions d’una comunitat específica
amb uns objectius comuns.
En general el que es fa és compartir una infraestructura d’aplicacions que, en cas

que fos gestionada per cada organització, seria massa cara, ineficient o complexa.
L’administració del núvol pot ser tan privada com pública però els costos i els
beneficis es reparteixen entre els membres de la comunitat. Normalment se sol
cobrar per l’ús que en faci cadascuna de les organitzacions.
La cooperació entre competidors és més habitual del que pot semblar en les empre-
ses i per això la informàtica en núvol els ofereix tota una sèrie de possibilitats de
creació d’infraestructures que els serien molt cares d’implementar separadament.
Un exemple d’aquest tipus de núvols és el format per les empreses Ford, Chrysler
i General Motors, anomenat USCAR, que està pensat per a la recerca de materials
per fabricar vehicles.
Privats
Moltes empreses encara recelen de posar les seves dades i infraestructura crítica al
núvol sota control d’un tercer. Per aquest motiu alguns dels problemes que tenen
els núvols públics s’han intentat solucionar fent servir la mateixa tecnologia per
crear núvols privats.
Amb aquests núvols s’aconsegueix aprofitar millor els recursos de què es disposa
en la xarxa local i s’aconsegueixen part dels avantatges de la informàtica en núvol,
sense perdre mai el control de l’aplicació ni les seves dades, sense dependre de
tercers i mantenint el control total sobre els recursos.
El terme privat implica que només el client fa servir el núvol i que no es

comparteix aquesta infraestructura amb cap empresa externa.
Això comporta que els sistemes han de ser administrats pel client com en un
sistema tradicional i que per tant s’ha de renovar el maquinari i fa falta invertir
en infraestructures i manteniment.
En general els preus baixos dels núvols públics són deguts al fet que el que fan
és vendre les capacitats de computació, memòria i disc que els sobren de les
seves pròpies infraestructures. En general les màquines del sistema no treballen
intensament sinó que, tot i que en moments puntuals exprimeixen els recursos
computacionals, normalment no ho fan.
Per tant, amb un núvol privat s’aconsegueix fer que els sistemes facin un ús
més eficient dels recursos de què es disposa. Crear un núvol privat en la
infraestructura de l’empresa fa que es puguin redirigir algunes de les tasques dels
ordinadors més ocupats a d’altres que no treballen intensament per optimitzar el
rendiment i l’ús del sistema.
A més, la creació d’un núvol privat deixa la porta oberta a la possibilitat que, en cas
que calgui, es puguin reduir costos fent el mateix que fan els proveïdors públics:
revendre els recursos sobrants a altres empreses.
Els núvols privats permeten optimitzar els recursos propis però suposen la pèrdua
de dos grans avantatges d’aquesta tecnologia: la baixa inversió i la possibilitat
d’adaptació del sistema informàtic a les necessitats del moment. En un sistema
privat els recursos són els que són, i si en un moment puntual es requereixen més
recursos dels que es disposa, no es té la capacitat d’adaptar-se ràpidament als nous
requeriments; de la mateixa manera, si les previsions han estat massa optimistes
i la infraestructura és massa gran, tampoc no s’hi pot fer res perquè la inversió ja
està feta.
La llista de programari que permet crear núvols privats no para de créixer, tant
en l’àmbit del codi propietari com en el del codi obert: VMware vSphere,
Citrix OpenCloud, OpenNebula, OpenStack, Eucalyptus, Nimbus... Sovint aquest
programari també es pot fer servir per crear núvols públics o bé interactuar-hi
d’alguna manera.
Híbrids
Els núvols híbrids van sorgir per intentar obtenir els avantatges dels núvols privats
i dels públics. Es basen a disposar una part de la infraestructura en núvols públics
i una altra en privats, de manera que es tingui una part de la informàtica fora de Sovint la comunicació entre
els núvols es fa mitjançant
l’empresa i una altra a dins. serveis web REST o SOAP.
Per aprofitar els avantatges cal que els núvols privats i públics es puguin “enten-
dre”, i per això és essencial que disposin d’alguna forma d’interacció entre si.
L’objectiu és que en el moment en què la infraestructura privada no pugui fer front
a la càrrega de treball es puguin contractar automàticament recursos en el núvol

públic.
Intercloud
Basant-se en la idea dels núvols híbrids, Cisco Systems va definir la idea d’Intercloud. Es
tracta de recrear Internet però prenent com a components bàsics els núvols i no pas les
màquines.
Intercloud és un núvol de núvols interconnectats basant-se en estàndards oberts que

puguin oferir una forma oberta d’implementar un entorn universal interoperable.
El gran repte està a poder aconseguir que hi hagi estàndards d’interoperativitat i portabilitat
entre núvols públics i privats, de manera que es puguin passar recursos d’un núvol a un altre
fàcilment. Això vol dir que un núvol hauria de rebre prou informació per poder desplegar
l’aplicació (recursos, seguretat, localització...).
Aquests estàndards oberts encara no existeixen i no és clar quan succeirà però la majoria
de les empreses estan d’acord que en un moment o altre s’hi acabarà arribant.
Per exemple, la implementació de codi obert Eucalyptus permet implementar un

núvol privat que és compatible amb Amazon EC2, de manera que el núvol privat
es pot comunicar amb un de públic que sigui en la infraestructura d’Amazon.
Els núvols híbrids fins ara s’han mostrat ideals per a diverses tasques com les
còpies de seguretat remotes o la implementació de plans de contingència, però
tothom espera que la seva importància creixerà amb el pas dels anys.
3.2.2 Segons els nivells de servei ofert
És important tenir present que no tots els serveis en el núvol ofereixen les mateixes
capacitats. En aquest àmbit s’ofereix des de maquinari (normalment en forma de
màquines virtuals) fins a serveis de programari més o menys complexos.
Per tant, és important definir algun tipus de classificació dels serveis oferts en el
núvol. La classificació més acceptada sol dividir els serveis en tres grans grups:
• SaaS (programari com a servei o software as a service).
• PaaS (plataforma com a servei o platform as a service).
• IaaS (infraestructura com a servei o infrastructure as a service).
La diferència entre els serveis està en el nivell d’abstracció respecte al maquinari i

sobretot en la dependència del programari que ofereixen. En IaaS disposem d’una
Hi ha alguns autors que
anomenen aquest grup màquina que podem personalitzar i en la qual instal·lem el nostre propi programari
HaaS (maquinari com a
servei o hardware as a
mentre que en SaaS tenim un programa ja desenvolupat per fer-lo servir.
service) però
independentment del nom
que hi posin, la idea final és Aquesta classificació deixa clar que abans que algú triï un sistema o un altre ha de
la mateixa. determinar quin és el sistema que s’ajusta més als seus objectius.
IaaS
Els IaaS són el nivell més baix d’informàtica en núvol. El que fan els proveïdors
és permetre que una part de la seva potència de càlcul i del seu emmagatzematge
sigui oferta als clients en forma d’instàncies de màquines virtuals.
Els sistemes classificats com a IaaS el que ofereixen és la possibilitat de crear

la infraestructura informàtica de l’organització en el núvol.
Per a l’usuari del servei, a part que no veu físicament el servidor, no hi ha cap més
diferència entre tenir un servidor en les seves instal·lacions o accedir-hi mitjançant
el núvol. El control total de la màquina implica que és el client qui s’encarrega de
definir quin sistema operatiu i programes hi instal·la, i qui s’encarrega de controlar
i gestionar el sistema.
Per tant, això porta associades una sèrie d’obligacions ja que el proveïdor cedeix
completament el control de la màquina virtual i és l’usuari qui es fa responsable de
les operacions. Si la màquina arriba al límit de capacitat és l’usuari el responsable
de modificar-la per adaptar-se a les noves necessitats.
La diferència entre obtenir un servidor de núvol o instal·lar-lo en la nostra

infraestructura està en els costos. S’aconsegueix tenir un sistema que es pot
controlar de la mateixa manera que si fos físicament a l’empresa però:
• No cal fer cap inversió en maquinari ni pensar quan s’ha de renovar o

expandir.
• No s’ha d’invertir en les infraestructures de xarxa necessàries per connectar-

lo. I difícilment una empresa es podrà permetre tenir una infraestructura de
xarxa de la qualitat de les d’Amazon o Google.
• No cal tenir grans coneixements d’administració de xarxes ja que és el

proveïdor qui gestionarà aquest àmbit.
Fins a l’aparició de la informàtica en núvol, quan algú volia externalitzar algun

dels seus serveis els contractava a un proveïdor d’allotjament (hosting), el qual
normalment oferia entorns preinstal·lats amb limitacions pel que fa a sistemes
operatius, espai de disc i taxa de transferència de dades. El client es veia obligat
a adaptar-se al “paquet” que oferia el proveïdor que més bé s’adaptés a les seves
necessitats del moment. Aquest sistema tenia diverses limitacions:
• Canviar les característiques del sistema normalment requeria un procés de

negociació amb el proveïdor i era molt complicat aconseguir canviar el
servei per a moments puntuals en què la demanda pogués créixer.
• El control del sistema era relativament reduït ja que la gestió estava en mans
del proveïdor i no se’n solia cedir el control.
• Com que l’entorn ofert era fix els preus també solien ser fixos.
Amb IaaS s’aconsegueix que qualsevol pugui crear la seva pròpia infraestructura
de maquinari:
• Escollir quines són les característiques concretes que ha de tenir el sistema

i modificar-les tant a l’alça com a la baixa en pocs minuts.
• Instal·lar el sistema operatiu i el programari que es vulgui en cada moment.
• Gestionar totalment el sistema operatiu incloent-hi els mecanismes de

seguretat.
• Triar entre una oferta de preus en relació amb l’ús i amb la capacitat
contractada, de manera que s’obtenen preus variables.
El proveïdor de IaaS que té més quota de mercat avui en dia és sense cap mena de
dubte Amazon amb el seu producte EC2 (Elastic Compute Cloud), però d’ençà la
popularització de la informàtica en núvol n’han aparegut molts d’altres, com per
exemple Rackspace o GoGrid.
PaaS
Els serveis del núvol que ofereixen PaaS el que fan és oferir un entorn
de desenvolupament en què un usuari pot desenvolupar les seves pròpies
aplicacions, i un entorn de desplegament per poder desplegar les aplicacions
desenvolupades.
En l’entorn s’hi inclou tot el que cal a un programador per crear prototipus, i
també desenvolupar, provar, documentar, analitzar i posar en funcionament les
aplicacions.
Normalment aquests sistemes ofereixen algun tipus d’API (interfície de pro-

gramació d’aplicacions o application programming interface) que simplifica
notablement el desenvolupament de les aplicacions en la infraestructura a pesar
que limiten els llenguatges de programació que s’hi poden fer servir. Alhora
aquest avantatge a vegades és vist com un inconvenient perquè fa que canviar
de proveïdor sigui molt més complicat, ja que l’API sol ser específica de cada
proveïdor. Això fa per exemple que sigui complicat canviar un programa emprat
amb l’API de Google per adaptar-lo a la infraestructura de Microsoft Azure.
En general en tots hi sol haver:
• Un servei de base de dades.
• Un espai d’emmagatzematge.
• Algun sistema de desenvolupament col·laboratiu per permetre a diferents

desenvolupadors treballar alhora.
En general el PaaS ofereix abstracció dels detalls tècnics de l’entorn en què s’exe-
cuta l’aplicació, i permet així que el desenvolupador només s’hagi de concentrar
en els detalls concrets de l’aplicació que vol desenvolupar.
El contracte sol incloure la garantia que el sistema és escalable (no caldrà canviar
l’aplicació quan creixi) i també la disponibilitat del servei. També sol estipular
que el proveïdor s’ha d’encarregar de fer còpies de seguretat perquè l’usuari no se
n’hagi de preocupar.
A més, no cal que el client faci cap despesa en la compra de nou maquinari
ni programari, i tampoc no tindrà despeses en llicències de programari, i podrà
treballar des de qualsevol lloc i en qualsevol dispositiu que tingui accés a Internet
i un navegador web.
Entre els proveïdors de PaaS més importants hi ha Google, amb el Google App
Engine; Microsoft, amb Windows Azure; o Salesforce, amb Force.com:
• Google App Engine permet desenvolupar i desplegar aplicacions en la

infraestructura de Google. Entre les restriccions que té, el programa ha
d’estar escrit en Python o Java i valent-se només d’algunes biblioteques.
Disposa de diverses API que tenen desenvolupades tasques crítiques de
manera eficient i transparent.
• Windows Azure és la PaaS patrocinada per Microsoft i permet executar,

desenvolupar i provar aplicacions desenvolupades en qualsevol dels llen-
guatges .NET tot i que també pot fer servir altres llenguatges com Ruby,
PHP o Python. Incorpora una base de dades en la mateixa plataforma i
permet comunicacions fent servir el protocol SOAP i REST.
• Salesforce va ser una de les primeres empreses a crear un sistema PaaS i

el seu sistema Force.com permet desenvolupar qualsevol tipus d’aplicació
empresarial lligada a la seva plataforma. Hi ha força restriccions sobre què
es pot fer.
SaaS
El SaaS (programari com a servei) és el servei més conegut de la informàtica en

núvol perquè és el que fan servir més els usuaris finals. Per fer servir SaaS no cal
tenir cap mena de coneixements d’administració ni cal ser desenvolupador; només
cal saber fer servir el programa.
El SaaS fa referència a aplicacions instal·lades pel proveïdor en el seu sistema

i que estan preparades perquè les usin els clients en qualsevol moment.
La idea és que en comptes de comprar una còpia d’un determinat programari -per
exemple, un editor de textos com Microsoft Word- el que es fa és pagar un lloguer
-a un preu molt més baix- per tenir dret a usar-lo durant un determinat període. No
cal instal·lar cap tipus de programa en el sistema del client sinó que s’hi accedeix
mitjançant un navegador, i per tant es pot editar des de qualsevol lloc o des de
qualsevol dispositiu que tingui accés a Internet.
El que caracteritza més aquest servei és que el client no ha d’instal·lar cap tipus
de programari en el seu sistema, sinó que simplement amb un navegador i una
connexió a Internet pot aconseguir treballar amb el programari com si el tingués
instal·lat en la seva màquina.
El SaaS permet que el client es despreocupi de tots els aspectes relacionats

amb la tecnologia: no li cal instal·lar el programa, ni comprovar si han aparegut
actualitzacions de programari o si el programa funciona correctament. De les
actualitzacions, el suport i la disponibilitat del programari se n’encarrega el
proveïdor.
Com que el pagament s’estableix segons l’ús que se’n fa no requereix els costos
inicials associats al programa. Les despeses inicials solen ser molt baixes en
comparació de les que es requereixen en cas de voler muntar la infraestructura
en la instal·lació pròpia, ja que no cal que es facin despeses en maquinari, ni en
llicències de programari, ni cal ni tenir personal informàtic, perquè qualsevol amb
ERP i CRM en núvol
una formació mínima pot fer servir les aplicacions.
En entorns de gestió empresarial,
quan es parla de SaaS es fa Aquest darrer aspecte és especialment important en entorns empresarials ja que
referència a un ERP o un CRM
que no estan instal·lats en els els programes per a empreses sempre han tingut la tendència a ser complexos,
servidors del client sinó que
estan allotjats en el servidor d’un cars i normalment no solen ser senzills d’instal·lar. No és estrany que calgui un
proveïdor. Molts dels grans
proveïdors de programes equip d’experts per instal·lar, configurar i provar el programari abans de poder-lo
empresarials (SAP, Oracle,
Microsoft...) ja ofereixen o
posar en producció, i sempre cal fer un seguiment del producte per mantenir-lo
planegen oferir productes que
funcionen en el núvol. Un dels
actualitzat, solucionar-ne els possibles errors...
que té més èxit és el CRM de
Salesforce, que s’ha convertit en En els darrers anys hi hagut programes de tota mena que han començat a oferir els
una referència mundial.
seus serveis en el núvol i ja s’hi poden trobar aplicacions de tot tipus: sistemes de
còpies de seguretat, programes d’ofimàtica, ERP...
Amb una visió més general, pràcticament totes les aplicacions web que ofereixin
un servei es poden considerar SaaS. Els serveis de correu electrònic en el Web com
Gmail o Hotmail, o els paquets d’ofimàtica en línia com Google Docs o Microsoft
Office 360 es poden considerar SaaS.
3.3 Resistències a l’adopció de la informàtica en núvol
Els sistemes en el núvol ofereixen tota una sèrie d’avantatges en la gestió eficaç
dels recursos, en l’estalvi en inversió en equipament informàtic i en les possi-
bilitats d’escalabilitat de la infraestructura, que superen notablement el sistema
tradicional de creació d’infraestructures en local. Aleshores, si els sistemes en el
núvol ofereixen tants avantatges, per què no els estan adoptant massivament les
empreses?
A part de la resistència dels departaments d’informàtica, que solen veure com un

competidor els serveis en el núvol, els motius més importants solen respondre a
tres grans aspectes:
• Seguretat i disponibilitat de les dades.
• Captivitat en un proveïdor.
• Aspectes legals de l’emmagatzematge de dades.
3.3.1 Privacitat i seguretat de les dades
Les empreses han destinat grans quantitats de diners a la compra, instal·lació i

renovació dels sistemes informàtics, que s’han convertit en un aspecte fonamental
de les organitzacions, i les dades que s’emmagatzemen en aquests sistemes són
l’actiu principal de les companyies.
Per aquest motiu les organitzacions solen ser reticents a desar dades que poden ser
vitals per a la seva supervivència en un sistema que pot ser a l’altra banda del món.
Mentre la informació resideix dins de l’empresa ningú es no preocupa, perquè se
sap on és i sempre és disponible; però en el moment en què les dades crítiques
s’emmagatzemen fora de l’empresa comencen les pors.
Entre les pors més importants hi ha les següents:
• Es pot accedir a les dades sempre que es vulgui?
• Pot ser que algun dia el proveïdor tanqui? En aquest cas, com es poden
recuperar les dades?
• Com es pot garantir que les dades no són accessibles per a un tercer?
Es pot accedir a les dades sempre que es vulgui?
Els sistemes en el núvol posen la informació de les organitzacions que els con-
tracten en mans dels diferents proveïdors que hi estan implicats. Això representa
que es depèn no solament del proveïdor dels serveis en el núvol sinó també del
proveïdor de connexions a Internet.
Si una empresa té tot el programari en el núvol, una fallada en el sistema de

connexió a Internet pot provocar que aquesta empresa quedi paralitzada. Tot i que
les comunicacions han millorat, la majoria de les companyies de comunicacions
no poden garantir un determinat grau de qualitat en el servei i això pot ser un
problema per a determinades empreses o en determinats llocs.
L’altre possible punt de fallada està en els proveïdors de serveis en el núvol.

Malgrat que solen garantir disponibilitats del seu sistema superiors al 90%, com
que no tenen el programari i les dades en una infraestructura local, tot el sistema
informàtic de l’empresa pot quedar inoperant si sorgeix un determinat problema
fins que el proveïdor no soluciona aquest problema.
A més, si es dóna la circumstància que es produeix un desastre, no es podrà fer

servir cap dels sistemes tradicionals de recuperació de dades ja que no hi ha cap
lloc per a aplicar-los, i es depèn de les capacitats tècniques del proveïdor, i també
de les còpies de seguretat que aquest proveïdor hagi fet.
Pot ser que algun dia el proveïdor tanqui? En aquest cas, com es poden
recuperar les dades?
Es tracta d’un problema que les empreses ja afronten habitualment. Què passaria,
per exemple, si tanca una entitat bancària en què l’empresa diposita els seus diners?
És gairebé tan difícil que tanquin alguns dels grans proveïdors de serveis en el
núvol -com Google, Amazon o Microsoft- com que tanqui el banc amb què s’està
treballant.
Com en qualsevol altre servei, contractar en el núvol requereix que s’investigui

prèviament si el proveïdor té prou estabilitat i capacitat per garantir la continuïtat
futura del negoci.
Com es pot garantir que les dades no són accessibles per a un tercer?
Per a molts experts en seguretat la informàtica en núvol té una vulnerabilitat

inherent que es deriva del fet que, com que els servidors són accessibles des de
qualsevol lloc, també poden ser atacats des de qualsevol lloc.
A més, alguns dels problemes de seguretat habituals en els sistemes quan aquests
sistemes són en local esdevenen més importants quan el programa passa al núvol.
Que un usuari faci servir una contrasenya dèbil com 123456 és un problema de
seguretat en un sistema local, però es converteix en una porta oberta al públic si
el sistema és obert a la Xarxa.
3.3.2 Captivitat en el proveïdor
Un dels problemes que té actualment la informàtica en núvol és que no sempre tots

els núvols són compatibles entre si. En aquest moment no existeix un estàndard
d’interoperativitat entre núvols i per tant cada proveïdor fa les coses a la seva
manera.
La falta d’un estàndard d’interoperativitat que segueixin tots els proveïdors fa que
si tenim un núvol en un determinat proveïdor i volem canviar-nos a un altre no
sempre sigui senzill, ja que aquest pas requereix:
• Configurar la xarxa i els mecanismes de seguretat en el nou proveïdor,

adaptant-se a les seves eines.
• Tornar a crear l’aplicació en el nou proveïdor.

• Posar en funcionament l’aplicació en el nou proveïdor i comprovar que

funciona igual que en l’anterior.
• Moure les dades del proveïdor original al nou amb els mecanismes de
seguretat adequats.
Les complicacions del procés solen provocar que sovint, tot i que es consideri que
seria positiu, el canvi no es dugui a terme i per tant l’empresa quedi a mercè d’un
proveïdor concret.
És probable que en un futur proper la interoperativitat entre núvols acabi existint;

ja hi ha veus que reclamen la creació d’estàndards en el núvol que garanteixin la
interoperativitat.
3.3.3 Aspectes Legals
Un aspecte que s’ha de tenir en compte són els problemes de compliment de la

legislació existent en cada país. Internet és una xarxa internacional sense fronteres
i per tant les dades que emmagatzemem al núvol poden anar des del país en què
s’han generat fins a qualsevol altre punt del món.
La ubicació física on s’emmagatzemen les dades és un factor determinant des d’un

punt de vista legal, ja que l’emmagatzematge de dades que continguin informació
de caràcter personal és regulat per la Llei orgànica de protecció de dades de
caràcter personal (LOPD).
La LOPD estableix que no es poden fer transferències internacionals de dades

a països que no tinguin una legislació internacional semblant a la que hi ha a
l’Estat espanyol. I per tant no es consideren transferències internacionals de dades
l’enviament a qualsevol país de la Unió Europea o un grup de països que han signat
un conveni com l’Argentina o Suïssa. S’ha de tenir en compte, per tant, que cal
tenir clar en quin lloc s’emmagatzemaran les dades per no tenir problemes legals. No tots els països tenen
una legislació semblant pel
que fa a protecció de dades.
La LOPD també té altres aspectes que s’han de tenir en compte a l’hora de posar Per exemple, els Estats
Units no la tenen, tot i que
les dades en el núvol: s’accepta que es facin
transferències les empreses
americanes que s’han
adherit al safe harbor.
• Obliga a tenir un responsable de les dades que és qui s’ha d’encarregar
d’establir tota una sèrie de mecanismes de seguretat destinats a garantir
la integritat i la confidencialitat de les dades que s’emmagatzemen. Com
pot saber el responsable de seguretat que això s’està fent si les dades són a
l’altra punta del món?
• Posar les dades a disposició del proveïdor de serveis en el núvol es pot

considerar tractament de dades per un tercer i per tant s’han de complir
tota una sèrie de normes i mecanismes que ha de dur a terme el proveïdor.
Tots aquests problemes legals es poden esquivar definint clàusules en els contrac-
tes amb els proveïdors en el núvol que s’adaptin a la legislació espanyola. Això
requereix que les organitzacions abans de contractar un servei en el núvol es vegin

obligades a repassar el contracte de serveis per veure si realment aquest contracte
s’adapta a la legislació local o no.

Lenguajes de Marcas

Uploaded by

Document Information

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

Lenguajes de Marcas

Uploaded by

Copyright:

Available Formats

Informàtica i comunicacions

Administració de sistemes informàtics en xarxa

Primera edició: febrer 2012

Podeu veure el text legal complet a

En acabar aquest mòdul, l’alumne:

• Reconeix les característiques de llenguatges de marques analitzant i inter-

• Utilitza llenguatges de marques per a la transmissió d’informació a través

• Estableix mecanismes de validació per a documents XML utilitzant mèto-

• Genera canals de continguts analitzant i utilitzant tecnologies de sindicació.

• Realitza conversions sobre documents XML utilitzant tècniques i eines de

• Gestiona informació en format XML analitzant i utilitzant tecnologies

• Treballa amb sistemes empresarials de gestió d’informació realitzant tas-

Programació amb XML

1. Introducció als llenguatges de marques. Classificació.

1. Utilització dels llenguatges de marques en entorns web

2. Definició d’esquemes i vocabularis en XML

Àmbits d’aplicació de l’XML

2. Conversió i adaptació de documents XML

3. Bases de dades natives XML. Llenguatge de consultes (XQuery)

Sistemes de gestió empresarial

1. Sistemes empresarials de gestió d’informació

Llenguatges de marques i sistemes de gestió

1 Introducció als llenguatges de marques. Classificació 9

Els llenguatges de marques estan en plena expansió. Recolzant-se en el gran èxit

L’apartat “Introducció als llenguatges de marques. Classificació” mostra què són

L’apartat “Documents XML” entra en profunditat en el llenguatge XML i explica

En acabar aquesta unitat l’alumne:

1. Reconeix les característiques de llenguatges de marques analitzant i inter-

• Identifica les característiques generals dels llenguatges de marques.

1. Introducció als llenguatges de marques. Classificació

1.1 Les dades

1.1.1 Característiques de les dades

• A qui van dirigides

• Que es puguin compartir

1. Dades destinades als humans: generalment les dades destinades al humans

2. Dades destinades als programes: els programes generalment no necessi-

Reutilització de les dades

Compartició de les dades

En el passat, amb els ordinadors centrals la informació es generava i es processava

• en sistemes operatius totalment diferents.

• en màquines que poden funcionar de maneres molt diverses.

Per tant, en un sistema informàtic modern s’ha de tenir en compte aquesta

1.2 Emmagatzematge de dades en ordinadors

Atesa la seva arquitectura, els ordinadors emmagatzemen la informació en binari i,

Tradicionalment en els ordinadors les dades s’organitzen de dues maneres:

1.2.1 Dades binàries

Emmagatzemar les dades de manera binària és la manera natural d’emmagatzemar

• Generalment estan optimitzades per ocupar l’espai necessari.

• Els ordinadors les llegeixen fàcilment.

• Poden tenir estructura.

• És relativament fàcil afegir-hi metadades.

valor decimal valor binari

Un avantatge afegit de la representació de nombres en binari és que ja estan

Una de les maneres més senzilles de representar una imatge en un ordinador

F ig u ra 1 . 1. Representació d’un gràfic en

En realitat un ordinador no emmagatzemarà la informació d’aquesta manera sinó

Representar la informació d’aquesta manera fa que les imatges ocupin molt

El resultat d’aplicar aquest procediment a la mateixa imatge ens donarà:

Les metadades són dades sobre les dades.

L’ús de metadades optimitza l’emmagatzematge d’informació però alhora fa que

Els tipus de dades estructurats són agrupacions d’altres tipus de dades

Fig u ra 1 . 2 . Representació de dades en una estructura fent servir caràcters

Generalment aquestes dades estructurades s’emmagatzemen en forma de llistes o

Estructura de les dades