Programozás | XML » XML ismertető és linkgyűjtemény

Developer XML – kezdetnek nem rossz! Az októberi különszámunkban megjelent SQL annotált sémák késztettek e cikk megírására. A visszajelzések alapján ugyanis világossá vált számunkra, hogy égetô szükség lenne egy tudományos fantasztikumtól mentes, kizárólag értelmes szavakat tartalmazó XML cikk megjelentetésére, mert amíg valaki meg nem írja élete elsô XML/XSL dokumentumpárosát, addig bizony nehezen éli bele magát a bonyolultabbnál bonyolultabb XML alkalmazások (például BizTalk Server) lelkivilágába. Azután itt vannak a szokásos kérdések: az XML az egy új programozási nyelv? Nem. Új adatbázis-formátum? Nem-nem! vôbb, minthogy ideírjuk marketingakcióink idôpontjait. Az XML azonban visszahozza a dokumentumokba a tartalmi leírást, a metaadatokat. Egy XML dokumentumban sohasem találunk közvetlen megjelenítési, formázási információt, vagy ha igen, az baj. Az XML fájl legyen adat központú, hisz sohasem tudhatjuk, hogy mi

a végsô célja: ha bankkártya adatokat cipel két vállalat között (született az SAP-ben, majd a BizTalk Serveren átvonulva elnyeli az SQL Server 2000), akkor belátható, hogy a külalaki információk tökéletesen feleslegesek! Más a helyzet, ha böngészôben meg kell jeleníteni. Ilyenkor segítenek a stíluslapok, az XSL fájlok - de errôl majd késôbb Most térjünk vissza az XML-hez, és vizsgáljuk meg, mitôl több ez, mint spanyol viasz. A teljesség igénye nélkül Félre hát az SGML-lel és az URN-ekkel, készítsünk hirtelen olyan XML dokumentumot, amely nem több mint három sor - készítsük el a „Hello World!“ alkalmazást XML-ben! Elô a „Visual“ Notepaddel! Kiterjeszthetô XML=eXtensible Markup Language. Bármit le lehet írni vele Íme a kedvenc Billjeim: <gyoker> <duma>Hello World!</duma> </gyoker> Ennyi. Save Legyen HELLOXML a neve Nyissuk meg Internet Explorerrel Hát nem gyönyörû? Ha Internet Explorer 5össel

nézzük, akkor valami hasonlót kell látnunk: <gyoker> <bill>Bill Clinton</bill> <bill>Bill Gates</bill> <bill>Billy Idol</bill> <bill>Buffalo Bill</bill> </gyoker> Ha jellemezni kellene ôket, ugyanúgy paramétereket adhatok nekik, mint például HTML-ben egy betûtípusnak. Hasonlítsuk össze ezt: <font face="arial" size="2" color="red">Hello World!</font> ezzel: <bill munkahelye="Fehér Ház" kora="44" biztos ez="nem">Bill Clinton</bill> Korábbi böngészô használata esetén nem tudom, mi jelenik meg :) Aki ki szeretné próbálni a cikk további példáit, használja fel a képernyôképekrôl leolvasható URL-eket, hisz a fájlok az újság weblapján is elérhetôk. (Az egyszerûség és olvashatóság kedvéért az összes XML példám ékezetmentes, mert UTF-8 kódolással kellett volna a Notepaddel elmentenem a fájlokat,

amire a Notepad képes ugyan, de kerülni próbáltam a konfliktushelyzeteket.) De mit is csináltunk? Látható, hogy XML kódocskánk nagyon hasonlít a HTML nyelvre, ugyanúgy <tag>-ekkel (magyarul: HTML tagok) dolgozunk, mint hagyományos weblapkészítés közben. A drámai különbség az, hogy kinek szólnak e tagok: tisztán látszik, hogy nem a böngészônek (nem, nem azért lett piros!), hisz érintetlenül megjelentek a képernyôn. Honnan is tudná az Explorer, miként kell formázni a <duma> tagot? Az XML fájlban a tagok nem az adatok megjelenítését vezérlik, hanem a végfelhasználónak (embernek vagy gépnek) nyújtanak információt a tartalom logikájáról. Valaha a HTML nyelv is ügyelt erre, hisz nem formázó, hanem tartalmi leírótag például a <title>, ám az évek folyamán az egyre giccsesebb weblapok megjelenésével ez a vonulat elsorvadt. Hajdanában a <title> tagot valóban a dokumentum címével illett feltölteni, hogy a

keresôprogramoknak könnyebb dolguk legyen, ám mivel ez jelenik meg az ablak tetején a böngészô címsorában, mi sem kézenfek- Hierarchikus Vegyünk egy a valós életbôl ellesett, szigorúan hierarchikus példát! Írjuk le egy autó összes ülésének, támlájának, huzatának mintáit egyetlen fájlban! A hierarcikus jelleg olyan esetekben igazán hasznos, amikor például egy összetett, apa-fiú adatbázis-lekérdezés eredményét kell eljuttatni egy munkaállomásra. A Microsoft Magyarország szakmai magazinja / 2000. Develpoer / XML Az XML elôtti világban ez csak több, táblázatos lekérdezés egymás utáni átvitelével volt lehetséges. (Illetve szabványmentes módon egy-két gyártó megvalósította ugyan, de piaci sikert senki nem ért el vele) Szabványos Ennek fontosságát azt hiszem, nem kell ecsetelnem. Végre mindenfajta konverzió nélkül szót ért egymással SQL Server és Oracle, Exchange Server és majd a konkurensek is, ha végre

észbe kapnak. Szigorú A szigorúság alatt azt értem, hogy az XML szintaktikája sokkal kötöttebb, mint hinnénk, és ez többnyire jót tesz neki. Amitôl viszont minden Windowshoz szokott XML guru el fog hûlni: megkülönbözteti a kis- és nagybetûket (case sensitive). A <tag>-nak nem bezárója a </Tag> :-( Úgy tûnik egy nagyhangú junixos is helyet kapott a szabványtestületben. Viszont igen lényeges szigorítás, hogy minden tagot minden körülmények között be kell zárni, még akkor is, ha nincs értéke. A HTML-ben simán elhelyezhetünk lezárás nélkül egy önálló <BR> (sortörés) tagot, XML-ben viszont ennek így kell kinéznie: Megjelenítés XSL stíluslapokkal Evezzünk vadabb vizekre! Próbáljuk Internet Explorerben csinosan megjeleníteni az adatokat! Ehhez az XML fájl mellett szükségünk lesz egy másik fájlra is, mely a megjelenítési információkat hordozza - ez az XSL. Ha az XSL-t valóban megjelenítésre használjuk

(miért, mire lehet még?) akkor belsô szerkezete HTML jellegû. Képzeljük el úgy, mint egy mintát, melyet az XML adattartalmával kell kitölteni. Ha az XML-ben 1000 féle pizza van, amelyet egy HTML táblázatban szeretnénk látni, akkor az XSL tartalma logikailag a következô: <html> <table> Ezt ismételd meg annyiszor, ahány pizza van: <tr> <td>Na ide jöhetnek a pizzanevek</td> <td>Ide pedig a sajtosság foka</td> <td>stb.</td> </tr> ciklus vége </table> </html> <önlezárás/> Olvasható Végre itt a világ legjobban debuggolható formátuma! Az XML fájl ugyanis értelmes TXT, olvasható! Mindenféle segédeszköz nélkül tudunk benne hibát keresni. A formátum nyilván csak egy adott befogadható adatmennyiségig élvezetes olvasmány, de hibakeresésre tetszôleges szövegszerkesztô használható. Ugyanakkor e szószátyárság miatt jó nagy is, ám pont emiatt. Remekül tömöríthetô

Persze, hisz a redundancia foka közel végtelen amikor már egymilliomodszor ismételjük el a fájlban a tag nevét: <gyoker> <pizza hus="nincs" sajt="jo sok">Margareta </pizza> <pizza hus="hatfele" zoldseg="brokkoli">Quattro Staggioni </pizza> </gyoker> Az igazsághoz hozzátartozik, hogy ez a fajta procedurális megközelítés csak az egyik, mégpedig a primitívebb XSL megjelenítési lehetôség, mely kizárólag well-known, azaz jól ismert struktúrájú adathalmazon használható. Amennyiben sánta fa és egyéb érdekfeszítô adathalmaz feldolgozására volna szükség (lásd késôbb), akkor elô kell(ene) vennünk halmazszemléletû XSL tudásunkat Térjünk vissza mindkét lábunkkal a földre, és fejezzük be az elôbbi XSL-t úgy, hogy az elôbb ékes magyar nyelven beirkált utasításokat lefordítjuk XSL transzformációs tagokra: Ezt ismételd meg annyiszor, ahány pizza van . ciklus

vége helyett <xsl:for-each select="gyoker/pizza"> . </xsl:for-each> Na ide jöhetnek a pizzanevek helyett <xsl:value-of /> (Önlezáró.) A <pizza> tagok belsô attribútumait (hus, zoldseg) pedig a következôképpen írathatjuk ki: <xsl:value-of select="@hus"/> <xsl:value-of select="@zoldseg"/> ahol a kukac karakter jelzi, hogy itt nem egy érték, hanem egy attribútum tartalmára vagyok kíváncsi. Végül lássuk el a fájlt a hagyományos XSL fejléccel, 2000. 11 / A Microsoft Magyarország szakmai magazinja Develpoer / XML <?xml version=1.0?> <xsl:stylesheet xmlns:xsl="http://www.w3org/TR/WD-xsl"> melyet megérteni nem kell, csak flopin a zsebünkben hordani, hogy ha hirtelen kellene XSL-t alkotnunk, ne álljunk bután és tehetetlenül a probléma megoldásának utolsó mozzanata elôtt. Megfigyelhetô, hogy az XSL fájl is XML nyelven íródott, csak egyfajta szabályos,

rögzített szintaxisú XML-lel van dolgunk. Apropó flopi: mentsük rá azt a sort is, amelyik az XLM-XSL összerendelést végzi – az sem triviális! <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="pizza.xsl"?> Az XSL végleges formában: <?xml version=1.0?> <xsl:stylesheet xmlns:xsl= "http://www.w3org/TR/WD-xsl"> <xsl:template match="/"> <HTML> <BODY> <TABLE BORDER="2"> <TR> <TD>Pizza neve</TD> <TD>Hus</TD> <TD>Zoldseg</TD> </TR> <xsl:for-each select="gyoker/pizza"> <TR> <TD><xsl:value-of /></TD> <TD><xsl:value-of select="@hus"/></TD> <TD><xsl:value-of select="@zoldseg"/></TD> </TR> </xsl:for-each> </TABLE> </BODY> </HTML> </xsl:template> </xsl:stylesheet> Az XML ezek után így

jelenik meg: Hogy az alapokból semmi se maradjon ki, most készítsünk halmazszemléletû XSL megoldást is, ehhez azonban elôször szükségünk lesz egy táblázatba nem foglalható, masszívan hierarchikus XML adathalmazra: <gyoker> <mozi>Muvesz <terem>Chaplin <film>Matrix <kezdet>14:00 </kezdet> <kezdet>16:00 </kezdet> </film> <film>Forrest Gump <kezdet>17:00 </kezdet> </film> </terem> <terem>Huszarik <film>Mumia <kezdet>23:59 </kezdet> </film> </terem> </mozi> <mozi>Kobanya <film>Rain Man <kezdet>17:00 </kezdet> <kezdet>18:30 </kezdet> </film> <szakkor>Vasutmodellezes <nap>Szombat </nap> <kezdet>13:00 </kezdet> </szakkor> </mozi> </gyoker> Könnyen belátható, hogy ez a struktúra kényelmesen nem jeleníthetô meg kétdimenziós táblázatban, hisz a Mûvész

mozi esetén mozi->terem->film->kezdet egymásba ágyazást láthatunk, míg a Kôbánya esetén a terem megkülönböztetésének nincs értelme, továbbá ott nemcsak filmeket vetítenek, hanem szakkörök is vannak – egyébként tavaly bezárt :( . A leghelyesebb az lenne, ha nem is kellene ciklikusan végigfutkározni a sorokon, és rákeresni, hogy vajon éppen miféle adat került elénk, hanem a formázást a lehetô legteljesebb mértékben rábízhatnánk az XSL értelmezôre. Ennek semmi akadálya Az XSL képes arra, hogy az általunk definiált formátummintákat automatikusan, ciklikusan, rekurzíve stb. „ráfesse“ az adatokra Nem kell mást tennünk, mint úgynevezett templateket definiálnunk, hogy hogyan is nézzen ki egy filmcím, legyen az bármilyen mélyen is a hierarchiában, <xsl:template match="film"> <font color="green"><xsl:applytemplates/></font> </xsl:template> A Microsoft Magyarország szakmai

magazinja / 2000. Develpoer / XML azaz a filmcím legyen zöld. Az xsl:apply-templates arra szólítja fel az XSL értelmezôt, hogy ezen a ponton vesse bele magát az XML fáljba, és keresse ki az adatokat. Érdemes megjegyezni, hogy az xsl:apply-templates rekurzív hívás, azaz ha az elôásott adatoknak gyermekadataik vannak (itt a filmeknek kezdetük van) akkor azokra ismét megadhatunk templatet, valahogy így: <xsl:template match="kezdet"> <b><xsl:apply-templates/></b> </xsl:template> A kezdet félkövér lesz. Itt azonban két esetet meg kell különböztetnünk: ha a kezdet egy film gyermeke, akkor a rekurzív hívás miatt <xsl:apply-templates> örökli a szülô formátumát is, emiatt nemcsak félkövér, hanem zöld is lesz Ha a kezdet nem filmhez tartozik, hanem például egy szakkörhöz, akkor fejlesztésünk jelen stádiumában nincs mit örökölnie a szülôjétôl (mert arra még nem írtunk megjelenítési

mintát), ezért egyszerûen félkövér lesz. Írjunk mintát a szakkörre is: Ez a minta minden halmazszemléletû XSL fájban legyen benn, hogy tehesse azt, amire való: jelenítse meg a kifelejtett, félredefiniált halmazok adatait is. Természetesen itt is használhatunk HTML formázást, de vigyázzunk: minden fent említett elemre hatással lesz ez a minta! És már majdnem készen is vagyunk, még kell egy globális template az egész folyamat beindításához (match="/") és save. A mozi.xsl egy kicsit túl nagy ahhoz, hogy ide illesszem, ezért letölthetôvé tettem. A cikkben elôfordult összes XML és XSL fájl letölthetô a következô címrôl: http://technet.netacademianet/feladatok/xmlzip A „formázott“ dokumentum pedig így néz ki: <xsl:template match="szakkor"> <font color="red"><xsl:valueof/></font> </xsl:template> Vajon ettôl pirossá válik-e a szakkör alatti kezdete tag kijelzése is? Igen,

mert az <xsl:value-of> nemcsak az adott tag értékét írja ki az adott mintával, hanem a gyermekekét is. Ez néha súlyos bonyodalmak forrása lehet, mert ha tényleg csak az adott szint értékét kérjük, azt másképp, XSL függvénnyel kell megadni, így: <xsl:value-of select="text()"/>. Ez leállítja a rekurziót Végül hadd mutassam meg a dzsoli dzsóker mintát, amely szintén az elôbbi text() függvény használatával minden egyes további, mintával el nem látott, illetve „mintás", de <xsl:value-of> taggal ki nem íratott értéket egyszerûen a meghívás helyén (rekurzióról van szó!) kidobál a kimenetre: A zip remek lehetôséget nyújt arra, hogy példáimat ki-ki ízlése szerint átirkálja, próbálkozzon vele. A további tanulást segíti az msdnmicrosoftcom címen található XML tutorial gyûjtemény, amely a cikk által felszínre kerülô XML, XSL kérdésekre megnyugtató válaszokat nyújt. Természetesen a

levelezési listán is szívesen válaszolok Végezetül hadd jelezzem, hogy az XSL fájlok nemcsak megjelenítésre valók, hanem ennél átfogóbb szerepük van: általános XML transzformációra alkalmasak. Megfelelô módon alkalmazva az XSL-ek képesek AXML-bôl BXML-t faragni, ahol AXML például egy autógyártó cég rendelési formátuma, míg B.XML egy alkatrészbeszállító cég gyártósorvezérlô adata Ez azonban már egy másik történet: a BizTalk Server legendája. <xsl:template match="text()"> <xsl:value-of/> </xsl:template> 2000. 11 / A Microsoft Magyarország szakmai magazinja Fóti Marcell MCT, MCSE, MCDBA Developer 4 4 Bevezetés A cikk célja, hogy megadja a kezdô lökést azoknak, akik már ismerik az XML nyelv alapjait, hallottak a hagyományos többrétegû alkalmazásfejlesztésrôl, de még nem használták ki alkalmazásaikban az XML-ben rejlô lehetôségeket. Az elsô részben végigfutunk az XML nyelv alapjain, a

további részekben pedig konkrét gyakorlati példákon keresztül megnézzük, hogyan lehet kihasználni az XML elônyeit WEB fejlesztésekben. XML alapok – turbó sebességgel Hogy a gyakorlati részben pontosan lehessen követni a programok és az XML kapcsolatát, megpróbálom tömören, de precízen definiálni az XML technológiában alkalmazott fogalmakat. Az XML nyelv egy olyan leíró nyelv, amely segítségével adatokat reprezentálunk. Úgy van megalkotva, hogy használhatjuk akár önleíró módon, akár egy elôre meghatározott szabályrendszerre (séma) épülve. Ez utóbbi azt jelenti, hogy az adatok ábrázolásának struktúráját megköthetem elôre, és csak azokat az XML dokumentumokat fogadom el megfelelônek, amelyek az általam definiált szerkezet, séma alapján vannak megszerkesztve. Az XML nyelv alapelemei a tagok (tag). A tag egy „kacsacsôrök” <> közé zárt szöveg. Például a <malac> egy tag Az XML tagok érzékenyek a

kis-nagybetûre, <egér> és <Egér> nem ugyanaz! Az adatokat egy kezdô és egy záró tag közé kell elhelyezni, és az így nyert formációt XML elemnek (element) hívjuk. A záró tag ugyanolyan, mint a kezdôtag, csak egy / (per) jel van a tagban található szöveg elôtt. Kezdôtag: <malac>, záró tag: </malac>. Így egy teljesen szabályos XML elem: <malac>Mazsola</malac> A tagok között levô adatokat az elem értékeként (value) kezeljük. Az XML tagoknak tetszôleges számú attribútumokat (attribute) is adhatunk Ezek név="érték" típusú értékadások Az idézôjelek kötelezôek Például, minden malachoz írjuk oda a legjobb barátját egy attribútumként: <malac barát="Manócska">Mazsola</malac> Az XML dokumentum egy olyan XML elem, amelyben lehetnek beágyazott XML elemek. Tehát egy szem XML elem is már egy XML dokumentum, de a tipikus XML dokumentum több szinten is egymásba ágyazott

XML elemekbôl áll. Például: XMLgessünk <szereplo>Morzsi</szereplo> <szereplo>Cicamica</szereplo> </mese> </mesék> Az iménti példa egy jól megformázott (well-formed) XML dokumentum. Hogy miért? Egy jól megformázott XML dokumentumnak teljesíteni kell a következô kritériumokat: Ü A kezdô és a záró tagoknak egyezniük kell Ü Az elemek nem lapolhatják át egymást Ü A problémás karaktereket kódolni kell (<,&,>,",’) Ü Kell lennie egy és csakis egy gyökér elemnek Tulajdonképpen egy jól megformázott XML dokumentum nem más, mint egy olyan dokumentum, ami illeszkedik az XML szabvány által specifikált szabályokhoz. Mitôl lesz egy XML dokumentum érvényes (valid)? Attól, hogy nemcsak jól megformázott, hanem egy elôre definiált sémának megfelelôen van felépítve. Másképpen fogalmazva megkötöm, formálisan leírom az általam használni kívánt XML dokumentum nyelvét, és megnézem, hogy

ennek a nyelvnek megfelelô-e a kapott dokumentum. Ha igen, akkor érvényesnek könyvelhetem el Névterek Vágjunk bele egy kicsit bonyolultabb dologba, egy példán keresztül. Mi van akkor, ha több ország iskoláiból kapunk tanulmányi eredményeket (természetesen XML formátumban), és ezeket szeretnénk egy nagy XML dokumentumba foglalni? Azonban az egyik országban az 1-esnek örülnek a gyerekek, míg nálunk (legalábbis a legtöbb) az 5-ösnek. Ha egyszerûen összefûznénk az adatokat, akkor lehetetlen lenne összehasonlítani a különbözô eredményeket. Valahogyan definiálni kellene az összesített XML dokumentumban a számok kétféle értelmezését. Ezután minden tételnél megjelöljük, hogy melyik tétel melyik értelmezéshez kapcsolódik, így késôbb egyértelmûen kibányászhatók az érdemjegyek. Az ilyen jellegû problémák feloldására vezették be a névtér (namespace) fogalmát az XML szabványban A dokumentum elején meghatározzuk a leírni

kívánt típusokat, és a tagoknál megjelöljük, hogy azok melyikhez tartoznak. Névtér használata nélkül így nézne ki az összevont érdemjegy táblázat: <Osztályzatok> <mesék> <mese> <cim>Mazsola</cim> <oszt>4</oszt> <oszt>2</oszt> </Osztályzatok> <szereplo>Mazsola</szereplo> <szereplo>Manócska</szereplo> <szereplo>Tádé</szereplo> </mese> Melyiknek örülne egy gyerek? Az attól függ, hogy honnan kerültek bele az adatok. Tegyük egyértelmûvé az adatok értelmezését: <mese> 39 <cim>Futrinka utca</cim> <Osztályzatok <szereplo>Buksi</szereplo> xmlns:AzÖtösaJó="http://iskola.hu/Ot" A Microsoft Magyarország szakmai magazinja 2001. 03 Developer 4 4 XMLgessünk xmlns:AzEgyesaJó="http://iskola.hu/Egy" > <AzÖtösaJó:oszt>4</AzÖtösaJó:oszt>

<AzÖtösaJó:oszt>5</AzÖtösaJó:oszt> <AzEgyesaJó:oszt>2</AzEgyesaJó:oszt> Kivételek persze mindig vannak. A névtéröröklôdési láncot megszakíthatjuk bármely ponton úgy, hogy egy üres névtérdefiníciót alkalmazunk a gyermekelemre, és attól a szinttôl lefelé már nem lesz érvényes az alapértelmezett névtér: </Osztályzatok> <Osztályzatok Mit láthattunk itt? Készítettünk két névteret. Az egyiknek „AzÖtösaJó”, a másiknak „AzEgyesaJó” a neve. A nevek tetszôlegesen választhatók, lehetne Jancsi és Juliska is, de nem árt, ha a választott névtér neve utal a funkciójára. Az xmlns:névtérnév="valami egyedi" segítségével definiálhatunk névteret egy taghoz. A „valami egyedi”-nek az egész világon egyedinek kell lenni, így elvileg a világ összes XML dokumentumát konfliktus nélkül össze lehetne fûzni, mert a „valami egyedi” egyértelmûen azonosítja a forrást, így nem

lehetnek névütközések. A névtérnév egy álnév (alias) a hosszú, egyedi névtér névre. Így a tagokban könnyebb rájuk hivatkozni A névtér öröklôdik, így a gyermek tagok (mint az oszt) is használhatják a szülôben (Osztályzatok), nagyszülôben, dédszülôben, satöbbi definiált névteret. Mit jelent az a bûvös URL a „valami egyedi” helyén? Ha beírom az Internet Explorerembe, akkor mi fog ott bejönni? Kakukkos óra? Nem, általában semmi! A névtér mirôl is szól? Arról, hogy valamilyen módon egyedi neveket kell definiálni. Erre két módszer adódik kézenfekvôen: használjunk valamilyen URL-t, vagy alkalmazzuk a Windows-os GUID-ot (Globally Unique Identifier). Mivel a W3C konzorcium, az XML gazdája nem csak a Microsoft által befolyásolt szervezet, ezért a legtöbb névtér deklarációban URL-t látunk, és nem GUID-ot, mint egyedi névtér azonosítót. Amikor egy program feldolgozza az így összesített adatokat, akkor minden egyes tag

feldolgozása során megnézi, hogy az adott tag melyik névtérhez tartozik. A névtereket tudnia kell elôre ahhoz, hogy tudja a dokumentumban található számok, mint osztályzatok értelmét. Mivel a névtér garantáltan egyedi, azért a programunk értelmezni tudja a bejövô XML adatokat. Látni fogjuk, hogy konkrét termékek, például az SQL Server 2000 vagy az XML Parser XSL konvertere csak akkor mûködik helyesen, csak akkor végzi el a kért mûveletet, ha a névteret az elôírtnak megfelelôen, karakterrôl-karakterre pontosan adjuk meg. Ha az adatok zöme egyféle értelmezésû, így csak egy kis százaléka kellene, hogy valami más névtérbe tartozzon, akkor érdemes kihasználni az alapértelmezett névtér (default namespace) lehetôségét, hogy rövidebb dokumentumot kapjunk. Ha az elôbbi példánk bejövô adathalmazában a hazai (az ötös a legjobb jegy) értelmezés a leggyakoribb, akkor tegyük azt az alapértelmezett névtérré, így csak azokat az

adatokat kell megjelölni, amelyeket nem így kell értelmezni. Az alapértelmezett névteret úgy deklaráljuk, hogy nem adunk álnevet a kívánt névtérazonosítónak: <Osztályzatok xmlns="http://iskola.hu/Ot" xmlns:AzEgyesaJó="http://iskola.hu/egy" > <oszt>4</oszt> <oszt>5</oszt> <AzEgyesaJó:oszt>2</AzEgyesaJó:oszt> </Osztályzatok> xmlns=http://iskola.hu/Ot > <oszt xmlns=""> <o1/> <o2/> </oszt> <oszt>5</oszt> </Osztályzatok> A példában a "http://iskola.hu/Ot" alapértelmezett névteret kapcsoljuk ki az elsô <oszt> elemre, és az ô 2 gyermekére (<o1/> és <o2/>) Fontos, hogy az alapértelmezett névtér nem vonatkozik az attribútumokra, csak a tagokra, azaz az <oszt megj="Okos gyerek"> esetén a megj attribútum az nem tartozik az alapértelmezett névtérhez (semmilyen névtérhez sem tartozik). Ha azt

szeretnénk, hogy ahhoz tartozzon, akkor minden egyes attribútum elé is ki kell írni a névtér elôtagot: <oszt AzEgyesaJó:megj="Okos gyerek">. Ezzel még sokszor fogunk találkozni az adatbázis-XML kapcsolatok leírásánál. A fegyvertárunk Cikksorozatunk további részeiben elmélyedünk a sémák, XSL transzformációk és az XPath rejtelmeibe. Ahhoz, hogy e kalandozásaink kézzelfoghatóak, kipróbálhatóak legyenek, nézzük végig milyen programok, eszközök állnak a rendelkezésünkre, ha XML alapú fejlesztésekbe szeretnénk belevágni. A jövôbeli XML alapú fejlesztések teljes támogatására a Microsoft Visual Studio.NET lesz a legkényelmesebb integrált eszköz. Amíg azonban nincs (legalább fél év), addig is kell valamivel dolgoznunk. Milyen eszközökkel tehetjük ezt meg? Microsoft XML Parser 3.0 [1] ô mindennek a lelke, a mozgatórugója. Az XML parser egy COM komponens, amelybe számtalan funkciót belezsúfoltak. Mivel COM

komponens, minden COM-ot támogató nyelvbôl és eszközbôl használható, VB-bôl, VBScript-bôl (ASP), JavaScript-bôl (ASP-ben, böngészôben), Visual C++-ban, vagy akár Windows Scripting programokban. (Azt, hogy Office termékekbôl is használható nem említettem, de természetesen azokból is mûködik) A .NET framework alatt található XML Parser még nem teljes (ami nem is csoda, hisz még Beta 1 szinten van), de a .NET nyelvekbôl egyszerûen meghívhatók a COM komponensek, így egyelôre abban is az XML Parser 3.0-t érdemes használni A parser-ben található szolgáltatásokat két nagy csoportra oszthatjuk: az egyik az XML DOM (Document Object Model), a másik a SAX API (Simple API for XML). Az XML DOM célja, hogy egy XML dokumentumot beolvasson, értelmezzen, és lehetôvé tegye a dokumentumban (XML fában) való mozgást és módosítást programozható felületeken keresztül. Azaz miután beolvasta XML csodánkat, képesek leszünk programból új tagokat

beleilleszteni, attribútumokat módosítani stb. Ugyanezzel a modullal lehet XSL fájlokat is beolvasni, majd egy XML dokumentumra végrehajthatjuk az XSL-ben leírt transzformációkat A Microsoft Magyarország szakmai magazinja 2001. 03 40 Developer 4 4 XMLgessünk A DOM nagyon kényelmes kis XML állományok feldolgozásához, azonban több megabájtnyi XML fájlok feldolgozására nem megfelelô, mert beolvassa az egész XML fájlt a memóriába, és csak utána értelmezi. Ez különösen kiszolgálóoldali felhasználásnál okoz nagyon hamar problémákat, ahol sok felhasználó egyszerre akarna nagy XML-eket értelmeztetni Kiszolgálóoldalon, webalkalmazásokban hasznos lehet az alkalmazás indulásakor felolvasni és értelmezni a sokszor használt XML dokumentumokat, sémákat és XSL-eket. Kifejezetten erre a célra találunk a komponensben olyan FreeThreaded DOM-ot, ami elviseli azt, hogy egyszerre sok weblap egyszerre használja Az elôbb említett

memóriaproblémákon tud segíteni a SAX. A DOM-mal ellentétben a SAX egymás után olvassa fel az XML forrás sorait, és elôre meghatározott feltételek esetén egy eseménnyel jelzi a hívó program felé, hogy felolvasott és értelmezett egy adag XML tagot. Ilyenkor a hívó program feldolgozza a kapott adatköteget, majd visszaadja a vezérlést az értelmezônek. Ezzel a módszerrel tetszôleges méretû XML állományokat is feldolgozhatunk minimális memória felhasználásával, mert mindig csak az éppen feldolgozás alatti dokumentumrész van a memóriában. Egy webalkalmazásban ez nagyon kifizetôdô tud lenni Emellett a csomagban találunk egy HTTP-n keresztüli XML kommunikációra alkalmas objektumot is, melynek segítségével HTTP protokollra ültetve (ezt szinte minden tûzfal szereti!) tudunk XML dokumentumokat küldeni a fogadó alkalmazásoknak. Ez már a Webszervizek lehetôségét villantja fel! Az XML Parser type library-jét Microsoft XML, v3.0 néven

találhatjuk meg a fejlesztôeszközökben Részletes dokumentációt az MSDN library-ban találhatunk, illetve weben a [2] címen. XML fejlesztôeszközök, segédprogramok Az XML parser, mint alapkomponens nélkülözhetetlen, de sok egyéb eszközünk is van, amelyeket kihasználhatunk a fejlesztésekben. Lássuk ezeket! XML Notepad [3] Az XML nélküli testvéréhez hasonló bonyolultságú eszköz, a fejlesztôeszközök csúcsa, mellyel grafikus felületen szerkeszthetjük meg az XML fánkat. Elsô ránézésre elég félrevezetô a felhasználói felülete, azonban némi gyakorlattal jól használható kis program. Íme egy kép róla, mûködés közben: A baloldalon található az XML fa, a jobboldalon pedig an- 41 A Microsoft Magyarország szakmai magazinja 2001. 03 nak tartalma síkba kiterítve. Tehát egy-egy tag, attribútum értékét a jobb oldalon írhatjuk be, míg a baloldalon jobb klikk, helyi menükkel hozhatjuk létre a gyerekelemeket, attribútumokat

satöbbi. Az elkészült mû forrását megtekinthetjük View/Source menüpont alatt: Amellett, hogy láthatjuk az XML forrásunkat, még az is kiderül, hogy sikerült-e jól formázott dokumentumot összehoznunk. SQL Server XML View Mapper [4] Az októberi Tech.net különszámban már írtam az XML nézetekrôl, melyek nem mások, mint az SQL Server 2000 és az IIS együttmûködésével elôállt transzformációk, melyek a háttér SQL adatbázis adatait szolgáltatják tetszôleges felépítésû XML formátumban. Ehhez egy XML formátumú fájlt kell készítenünk, ami az adatbázismezôk és a kimeneti XML dokumentum elemei között teremt kapcsolatot. Ez az XDR annotált séma Az XML nézetek segítségével el lehet rejteni a forrásadatbázis szerkezetét, és tetszôleges XML formátumú kimenô adatokat tudunk generálni az SQL Server táblákból. A tipikus feladat, hogy kapunk egy sémát, ami leírja a kívánt XML adatok formátumát, és nekünk össze kell

párosítani az SQL Server mezôit-tábláit a kívánt XML dokumentum elemeivel. Ez nagyon mechanikus munka, és ebben segít az XML View Mapper. A program felhasználói felületének jobb oldalán láthatjuk az összeállítandó XML nézetünket, a baloldalon pedig egy létezô SQL adatbázis tábláit és nézeteit. A két oldal mezôi között fogd, és vidd módon lehet összerendeléseket teremteni. Az XML nézetben lehet logikai JOIN-okat is létrehozni, azaz olyan táblákat JOIN-olni, amelyek adatbázisszinten nincsenek összekötve. Ennek is elég bonyolult a formátuma, azonban az ehhez szükséges kódot is legenerálja a program. Developer 4 4 XMLgessünk XML Lint [5] Ez egy nagyon egyszerû kis parancssori program, melynek segítségével ellenôrizhetô, hogy egy XML dokumentum jól megformázott-e, valamint, hogy megfelel-e egy paraméterként megadott DTD-nek vagy XDR-nek. </updg:header> <updg:sync > <updg:before> <Employees

EmployeeID="$EmployeeID" /> </updg:before> <updg:after> MSXSL [6] Parancssori segédprogram, melynek segítségével XSLT transzformációkat tesztelhetünk, illetve sok állományra végrehajtathatunk. Azaz veszi a forrás XML dokumentumokat, végrehajtja rajtuk az XSLT fájlban kijelölt transzformációt, és generál egy eredmény XML fájlt Például, ha a forrásfájl, a.xml tartalma: <?xml version="1.0"?> <xslTutorial > <title>XSL</title> <author>John Smith</author> </xslTutorial> Az transzformálófálj, a.xsl tartalma: <xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3org/TR/WD-xsl> <Employees LastName="$LastName" /> </updg:after> </updg:sync> </ROOT> Az összes, ebben a cikkben felsorolt telepítôcsomag és program letölthetô a NetAcademia ftp szerverérôl is a [8] címen. Zárszó Sorozatunk elsô részében belekóstoltunk az XML technológia

alapjaiba. A következô részben megnézzük, mind ügyfél, mind kiszolgálóoldalon az XML dokumentumok feldolgozásának lehetôségét az XML DOM-mal. Addig is a [9] címen található példaalkalmazások segítségével bátran lehet tesztelni a jól formázott XML dokumentumokat, valamint ki lelhet próbálni saját, illetve elôre elkészített példa XSL transzformációkat A jövôben is követjük ezt a jó hagyományt, és minden XML cikkünkhöz itt lesznek elérhetôek a példaalkalmazások és tesztprogramok. <xsl:template match="/"> <H1><xsl:value-of select="//title"/></H1> <H2><xsl:value-of select="//author"/></H2> Soczó Zsolt MCSE, MCSD, MCDBA NetAcademia Kft. </xsl:template> </xsl:stylesheet> MSXSL-lel a transzformáció: msxsl a.xml axsl -o kxml És a kimenet, a k.xml tartalma: <H1>XSL</H1> <H2>John Smith</H2> XML for SQL Server 2000 [7] Az SQL Server

2000 XML támogatásának fejlesztésekor egy fontos cél kimaradt a végleges termékbôl - idôhiány miatt. Így történhetett az meg, hogy az SQL Serverbôl jól kidolgozott, kényelmes módon lehet elérni a tárolt adatokat XML formátumban XML nézetekkel és XML sablonokkal, addig visszafelé, az adatok módosítása még csak SQL Scriptbôl, az OPENXML segítségével lehetséges. Azaz közvetlenül XML formátumú leírással nem lehet adatokat beletuszkolni a szerverbe, XML nézeteken keresztül. Ezt a funkciót az XML for SQL Server 2000 csomag segítségével felokosított SQL Serveren lehet elérni. A bûvszó az updategram, amely lehetôvé teszi a közvetlen, XML adatmódosító parancsok végrehajtását. Csak a teljesség kedvéért megmutatok egy updategram-on keresztüli SQL tábla módosítást, a részletes tárgyalásra külön cikket szánunk. A cikkben szereplô URL-ek: [1] MSXML Parser 3.0 Release http://download.microsoftcom/download/xml/Install/30/

WIN98Me/EN-US/msxml3.exe [2] XML Parser referencia http://msdn.microsoftcom/library/ psdk/xmlsdk/xml 9yg5.htm [3] XML Notepad http://msdn.microsoftcom/xml/NOTEPAD/ download.asp [4] SQL Server XML View Mapper 1.0 http://downloadmicrosoftcom/ download/SQLSVR2000/Install/1.0/NT5/EN-US/setupexe [5] XML Lint http://msdn.microsoftcom/downloads/tools/ xmlint/xmlint.zip [6] MSXSL http://msdn.microsoftcom/msdn-files/027/ 001/485/XSLTCommandLine.exe [7] XML for SQL Server 2000 Web Release 1 http://download.microsoftcom/download/SQLSVR2000/Install/ 1.0/W9X2KMe/EN-US/XML%20for%20SQLEXE [8] A fenti eszközök tükrözése a NetAcademia ftp szerverén ftp://ftp.netacademianet/tools/xml [9] NetAcademia XML oldalak http://technet.netacademianet/feladatok/xml <ROOT xmlns:updg="urn:schemas-microsoft-com: Ä xml-updategram"> <updg:header> <updg:param name="EmployeeID"/> <updg:param name="LastName" /> A Microsoft Magyarország szakmai magazinja

2001. 03 42 XML-gessünk (II. rész) Bevezetés Két hónappal ezelôtti számunkban elindultunk az XML-hez kapcsolódó technológiák felidézésével. Ebben a számban utánajárunk az XML dokumentumok strukturális leírására szolgáló sémáknak, majd rátérünk az Internet Explorer XML képességeire. Ezen belül elmélyedünk az XML dokumentumok formázásában az XSL és a CSS alkalmazására Az itt leírt alapok megteremtik azt a tudást, amely segítségével már ügyfél és kiszolgáló oldalon is tudunk XML dokumentum alapú weboldalakat építeni – melynek részleteit a következô számban olvashatják. XML Stratégia Az XML technológia vívmányai, akár tetszik, akár nem, a nyakunkon vannak, és mielôbb alkalmaznunk kell tudni ôket. Havonta 4-5 oldalban alig lehet valamit átadni ezekbôl a forradalmi módszerekbôl, mert ha alapozással akarnánk kezdeni, akkor minimum a következô 10 cikk csak fogalmak tisztázásával menne el, és még mindig nem

tudnánk használni az XML-t, csak értenénk, hogy mit takarnak azok az X-szel kezdôdô néhány betûs rövidítések. Emiatt a cikksorozatomban hibrid stratégiát vezetek be. Minden szám elején lesz körülbelül egy oldalnyi bevezetô, amelynek célja néhány fogalom tisztázása az XML háza tájáról. A maradék oldalakat mindig valamilyen kézzelfogható, gyakorlatban azonnal alkalmazható példakódokkal fogom megtölteni. A két rész nem feltétlen fog szorosan összetartozni, de egy közös kapocs lesz közöttük: mindkettô XML-rôl fog szólni. Emiatt elôfordulhat, hogy lesz a cikkekben egykét fogalom, amit elôtte nem definiáltam, de ilyenkor mindig hivatkozni fogok egy-egy URL-re, ahol a fogalomról részletes információ kapható. Vágjuk hát bele! Sémaleírás Adott az XML, mint általános, egyszerû és hatékony adatleíró nyelv. Önleíró, azaz egy XML dokumentumot minden külsô információ nélkül értelmezni lehet, be lehet járni a benne

található csomópontokat, kiolvasva az elemek értékét és attribútumait Azonban irányított kommunikáció esetén, akár gépek közötti információcserénél, akár gép-ember kapcsolatban sokszor szabályokat kell alkotnunk a küldendô illetve fogadandó XML dokumentum szerkezetére vonatkozóan. Ekkor már csak azokat az XML dokumentumokat fogadjuk el érvényesnek, amelyek szerkezete megfelel a formális leírásban szereplô feltételeknek. Például egy megrendelést leíró XML dokumentumra valószínûleg kikötnénk, hogy benne kell legyen a megrendelô neve, címe, adószáma satöbbi Ha a kapott megredelésxml-ben nem szerepel minden kívánatos adat, akkor visszadobjuk a megrendelést, mert nem érvényes. Az XML dokumentum szerkezetének, más néven sémájának leírására több módszer is a rendelkezésünkre áll, melyek fokozatosan, a használat során fejlôdtek ki. Nézzük meg mi- 3 3Developer lyen hárombetûs rövidítések segítenek bennünket az

XML dokumentumok sémájának leírásában: Ü DTD, Document Type Definition: [1] a legelsô eszköz volt az XML dokumentumok struktúrájának leírására. Több sebbôl is vérzik, de a legnagyobb problémája: nem XML formátumú. Ha már egyszer kitalálták az XMLt, nagyon gyors és hatékony feldolgozót (parser) írtak hozzá, akkor miért nem lehet az elemzendô XML dokumentum sémáját is XML-ben leírni? Emellett nincsenek benne adattípusok, mindent csak szövegként lehet definiálni, valamint nem támogatja a névtereket, amely nélkül szó sem lehet több forrásból összefûzött adatok ellenôrzésére. Ezek igen súlyos hiányosságok, amely miatt a DTD hamarosan ki fog halni, de egyenlôre sajnos egyedül ez az egyetlen, végleges, elfogadott sémaleíró nyelv. Ü XDR, XML Data-Reduced: [2] a nagyreményû Microsoft DTD utód - volt. A Microsoft gyorsan lemondott a DTD használatáról, és gyors ütemben belekezdett egy XML formátumú sémaleíró nyelv

kidolgozásába, amelyet a Word Wide Web konzorciumnak is elküldött szabványosításra. Megszületett az XDR Amellett, hogy XML formátumú még jóval flexibilisebb is, mint a DTD A DTDben leírt struktúrának maradéktalanul meg kell felelni egy XML dokumentumnak. Az XDR is tud ilyen szigorú lenni, de emellett elô lehet azt is írni, hogy az ellenôrizendô dokumentum egyes részeiben lehetnek további elemek is, amelyet a séma nem ír le. Például egy személyrôl szóló XML adatlapban kötelezôvé tesszük a név, születési dátum és az anyja neve elemeket, de ezen felül megengedjük, hogy egy buzgó gazdi például a kutyája nevét és haja színét is beleszerkessze a dokumentumba. A hangsúly nem azon van, hogy elôírhatunk opcionális elemeket, hanem azon hogy megengedhetünk olyan elemeket is, amelyekrôl a séma készítésekor még nem is tudtuk, hogy lesznek. Ehhez kapcsolódó szolgáltatás, hogy XDR segítségével le lehet szabályozni a dokumentum egy

részét is, nemcsak a teljes egészet DTDvel természetesen csak az egész dokumentumra lehet szabályokat definiálni. Emellett az XDR bôvíthetô, azaz az igények megváltozásakor nem kell a sémát kidobni, csak egy másik névtér bevezetésével kiegészíteni a meglevôt. Utolsó, de nagyon fontos szolgáltatás az XDR-ben, hogy az elemek és attribútumoknak meg lehet adni a típusát (egész szám, dátum satöbbi) A DTD-ben minden szövegként van deklarálva A legtöbb, a közeli múltban fejlesztett Microsoft termék XDR-t használ sémaleírásra. Azonban már a kapuban dörömböl az Ü XSD, XML Schema Definition [3], amely a cikk írásának pillanatában a leginkább aktuális sémaleíró nyelv. A Biztalk Server, illetve a .NET XML osztályok már tudják – tudni fogják ezt a sémaleírást is kezelni (természete- A Microsoft Magyarország szakmai magazinja 2001. 05 32 Developer 4 4 XML-GESSÜNK II.RÉSZ sen az XDR mellett). A Visual Studio 7 egyik

alapszolgáltatása az XSD sémák grafikus szerkesztése, konverziója XDR-bôl XSD-be, XML dokumentumból XSD generálása stb. (A Visual Studio 7 illetve a NET stratégia fejlesztôi szemmel nézve több, mint szenzációs. Újságunkban is rövidesen megkezdjük az alapok lefektetését) Az XML és a Web A Microsoft nagy erôkkel ráállt az XML technológiában rejlô lehetôségekre, és ez az elkötelezettség meglátszik az utóbbi 3 év összes Microsoft termékén is. Az összes terméket áthatja az XML, legyen szó konfigurációs állományokról (.NET-ben minden konfigurációs adat XML fájlokban van, hello registry – végre!), kiszolgáló termékekrôl, vagy az Internet Explorer-rôl Még azt sem tudtuk mi az az XML, de az IE4 már támogatta, persze az akkori szabványnak megfelelôen még eléggé gyerekcipôben, de már mûködtek benne nagyon hasznos funkciók. A Microsoft Internet Explorer 5 már igen hatékony XML támogatást tartalmaz, amely segítségével

az információk megjelenítéshez kapcsolódó funkciók jelentôs részét ügyféloldalon meg lehet oldani, csökkentve ezzel a szerver terhelését. Ezt mondják Amerikában, ahol tényleg agyonterhelik a webkiszolgálókat a szörfözôk. Ezzel szemben nálunk, ahol örül egy webszájt, ha van napi 5000 találata, inkább a lassú modemes kapcsolat miatti lecsökkent szerverhez fordulás az, ami miatt érdemes kihasználni az IE-ben rejlô lehetôségeket. Persze általában az Internetes környezetben nem köthetjük ki a látogatóknak, hogy használjanak IE 5.5SP1-et, mert csak az tudja kihasználni az általunk megírt funkciót. Azonban heterogén böngészôkörnyezetben sem kell lemondani az XML kínálta elônyökrôl, csak buta böngészô esetén az XML-lel kapcsolatos funkciókat a kiszolgálón kell implementálni, és csak a kész HTML kódot leküldeni a böngészôknek. Okos böngészônek megy az XML, butának a HTML. Az okos keveset fordul a webszerverhez, a buta

sokat. IE és XML, a két jó barát Csapjunk bele az IE5 XML szolgáltatásaiba. Ha egy XML állományt adunk meg a böngészônek, akkor ô azt közvetlenül megjeleníti. N Egy közönséges XML állomány az IE5-ben [4] 33 A Microsoft Magyarország szakmai magazinja 2001. 05 Figyeljük meg, az <?xml version="1.0" encoding="ISO8859-2" ?> sort! Egyrészt leírja, hogy a dokumentum az XML1.0-s szabványra épül [5], valamint azt, hogy a benne található karaktereket az ISO-8859-2-es kódtábla alapján kell értelmezni. Ha ezt nem tesszük meg, az összes értelmezôprogram, beleértve azt is, ami az IE mögött is van, kiborul az elsô ékezetes karakternél Az IE55 így dohog: An Invalid character was found in text content. Line 6, Position 19 <CSALAD>Socz?SALAD> -------------------^ Jó, de ez így minden, csak nem felhasználóbarát. Alakítsuk át ezt HTML-é, amelyen keresztül már szépen, formázottan láttathatjuk az

információkat. Két módszer kínálkozik erre, illetve egy harmadik, ami az elsô kettô keveréke. 1) Írjunk egy Cascaded Style Sheet-et (CSS) [6], amiben leírjuk, hogy melyik elem hogyan jelenjen meg a böngészôben. Ez mûködô, de igen erôsen behatárolt módszer, mert csak nagyon korlátozott lehetôségeink vannak a cél HTML dokumentum formátumának meghatározásában Egyszerûen azért, mert a CSS nem erre van kitalálva Arra nagyon jó, hogy leírjuk vele egy adott HTML elem megjelenését, de itt XML elemeket kellene transzformálni valamilyen, általunk definiált HTML formátumba, és erre a feladatra nem alkalmas a CSS. Viszont, erre van kitalálva az 2) Extensible Style Language, röviden XSL [7]. Az XSL pont arra van kitalálva, hogy tetszôlegesen bonyolult módon jelenítsünk meg egy XML dokumentumot, ami nevezhetnénk adatforrásnak is, kihangsúlyozva, hogy az nem hordoz semmiféle megjelenítési információt. XSL segítségével könnyedén

megváltoztathatjuk az adatok, elemek eredeti sorrendjét, megszûrhetjük a benne található adatokat, ismétlôdéseket vihetünk be, stb. Egyszóval XSL segítségével olyan HTML kimenetet generálunk, amilyet csak szeretnénk. Tulajdonképpen az eredeti XML dokumentumot bármi mássá is átkonvertálhatjuk vele, például egy másik XML dialektussá, azaz egy más struktúrájú XML dokumentummá, vagy éppen szöveges állománnyá! Amivé csak akarjuk. Nem véletlenül fejlôdött ki az XSLT [8], az XSL Transformations szabvány az XSL-bôl. Az XSL esetén a kiinduló cél az XML adatok meg jelenítésének szabályozása volt - alternatíva a CSS mellé. Az XSLT már kifejezetten annak fényében készült, hogy az XML dokumentumokat valamilyen más formátumúra akarjuk átalakítani,transzformálni. Van XSLT-nk, amivel pompásan át lehet alakítani a megjelenítendô XML dokumentumot HTML-é. Azonban egy bonyolultabb XSLT transzformáció igen áttekinthetetlen tud lenni,

és ha még ebbe képeket, formázó parancsokat, stílusokat is beleszövünk, akkor egy olyan XML-HTML-formázó parancsok spagettit kapunk, ami karbantarthatatlan lesz. Ekkor jön a nyerô ötlet XSLT-vel transzformáljuk át a kívánatos HTML-é a forrás XML-t, és a formázásokra csak hivatkozunk benne, de ne fejtsük ki ôket az XSLT-ben Ehelyett az összes formázó utasítást rakjuk ki CSS-be, és máris ötvöztük az XSLT flexibilitását a CSS szuper formázási képességeivel. Mindeközben a grafikus bármikor nyugodtan átgyúrhatja a CSS-t, nem kell szembesülnie (és elszaladnia :) az XSLT-vel. Developer 4 4 XML-GESSÜNK II.RÉSZ Az XSLT közbelép Most, hogy kipletykáltuk a grafikust, készítsünk egy XSL dokumentumot, és adjuk meg a forrás XML-ünknek, hogy amikor a böngészô megjeleníti, használja az XSL-ünket. Ehhez az XML forrás elején megadjuk az XSL fájl elérését (na.xsl): <?xml version="1.0"

encoding="ISO-8859-2"?> <?xml-stylesheet type="text/xsl" href="na.xsl"?> <NETACADEMIA> . A böngészô az XML állomány betöltésekor megnézi, hogy van-e XSL hozzárendelve. Ha van, akkor letölti azt is, és végrehajtja az abban leírt mûveleteket, majd megjeleníti a végeredményt Nézzünk egy egyszerû transzformációt: <?xml version="1.0" encoding="ISO-8859-2"?> <xsl:stylesheet xmlns:xsl="uri:xsl"> <xsl:template match="/"> 1 <HTML> <HEAD> <link rel="stylesheet" type="text/css" href="na.css" /> 0 </HEAD> <BODY> <TABLE CLASS="OktatokTabla"> <TR> <TD>Név</TD> <TD>Pozíció</TD> <TD>Telefonszám</TD> <TD>EMail cím</TD> 3 </TR> <xsl:for-each select="NETACADEMIA/OKTATó> <TR> <xsl:apply-templates/> 4 </TR>

</xsl:for-each> </TABLE> </BODY> </HTML> </xsl:template> 2 <xsl:template match="NEV"> 5 <TD><xsl:value-of select="CSALAD"/> <xsl:value-of select="KERESZT"/></TD> </xsl:template> <xsl:template match="BEOSZTAS"> 6 <xsl:template match="EMAIL"> <TD><xsl:value-of select="."/></TD> 8 </xsl:template> </xsl:stylesheet> Hogyan hajtja vége a böngészô az imént felvázolt transzformációt? A Å azt jelzi, hogy a match-ben megjelölt elemre, ami jelen esetben a gyökér elem (<NETACADEMIA>) hajtsa végre a záró tagig Ç leírt mûveleteket. Mit jelent a végrehajtani? A nem XSL tagokat egyszerûen bemásolja a kimenetbe, így egészen a É pontig minden bekerül a végeredménybe. Jól látható, hogy itt egy HTML táblázatot hoztam létre, egy fejléccel. Az XML forrásból származó tartalom generálása

a É körül történik Az xsl:for-each arra utasítja az XSL értelmezôt, hogy a select után megadott XPath [9] kifejezés által kiválasztott elemeken menjen végig, és mindegyikre hajtsa végre az utasítás törzsében leírt parancsokat. A NETACADEMIA/OKTATO XPath kifejezés az összes, a NETACADEMIA elem alatt létrehozott OKTATO elemekre ad egyezést, azokat választja ki (jelen esetben csak egyet, de ha több ismétlôdô OKTATO elem lenne a forrásban, akkor mindegyiket). Mi történik a kiválasztott elemekkel? Generálódik hozzájuk egy <TR> </TR> páros, ami HTML-ben a táblázat egy sorát írja le. És a lényeg, a forrásadatok a Ñ kifejezés jóvoltából kerülnek bele a kimenetbe. Az xsl:apply-templates elem azt jelenti, hogy az éppen feldolgozás alatt álló elemre nézze meg, hogy van-e egyezô sablon létrehozva. Ha van, akkor azt végrehajtja, és annak a kimenete beleszövôdik a Ñ kifejezés helyébe. Esetünkben a É paranccsal lefúrtunk

az XML forrásunk <OKTATO> eleméhez, így az Ö-à sablonok már errôl a szintrôl indulnak, azaz a match attribútumokban megadott XPath kifejezések kiegészülnek így: /NETACADEMIA/OKTATO/TELEFON, mondjuk a á sablon esetén. Másképpen fogalmazva a forrás XML-ben a /NETACADEMIA/OKTATO/TELEFON elérési úttal jelzett elem elérésekor az XSL processzor meghívja a á sablont. A sablonon belül az xsl:value-of elem kiválasztja a select="KORZET" által kijelölt elem értékét, azaz a <KORZET></KORZET> közötti szöveget â. Néhány egyéb formázó karakter és a SZAM elem értékének felolvasása után a sablon véget ér. Ezután az XSL motor megnézi, hogy van-e még más sablon, ami egyezést mutat valamelyik elemmel. Esetünkben mind a négy sablon szóhoz jut minden egyes oktatóhoz. Miután É végigment az összes elemen, kiíródik a táblázat vége, és véget ér a végrehajtás a Ç ponton. Aki ezt az utat lelkiismeretesen

végigkövette, az megérdemli, hogy megnézze a végeredményt: <TD><xsl:value-of select="."/></TD> </xsl:template> <xsl:template match="TELEFON"> 7 <TD>+36 (<xsl:value-of select="KORZET"/>) <xsl:value-of select="SZAM"/></TD> </xsl:template> 9 Mitôl lett ez ilyen díszes és tarka (mi lesz ebbôl a szürke újságban?! :) ? Hát attól, hogy az XSL által generált HTML A Microsoft Magyarország szakmai magazinja 2001. 05 34 Developer 4 4 XML-GESSÜNK II.RÉSZ kimenet kapott még egy CSS-t is a Ä -val megjelölt sorban. Anélkül csak egy fehér táblázatot látnánk. A teljesség kedvéért itt az nacss tartalma: <STYLE> BODY { BACKGROUND-COLOR: snow } TABLE.OktatokTabla { BORDER-RIGHT: groove; BORDER-TOP: groove; BORDER-LEFT: groove; COLOR: mediumblue; BORDER-BOTTOM: groove; FONT-FAMILY: Tahoma; BACKGROUND-COLOR: lightgoldenrodyellow } TD { BORDER-RIGHT: thin

groove; BORDER-TOP: thin groove; BORDER-LEFT: thin groove; BORDER-BOTTOM: thin groove } </STYLE> Az elôbbi XSL transzformáció egy nagyon egyszerû példa volt, ennek ellenére már ez is elég átláthatatlan és bonyolult lett. Az XML technológia bonyodalmaiba akkor kóstolunk bele igazán, amikor az XSLT nyelvet kezdjük el használni. A gond az, hogy az XSLT nem procedurális nyelv, hanem alapvetôen sablonok egyeztetésén alapul. Ez a fajta gondolkodás igen szokatlan egy Basic vagy C nyelven felnôtt programozónak. További nehézség, hogy mit tehetünk akkor, ha egy jó bonyolult XSLT transzformáció nem úgy mûködik, ahogy azt elvárjuk tôle? Nem formátumbeli hibákra gondolok, azt kiszûrik a transzformáló komponensek. Akkor leszünk meleg helyzetben, ha „csak" logikai hiba van az XSLT-nk mûködésében, és nem azt a transzformációt hajtja végre, amit mi módoltunk ki. Ilyenkor jönnek képbe a nyomkövetô vagy debugger programok, amelyek

segítségével lépésenként lehet végrehajtani a programunkat, ebben az esetben az XSL transzformációt. Ez egy kemény feladat, de szerencsére az Activestate cégnek - amely elsôsorban a Win32-es Perl eszközeirôl híres – megjelent a Visual XSLT 10 [10] programja, ami egy plug-in a Visual Studio.NET 7-hez, és amelynek segítségével szerkeszthetjük és nyomkövethetjük az XSL transzformációinkat. Szenzációs termék! A debugger ablakban láthatjuk a transzformáló XSLT-t, benne az éppen végrehajtás alatt álló XSL paranccsal. A Watch ablakban láthatjuk a forrás XML éppen feldolgozás alatt álló elemeit, az Output window-ban pedig a transzformált végeredményt. A program jelenleg Beta 1 állapotban van, hasonlóan a Visual Studio.NET 7-hez Ennek ellenére aki komolyan, a jelenben és a jövôben élve szeretne XML-lel foglalkozni, mindenképpen szerezzen be egy példányt a Visual StudioNET 7-bôl, és töltse le a Visual XSLT 1.0-t Mindkettô Must Have!

35 A Microsoft Magyarország szakmai magazinja 2001. 05 Újdonságok Az XML-t alkalmazó alkalmazásokat programozók legalapvetôbb fegyvere a parser, XML értelmezô, amely az XML Document Object Model-en keresztül programozottan elérhetôvé teszi az XML dokumentumok belsô szerkezetét. A parser-ek lehetôvé teszik a felolvasandó XML dokumentumok ellenôrzését egy megadott sémával szemben, amely jelen pillanatban – Microsoft-os platformon – DTD és XDR-el történhet. Az aktuális parser a Microsoft-tól a 3-as verziónál jár, ez az, amit éles környezetben is lehet használni. Azonban nincs megállás. Áprilisban a Microsoft kiadta a Microsoft XML Parser (MSXML) 40 Technology Preview Release-t Ezt még nem ajánlják produkciós környezetbe, de mindenképpen érdemes tanulmányozni. Miért? Azért, mert végre támogatja az XSD-t! A parser-ben implementált séma validáló kód a Wide Web Consortium (W3C) XML Schema, 2001. március 30-ikai ajánlásában leírt

módon mûködik, azaz olyan friss, hogy még meleg! Mivel ez még mindig nem a végleges XSD szabvány, így várható, hogy az valamennyit még változni fog a végleges kiadásig. Az XML parser 4 természetesen követni fogja a változásokat, újabb és újabb kiadásokkal. Mi van még a csomagban az XSD mellett? Megjelent benne egy új objektum, az MXHTMLWriter, amely segítségével a SAX API által felolvasott XML dokumentumból kapott adatfolyamot lehet HTML-lé transzformálni. Ez egy alternatív megoldás lesz az XML --> XML DOM --> XSLT --> HTML feldolgozásra, kifejezetten nagyteljesítményû webalkalmazásokhoz. Az új verziót fel lehet telepíteni olyan gépre is, amin már van MSXML3-as parser, így az alkalmazáaok a verzió függô ProgID-k használatával tudják használni mind a 3-as, mind a 4-es változatot. Arra viszont vigyázzunk, hogy ne rakjuk fel produkciós szerverre, mert a verziófüggetlen objektumlétrehozást alkalmazó programok az új

verzióból fognak egy példányt kapni, ami meglepetéseket okozhat. Zárszó Aki lelkiismeretesen végiglépkedett a példa XSL-en és XML-en, annak már van fogalma az XML alapú fejlesztések alapköveirôl, látja a jéghegy csúcsát. De az igazi csemege még a víz alatt van. A következô számban a transzformációt már nem fogjuk az Internet Explorer-re bízni, hanem a kezünkbe vesszük az XML DOM-ot, és azzal hajttatjuk végre az XSL-ünket, mind kiszolgáló oldalon, mind ügyfél oldalon. És ha már ott vannak az adatok a böngészôben, miért ne lehetne rögtön szûrni illetve sorbarendezni ôket, anélkül, hogy a szerverhez kellene fordulni? Miért is ne? A júniusi számban megmutatom hogyan. Soczó Zsolt MCSE, MCSD, MCDBA Zsolt.Soczo@netacademianet A cikkben szereplô URL-ek: [1]: DTD szabvány http://www.oasis-openorg/cover [2]: XDR szabvány http://www.ltgedacuk/~ht/XMLData-Reducedhtm [3]: XSD http://www.w3org/XML/Schema [4]: Példakódok

http://technet.netacademianet/feladatok/xml [5]: XML1.0 szabvány, magyarázattal! http://wwwxmlcom/axml/testaxmlhtm [6]: CSS szabvány http://www.w3org/Style/CSS [7]: XSL szabvány http://www.w3org/Style/XSL [8]: XSLT szabvány http://www.w3org/TR/xslt [9]: XPath szabvány http://www.w3org/TR/xpath [10]: Visual XSLT 1.0 Beta 1 http://www.activestatecom/ASPN/Downloads/VisualXSLT