4 Johdanto XML-maailmaan Rakenteisia dokumentteja ei voi "ymmärtää" osamaatta niiden perustekniikkaa. Niinpä seuraavaksi kohdistamme huomion tekniikoihin. Rakenteisten dokumenttien yleisiin menetelmiin palaamme taas siten kun osaamme esim. (teknisesti) määritellä dokumenttityyppejä... Seuraavassa luodaan johdatteleva katsaus XMLmaailmaan, jatkossa yksittäisiin tekniikoihin pureudutaan tarkemmin. Tavoitteena on nyt oivaltaa metakielen perusidea ja nähdä metsä puilta potentiaalisesti tarpeellista osattavaa löytyy jo XML-perheestä todella paljon. Tällä kurssilla käsittely rajataan keskeisiin perustekniikoihin. 61
4.1 Uusi merkintäkieli? XHTML soveltuu Web-sivujen julkaisuformaatiksi, mutta ei tarjoa kunnon välineitä mallintaa muuntyyppistä tietoa (vrt. musiikki.html) Myös "omien merkkausrakenteiden esittely HTMLkieleen" onnistuu esim. div- ja span-elementtien sekä class-attribuutin avulla Merkkauksesta tulee kuitenkin erittäin kömpelöä, ja käsittelijä joudutaan kuitenkin ohjelmoimaan itse (jopa julkaisusovelluksissa koska CSS ei mahdollista esim. elementtien uudelleenjärjestelyä eikä selain tietenkään ymmärrä itse keksittyjä classattribuutteja) "Rajoittuneisuus" ei kuitenkaan johdu merkkauksesta, vaan XHTMLdokumenttityypistä joka ei tietenkään taivu kaikkiin sovelluksiin (lue: ei sisällä merkkausrakennetta esim. cd-levyn tiedoille) 62
4.2 XHTML-merkkaus kierrätykseen Vaihdetaan siis sanasto...ja merkataan esim. seuraavasti (musiikki.alb): <music> <album artist="dire Straits" year="1978"> <name>dire Straits</name> <tracks> <track len="5m34s">sultans of swing</track> <track len="6m14s">in the gallery</track> </tracks> </album> <album artist="pet Shop Boys" year="1993"> <name>very</name> <tracks> <track len="3m55s">yesterday, When I Was Mad</track> </tracks> </album> </music> 63
4.3 Huomioita Merkkausrakenne on tuttu XHTML-kielestä, mutta käytössä on nyt music-sanasto (looginen rakenne!) Tiedot on nyt ilmeisestikin merkattu musiikkilevyjen käsitteiden näkökulmasta Se miten em. rakenteeseen päädyttiin on suunnitteluongelma -...oikeassa sovelluksessa ko. dokumentin tyyppi pitäisi tietenkin määritellä, esitellä (ja ohjeistaa sen käyttö) täsmällisesti <!DOCTYPE music SYSTEM "cd-music.dtd"> Mutta: kuka osaa yo. tietoa käsitellä, mikä ohjelma ymmärtää yo. rakenteen tiedot, kuka tietoa tuottaa, jne. - kannattaa siis suosia jo saatavilla olevia tyyppejä, jos mahdollista No, ainakin esitystavan määrittely onnistuu esim. CSS:n avulla (vrt. oheinen prosessointiohje), mutta tällä ei vielä pitkälle pötkitä: <?xml-stylesheet href="mystyle.css" type="text/css"?> 64
4.4 Miksi sama vanha merkkauskielioppi? Täysin uudentyyppisen merkintäkielen (myös uusi merkkauskielioppi) kehittäminen olisi toki myös mahdollista, mutta työlästä, eikä työhön kannata ryhtyä ilman hyviä perusteluita! Käytännössä pelkän merkintäkielen lisäksi kun tarvitaan yleensä "muutakin", esim. - editori, jolla dokumentteja voidaan tuottaa - sovellus(ohjelmia) tuotettujen dokumenttien hyödyntämiseen - sovelluksia, joissa tiedolla on käyttöä - yhteisö, joka ko. merkintäkielen suostuu ottamaan käyttöön Homma helpottuu huomattavasti, jos pyörää ei lähdetä keksimään uudestaan, vaan uusi merkintäkieli suunnitellaan jonkin standardoidun merkintäkielten kuvausjärjestelmän puitteissa (kokemukset!) -...merkkauskieliopin ja välineiden yhteensopivuus on XML:n perusta 65
4.5 No niin... XML - mikä se on? Extensible Markup Language (XML) 1.0 (Third Edition) on virallinen W3C suositus (ns. recommendation, 1. versio vuodelta 1998) XML määrittelee (teksti)dokumenttien loogisen ja fyysisen rakenteen, (merkkauskielioppi ja entiteetit) sekä DTD-määrityskielen tietyn (rajoitetun) elementtirakenteen omaavien, tietyntyyppisten dokumenttiluokkien kuvaamiseen XML 1.0 määrittelee keskeisesti XML-dokumenttien luokan, ts. sen, millaisia XML-dokumentit ovat ja miten niitä tulee käsitellä - XML-prosessori vs. XML-sovellus (ts. XML ~ rajapinta!) XML on SGML:n osajoukko (tästä seuraa ) Kaksi versiota: 1.0 (v. 1998) ja 1.1 (v. 2004); erot vähäisiä XML-sovelluksissa tarvitaan useita muitakin XML-perheen teknisiä suosituksia 66
4.6 XML-spesifikaation suunnittelukriteerit XML:ää kehittäneet XML Working Group (vanha SGML Editorial Review Board) ja XML Special Interest Group (vanha SGML Working Group) asettivat XML:n kehitystyölle seuraavia tavoitteita: - suoraviivainen käyttö Internetin yli - laaja sovellusalue (ei esim. laite- tai ohjelmistoriippuvuutta) - yhteensopivuus SGML:n kanssa - XML:ää käsittelevien ohjelmien kirjoittamisen helppous - vähän valinnaisia ominaisuuksia - dokumenttien luettavuus ja selkeys (myös ihmisten näkökulmasta) - määrityksen tulee valmistua nopeasti (työ alkoi toukokuussa 1996) - määrityksen suunnittelun on oltava tarkkaa ja huolellista - dokumenttien tekemisen helppous - minimalistiseen merkkauksen ei pyritä (esim. pitkät nimet ovat sallittuja) 67
4.7 XML-merkkaus pähkinänkuoressa (dok. esiintymäosa) <?xml version="1.0" encoding="iso-8859-1" standalone="no"?> <!DOCTYPE music SYSTEM "cd-music.dtd"> <!-- taustalla tyyppimääritys --> <?xml-stylesheet href="mystyle.css" type="text/css"?> <music xml:lang="en" xml:space="default"> <album artist="dire Straits" year="1978"> <name>dire Straits</name> <tracks> <track len="5m34s">sultans of swing</track> </tracks> <!-- lisäsin editorin kommentin --> <ed_note> Mercury Records. Dire Straits -- wrong time, wrong place? Note: Should comments be added to <![CDATA[<track>]]> elements as well? </ed_note> <cover src="dd79.png" title="painting by Chuck Loyola" /> </album> </music> Ts. iso osa merkkauksesta tuli jo XHTML-esimerkeissä, nyt uutta oikeastaan enää merkkidatalohko 68
4.8 Tässäkö kaikki?! Ei (mutta "XML ~ ASCII of the 20th Century") Merkkaus on tärkeä mutta pieni askel kohti sovelluksia Todellinen pihvi ovat XML-merkkauksen ansiosta yhteensopivat ja standardoidut sovellukset; - dokumenttistandardit (esim. tyypit XHTML, SVG, SMIL, DocBook,... ja niiden sovellukset) - yhtenäinen perustekniikka (ohjelmointirajapinnat, salaus ja kryptausvälineet, kyselyt,...) - käsittelymenetelmät ja jo tehdyt välineet (muunnostyylit, dokumenttien koostaminen, kyselyt, prosessorit, selaimet,...)...joiden kehittämisessä ja soveltamisessa tarvitaan ilmeisesti muitakin kuin "merkkaustaitoja" Sovellusten kirjo on mahdollinen koska XML:n määrittelemä tietorakenne on yleiskäyttöinen (abstrakti) ja laajennettavissa (tähän palaamme vielä...) 69
4.9 Eräs XML-teknologiaperheen yleisjäsennys Standardoituja XMLpohjaisia teknologioita on todella paljon (puhumattakaan eri organisaatioiden omista XMLsovelluksista) Kärjistettynä: XMLmerkkaus tuo siis käyttöön paljon ko. rajapintaa tukevia teknologioita (sekä välineitä ja sisältöä) XHTML SVG SMIL EMMA XSL-FO XSLT RDFS, OWL RDF CSS XPath MathML CC/PP P3P XQuery VoiceXML WSDL WAI... XForms SOAP......... DOM Canonical Base Fragments Encryption Signature Inclusions Events XKMS XLink XPointer... XML 1.0/1.1 Namespaces 1/1.1 XML Schema HTTP Unicode URI 70
4.10 XML-perheen keskeisiä "standardeja" XML 1.0 (1.1) (*) - merkkauskielioppi, DTD-määrityskieli ja entiteetit (fyysinen rakenne) Namespaces (1.1) (*) - nimiavaruuden käsite (sanastojen yksikäsitteisyys) SAX & DOM (*) - ohjelmointirajapintoja (tapahtuma/mallipohjainen) XML Schema - DTD-kieltä ilmaisuvoimaisempi skeemakieli (sis. mm. std-tietotyypit) XSL (*) - erityisesti XSL-muunnoskieli XSLT (dokumenttiluokkien väliset muunnokset, esim. music xhtml, DocBook xsl-fo,...) (SAX = Simple API to XML, DOM = Document Object Model, XSL[T] = Extensible Stylesheet Language [Transformations]) 71
4.11 Mihin XML:ää voi käyttää? (1/2) Yksinkertaisimmillaan XML soveltuu HTML:n manttelinperijäksi, ts. kaikki, mitä HTML:llä voidaan tehdä, voidaan (periaatteessa) tehdä paremmin e01 e10 ID XML(-standardiperhee)llä e11 IDREF XML on kuitenkin yleisempi, ns. metakieli, ts. se ei ole rajoittunut vain XHTML-tyyppisten, ainoastaan esitettäväksi tarkoitettujen, jne. dokumenttien merkkaamiseen, vaan XML-dokumentteja voi käyttää miltei mihin tahansa (tietorakenne!) Abstraktin perusluonteensa ansiosta dokumentit voivat sisältää mitä tahansa tietoa mitä viittauksia sisältävällä puumaisella tietorakenteella voidaan ylipäänsä mallintaa, siis myös "tietueista koostuvia relaatioita" Suurin hyöty yleensä saavutetaan kun XML-tekniikat ja rakenteinen dokumentaatio nähdään (teknisenä ja [suunnittelu]menetelmällisenä) osana käsittelyaskelista koostuvia tiedonhallintaprosesseja e00 72
4.12 Mihin XML:ää voi käyttää? (2/2) Koska XML tarjoaa mahdollisuuden myös dokumenttien täsmälliseen tyypittämiseen, soveltuu XML lähtökohtaisesti - tiedon esitysmuodon standardointiin (XML-tekstiformaatit) - kommunikaation pohjaksi (XML-viestit) - tiedon arkistointitekniikaksi (...koska laite- ja ohjelmistoriippumatonta, periaatteessa helppoa käsitellä ja siten myös helppoa virkistää) XML-ohjelmien ja XML-prosessorirajapintojen ansiosta XML tarjoaa myös taloudellisen pohjan standardoitujen kehysten ja toisen tason metakielten määrittelyyn eri sovelluksiin (vrt. CC/PP, SOAP, RDF) -...ts. sovellushierarkia (tai palvelupino), perustana yksinkertainen XMLtietorakenne 73
4.13 Webin standardipinon yleisrakenne Saavutettavuus sovellusten sanastot yms. merkkausk. yms. Tiedonsiirto 74
4.14 Miksi ja mihin XML:ää ei pitäisi käyttää? XML:kään ei kannata ottaa perusteitta käyttöön teknologiavetoisesti, onhan olemassa - csv-tietorakenteita, taulukkolaskentaohjelmia, relaatiotietokantoja, hyviä propietarytekstiformaatteja, jne. XML-perustekniikan pulmina voidaan pitää esim. - tekstimuotoisuutta ja monisanaisuutta (verbose) (Binary XML tulossa...) - rajoittuneita merkkaus- ja tyyppimäärityskieliä (DTD), SGML-taustaa - käsittelyn "hitautta" (verrattuna optimoituihin relaatiotietokantoihin) Näissäkin tapauksissa XML voi kuitenkin tarjota luontevan tavan nimetä ja kehystää tietoa esim. tiedonsiirrossa tarvittavan rajapinta/liimakielen tavoin Osa (teknisistä) pulmista myös ratkeaa hyvällä suunnittelulla ja ottamalla käyttöön muitakin XML-standardiperheen määrityksiä ja kunnon työkaluja 75
4.15 Mitä XML:n käyttämiseen tarvitaan? (1/3) XML 1.0 on pohjimmiltaan varsin abstrakti ja yleiskäyttöinen määritys, joka kertoo, millaisia XML-dokumentit ovat (std-tietorakenne vs. sen sovellus) Koska tietorakenteen tulee olla kunnossa, tekstinkäsittelytyökalun rinnalla käytetään aina (validoivaa) XML-jäsennintä: - XML-dokumenttien merkkauksen tarkistaminen, so. onko dokumentti ns. hyvin muodostettu (well-formed) - XML-dokumenttien (rakenteen) validointi, so. dokumentin vahvistaminen tiettyyn dokumenttiluokkaan kuuluvaksi 76
4.16 Mitä XML:n käyttämiseen tarvitaan? (2/3) Tekstinkäsittelytyökalu ja jäsennin voidaan myös yhdistää, tuloksena... - graafinen esitys dokumentin puurakenteesta - XML-merkkauksen syntaksiväritys - elementtien menupohjainen valintatyökalu - tyylieditori ja dokumentin esikatselu,... Editoriin voidaan integroida muutakin, esim. - suunnitteluvälineitä, tyyppikirjastoja - tuki muille XML-standardiperheen välineille - yhteys tietokantajärjestelmään ja (yrityksen tai organisaation) muihin operatiivisiin järjestelmiin, objektieditoreita,... "XML-tuotantoympäristöjä ja -editoreita" ovat esim. - esim. FrameMaker, XML Spy, XMetaL, XRay,... - myös komentorivipohjaisia XML-jäsentimiä löytyy tavallisten tekstieditorien tueksi (esim. Xerces) 77
4.17 Mitä XML:n käyttämiseen tarvitaan? (3/3) Huom. Graafisten ympäristöjen käyttö on toisinaan "makuasia", toisinaan ei - vrt. "ohjelmointi" - mutta esim. tekniset kirjoittajat ("sisällöntuottajat") eivät ole kiinnostuneita merkkauksen tekniikasta vaan kirjoittamisesta! 78
4.18 Lopuksi: XML kulissien takaa vs. näyttämöllä Edellä kuvattiin lähinnä XML:ää kehittäjän näkökulmasta (tekniikkaa...) - loppukäyttäjän näkökulmasta XML on kuin mikä tahansa perustekniikka: - "taas uusia tiedostotyyppejä, jolle integroitu ohjelmistotuki" (vrt. Open Office) Rajatuissa sovelluksissa XML-syntaksi on käytännössä tarkoituksenmukaista piilottaa loppukäyttäjiltä, myös kirjoittajilta (vrt. HTML ja esim. Composerin käyttö) Mitä loppukäyttäjät sitten loppujen lopuksi tarvitsevat? - XML:ää hyödyntävän sovellusohjelman, pluginin tms., käyttöohjeineen Lue: loppukäyttäjän näkökulmasta rakenteisten dokumenttien ja esim. XML-tekniikoiden hyödyt ovat vain välillisiä - yhteensopivien ohjelmistojen runsaus, ominaisuudet, hinta (kehitystyön kustannukset), sovellusten hallittavuus ja virheettömyys,... 79