V súčasnej dobe viac ako kedykoľvek predtým je potrebné prezentovať zozbierané údaje vo forme rôznych prehľadov. Dôležitým faktorom okrem validity dát je aj čas potrebný na vytvorenie požadovaného prehľadu. Niekoľko príkladov:

• prehľad o pracovníkoch podniku a ich pracovných výkonoch za určité obdobie
• výkaz o zápočtoch a skúškach
• zoznam podaných daňových priznaní členený podľa typu daň. priznania, regiónu atď..
• zoznam neplatičov podľa zadaných kritérií

Požiadavka na rýchlosť je opodstatnená, lebo ak napríklad vedenie podniku dostane prehľad výkonov svojich zamestnancov za uplynulý mesiac neskoro (napr. z mesačným oneskorením), nemôže flexibilne meniť zaradenie a pracovnú náplň zamestnancov.

Okrem faktora času treba zdôraniť aj ďalšie črty ako napríklad spôsob, metodika tvorby reportu. Kladie sa veľký dôraz na jednoduchosť a zrozumiteľnosť riešenia, intuitívne ovládanie použitých nástrojov, správne rozdelenie rolí v procese tvorby reportu. Otvorenosť a rozšíriteľnosť nástroja, možnosť rozšírenia tretími stranami, podpora rôznych výstupných formátov a prehliadačov reportov (napr:web prehliadač), export/import, zapojenie v rámci ďalších systémov podniku, či organizácie. Otvorenosť, v zmysle tvorby riešenia na otvorených technológiách a štandardoch napr:XML. V neposlednom rade aj kvalitná dokumentácia riešenia i výsledných reportov, ako aj zriaďovacie a prevádzkové náklady, jednoduchosť inštalácie a údržby systému.

Pre účely tejto práce reportingom nazývame každý proces, ktorého výsledkom je prezentácia nejakej množiny dát vo forme prehľadu. Výstupnou zostavou alebo reportom nazývame výsledok tohto procesu. Pri tvorbe reportom najčastejším dátovým zdrojom sú dáta uložené v relačných databázach ale už ani to nie je pravidlom a ako poukážeme neskôr sú opodstatnené požiadavky na reporting aj z iných dátových zdrojov ako napr: objekty, XML dokumenty.

Cieľom tejto práce je navrhnúť a vytvoriť nástroje na modelovanie a generovanie výstupných zostáv. Zhodnotiť vhodnosť použitia UML, XML Schéma, XML, XMI technológií pri modelovaní a generovaní zostavy. Na vybranom príklade ilustrovať proces modelovania a použitie vytvorených nástrojov.

V kapitole 2.Dostupnosť hotových riešení predstavíme niektoré dostupné riešenia na trhu a poukážeme na niektoré ich vlastnosti zaujímavé hlavne z pohľadu tejto práce a nášho riešenia. Ako sme už spomínali typickým dátovým zdrojom pri tvorbe reportov sú relačné databázy. V kapitole 3.Dátové modelovanie a dátové zdroje sa zameráme práve na ne a na použitie CASE systémov a tradičné postupy pri dátovom modelovaní. Pôvodne sme chceli využiť CASE systémy, konkrétne CASE Rational Rose a jazyk UML pri tvorbe nášho riešenia. Prijatím konceptu XML ako všeobecného dátového zdroja však stratilo nasadenie CASE systémov a jazyka UML pri tvorbe nášho riešena zmysel. Keďže však CASE systémy zostanú aj naďalej nástrojmi na modelovanie objektových a dátových modelov, ukážeme v tejto kapitole, na základe XMI formátu, možnosť mapovania dokumentačných informácií týchto modelov, do nami používanej XML Schémy pre popis XML ako dátového zdroja.V kapitole 5.XMLSchéma ako rozhranie ukážeme zaujímavé riešenie Davida Carlsona, ktorý používa jazyk UML a CASE systémy na modelovanie samotnej XML Schémy. Kapitola 4.XML, XMLSchéma a XSL je ľahkým úvodom do technológií XML, XMLSchéma a XSL, ktoré v našom riešení používame. Vysvetlíme základné princípy týchto technológií, ktoré sú nevyhnutné pre správne pochopenie tejto práce. V kapitole 5.XMLSchéma ako rozhranie ukážeme dôvody, vedúce k použitiu XML Schémy ako rozhrania, ktoré delí proces prípravy reportu na dve časti, na prácu dátového špecialistu a na prácu tvorcu zostavy. Poukážeme na niektoré výhody takéhoto rozhrania a spomenieme možnosti prezerania a tvorby XMLSchém. V kapitole 6.Proces modelovania, generovania a spúšťania reportu predstavíme celý proces od modelovania až po spúšťanie výstupnej zostavy, vysvetlíme v nej čo je vstupom a výstupom jednotlivých fáz modelovania, generovania a spúšťania reportu a aké výhody takáto koncepcia prináša. V kapitole 7.Report Designer predstavíme vytvorený nástroj pre modelovanie a generovanie výstupných zostáv nazvaný Report Designer, popíšeme hlavné črty , možnosti a výhody tohto nástroja. Report Designer je web aplikácia, ktorá môže byť jednoducho začlenená do podnikového systému, intranetu. Klientská časť aplikácie je naprogramovaná v Microsoft Internet Exploreri a je postavená na technológiach HTML, CSS, JavaScript, DHTML, HTC, XML, XSL. Umožňuje jednoducho vizuálne a v známom prostredí (web prehliadača) modelovať, generovať a spúšťať výstupné zostavy. Voľbou prehliadača internetu ako cieľovej klientskej platformy sa odbúravajú náklady na inštaláciu a údržbu systému, nakoľko prehliadač má nainštalovaný, alebo zvládne jeho inštaláciu, aj bežný používateľ. Používateľ (tvorca reportu) naviac získava možnosť práce s Report Designerom po prihlásení sa na server, aj kdekoľvek vo svete prostredníctvom internetu, nie je tak viazaný na konkrétne pracovisko, môže tak flexibilne reagovať na dodatočné požiadavky na report aj mimo podniku. V kapitole 8.Generovanie a spúšťanie zostavy na jednoduchom príklade demonštrujeme proces generovania a spúšťania repotu. Načrtneme spôsob generovania pri riešení niekoľkých čiastkových úloh. Kapitola 9.Systémové požiadavky obsahuje zoznam požiadaviek na serverovskú aj na klientskú časť aplikácie.

Z dostupných riešení na trhu spomenieme dva Crystal Reports od Seagate a JReport od spoločnosti Jinfonet software. Obidva produkty umožňujú tvorbu reportov, počnúc špecifikovaním dátového zdroja cez získavanie (dolovanie) požadovaných dát z dátového zdroja a ich úpravu (napr:zoskupovanie, súčtovanie), až po výsledné formátovanie výstupnej zostavy. Typickým zdrojom dát, s ktorým tieto nástroje pracujú je relačná databáza, kde získavanie dát prebieha formou príkazov v štandardnom jazyku relačných databáz SQL. Užívateľ týchto produktov musí byť znalý databázovej problematiky (ako sú uložené dáta, v akých tabuľkách a ako ich z nich získať) ako aj samotných požiadaviek na zostavy, a teda musí často poznať detaily z tej oblasti, ktorej sa report dotýka (napr:daňové priznania). V tejto práci ukážeme, že sa priam núka takéto prirodzené delenie procesu prípravy reportu:

• práca dátového špecialistu
• práca tvorcu zostavy (používateľa).

Spomenieme ešte niektoré ďalšie črty týchto produktov, ktoré budú z nášho pohľadu zaujímavé:
Crystal Report verzia 8.5 a JReport verzia 4.0 už umožňujú narábať s XML dátami ako so zdrojom dát. Avšak XML dokument musí reprezentovať dáta akoby jednej tabuľky z relačnej databázy. Nemôžeme teda využiť bohaté možnosti jazyka XML na zachytenie ľubovoľných dátových štruktúr. Takýto plochý "tabuľkový" pohľad týchto nástrojov je zrejmý, pretože oba produkty v konečnom dôsledku pracujú (pomocou špeciálneho drivera) s XML dátami ako s tabuľkou z databázy, a tak celá ďalšia filozofia práce ostáva nezmenená. Crystal Report dokonca umožňuje pristupovať k XML dátam z viacerých XML dokumentov, ktoré umožňuje viazať ako tabuľky v SQL pomocou joinov. V nástroji spoločnosti Seagate, ktorá má so svojím nástrojom Crystal Report vedúce postavenie v oblasti reportingu, badať od verzie 8.0 veľkú podporu nových web štandardov. Či už je to spomínaná práca s XML ako dátovým zdrojom, ale aj ako jednou z možností výstupu a XML ako transportný formát, alebo podpora web prehliadačov ako prehliadačov reportov (kým do verzie 8.0 to boli ich vlastné klientské prehliadače ).

Ako sme už spomínali typickým dátovým zdrojom pre modelovanie reportov sú relačné databázy. Preto sme sa zamýšľali aj nad tým, ako využiť CASE systémy pri tvorbe reportov. CASE systémy umožňujú modelovanie informačných systémov, počnúc od zachytenia používateľských požiadaviek formou use case, cez modelovanie objektov, modelovanie stavových a sequence diagramov, dátové modelovanie až po generovanie zdrojového kódu do rôznych programovacích jazykov, či skriptov pre vytvorenie relačnej databázy. Dôležitou vlastnosťou týchto nástrojov je aj tzv. Reverse Engineering, ktorý umožňuje spätné rozpoznanie modifikovaných zdrojových kódov programu a zanesie zmeny aj do modelu v CASE systéme. CASE systémy sú založené na jazyku UML. Samotný jazyk len popisuje objekty modelovania, preto vznikli CASE systémy, ktoré umožňujú vizuálne používať tento jazyk pomocou rôznych grafických elementov a diagramov. Samozrejme v týchto nástrojoch je priestor pre bohatú dokumentáciu každej modelovanej položky. Tieto systémy na zachytenie návrhu aplikácie, pre svoje schopnosti kompexného návrhu, sú v súčasnosti nasadzované pri návrhu každého väčšieho projektu, databázy či objektového systému. Preto sme ich pôvodne chceli použiť aj v našej aplikácii a vytvoriť nástroj, ktorý by s pomocou CASE systémov a informácií v nich namodelovaných, umožňoval jednoduchým spôsobom modelovanie reportov. Neskôr sme sa však rozhodli pre zmenu metodiky tvorby reportov, dôvody rozoberáme v kapitole 5.XMLSchéma ako rozhranie. V súčasnosti sa ukazuje potreba tvorby výstupných zostáv nie len z tradičných dátových zdrojov (databáza) ale aj zo zdrojov ako napríklad objekty nejakej aplikácie či XML dokumenty. V tejto práci sme chceli ponúknuť nástroj aj pre tieto nové typy dátových zdrojov, preto sme začali uvažovať o XML dokumentoch ako o všeobecných dátových zdrojoch. Prijatím tohto konceptu konceptu však stratilo nasadenie CASE systémov a jazyka UML pri tvorbe nášho riešena zmysel, pretože CASE systémy neumožňujú modelovať XML Schému, popisujúci formát, k našim XML dátovým zdrojom. Aj tu sa však objavujú prvé návrhy, ako podchytiť návrh XML aplikácií, bližšie o riešení Davida Carlsona uvedieme v kapitole 5.XMLSchéma ako rozhranie.

Uvedomujeme si však, že za väčšinou XML dátových zdrojov budú dáta uložené v databáze (zachytenej obyčajne v CASE systéme) a dátový špecialista bude musieť vytvoriť XML Schému na základe požiadaviek tvorcu zostavy a poskytnúť tieto dáta vo forme XML vyhovujúcej vytvorenej XML Schéme. Je možné navrhnúť riešenie, ako sprístupniť informácie z CASE systému pre potreby modelovania a dokumentovania vytváranej XMLSchémy. Väčšina CASE systémov umožňuje export modelov vo formáte XMI - XML Metadata Interchange , dokonca niektoré pracujú s ním ako s natívnym formátom, napríklad volne šíriteľný nástroj Together. Hlavným cieľom návrhu formátu XMI bolo umožniť jednoduchým spôsobom výmenu metadát medzi rôznymi modelovacími nástrojmi založenými na UML. XMI je na formáte XML, čo uľahčuje jeho nasadenie aj využitie. V tomto formáte vieme získať z CASE systémov, kompletné informácie o namodelovaných projektoch, vrátane dokumentačných častí. Na obrázku nižšie vidíme jednoduchý objektový model v CASE Rational Rose, ktorý obsahuje iba jednu tiredu osoba. Všimnime si dokumentáciu k tejto triede.
1.Ukážka CASE Rational Rose

Na ďalšom obrázku vidíme vyexportovaný model osoby z predchádzajúceho obrázku. Skutočne obsahuje všetky namodelované informácie. Máme tu náš package nazvaný MojPackage, triedu Osoba aj jej popis, atribúty, metódu. Žiaľ je to pomerne rozsiahly XML dokument, preto na obrázku máme zachytenú iba ilustračne jeho malú časť.
2.Ukážka XMI formátu

Tak ako XMI aj XMLSchéma je XML dokumentom a tak by bolo možné vytvoriť nástroje, ktoré by umožnili jednoducho prepájať tieto dokumenty a získané informácie prezentovať v požadovanej forme. To však už presahuje rámer tejto práce, preto sme tieto nástroje neimplementovali a zamerali sme sa na vytvorenie nástrojov pre reporting.

XML (Extensible Markup Language) je univerzálny formát pre štruktúrované dokumenty a dáta na webe. Toľko hneď prvá veta na webe W3 konzorcia [ 2 ], ktoré je normotvorcom tohto formátu, v sekcii venovanej XML. Slovo markup hovorí, že sa ide o značkovací jazyk. Značkovacím jazykom je aj dobre známe HTML. Tak ako v HTML, aj v XML tvoríme dokument pomocou značiek (tagov). Pod značkou chápeme zápis

<meno_značky/>

takúto značku nazývame nepárová alebo zápis

<meno_značky
  meno_attribútu="hodnota atribútu">
  telo značky
</meno_značky>

pre párovú značku, kde hodnota atribútu musí byť ohraničená úvodzovkami alebo apostrofmi a telo značky obsahuje text alebo ľubovoľný ďalší počet značiek. Na rozdiel od HTML, kde prehliadač kódu "porozumie" aj keď párové značky nie sú pouzatvárané, prípadne sú značky prekrížené, v XML musíme tieto pravidlá striktne dodržiavať, inak to má za následok chybu pri parsovaní XML dokumentu. Tieto požiadavky nie sú samoúčelné, ale umožňujú rýchlo analyzovať (parsovať) syntax dokumentu pomocou parserov. [ 1 ]

3.Ukážka XML dokumentu

Na obrázku vidíme XML dokument, ktorý obsahuje časť tejto práce, konkrétne časť tejto kapitoly a zoznam literatúry. Značkovanie, ktoré tu vidíme bolo navrhnuté a použité konkrétne pre túto prácu. Môžeme si všimnúť, že pomocou značiek je štruktúrovaná táto práca takto:

Značka <chapter header="XML, XMLSchéma a XSL">... obsahuje celú kapitolu s nadpisom XML, XMLSchéma a XSL. Tá obsahuje niekoľko párových značiek <para>...</para>(reprezentujú odstavce), ktoré môžu obsahovať značky <ref/>,<code/>,<img/> reprezentujúce referenciu, zdrojový kód a značku pre obrázok. Na hlavnej úrovni (deti značky root) si môžeme všimnúť ešte ďalšiu značku <resources/>, ktorá obsahuje značkovanie popisujúce zdroje tejto práce. Všimnime si, že značky nám prirodzene tvoria akýsi strom. Toto značkovanie, zatiaľ nie je nijako obmedzené a značky môžeme ľubovoľne vnárať a používať. Jediné obmedzenie, ktoré nám kladie XML je, že musíme mať iba jeden koreň (prvá značka v strome).

Z dôvodov rozoberaných nižšie sa zavádza definícia značkovania DTD alebo XML Schéma, ktorá kladie obmedzenia na používanie značiek. DTD (Data Type Definition) je predchodca XML Schémy, ktorého syntax bola nevyhovujúca, prevzaná ešte z jazyka SGML.

4.Ukážka XML Schémy

Zavedním DTD alebo XML Schémy získavame určitú povolenú sadu značiek, ich atribútov a vnorených značiek, ktoré môžeme v XML dokumente používať. Tým špecifikujem nový jazyk na báze XML. Z obrázku vidieť, že aj XML Schéma je jazykom XML, čo bolo aj jednou z požiadaviek na vytvorenie tohto jazyka. Oproti DTD má XML Schéma ešte jednu hlavnú výhodu, môžeme v nej definovať jednoduché dátové typy, ako napr:String ale aj vlastné komplexné typy. Tak ako existujú parsery na prácu s XML dokumentom existujú aj validátory, ktoré umožňujú daný XML dokument rýchlo kontrolovať pomocou jemu asociovanej XML Schémy alebo DTD. To má veľký význam, hlavne ak uvážime možnosti uplatnenia XML ako formátu na výmenu dát medzi rôznymi aplikáciami.

Všimnime si, že v XML Schéme na obrázku začínajú všetky značky (tagy) prefixom "xs". XML umožňuje zavádzať tzv. namespaces. Každá značka v XML dokumente patrí nejakému namespace, ktorý musí byť definovaný ešte pred prvým výskytom, dvojicou prefix a identifikátorom, ktoré tento namespace popisuje. Tagy, ktoré sú bez prefixu, patria do defaultného namespace. Teda v XML dokumente môžem používať viacero rôznych značkovaní, ktoré sa líšia práve v namespace. Môžeme vytvoriť XML dokument, kde použijeme rovnakú značku <stock/>, len s iným prefixom. Napr:

<company:stock><my:stock/></company:stock>

Tiež môžeme pri jednom elemente (značke) použiť atribúty z rôznych značkovaní (namespaces).

<my:item my:id="001" company:id="00023"/>

Môžeme teda jednoducho používať už existujúce značkovania napr:HTML vo svojom formáte.

XSL (Extensible Stylesheet Language) je jazyk, ktorý umožňuje zápis pravidiel transformácie XML Dokumentu na iný XML alebo non XML dokument. Najčastejšie sa používa na zápis štýlov, pomocou ktorých prezentujeme XML Dokument na výstupných zariadeniach ako tlačiareň, HTML prehliadač, PDA zariadenie atď. Oproti CSS kaskádovým štýlom má oveľa bohatšie výrazové prostriedky. XSL štýl pozostáva zo šablón.

<xsl:template match="výraz">
    telo šablóny
</xsl:template>

Tie určujú ako sa značky z XML dokumentu majú transformovať. výraz špecifikuje pomocou XPATH štandardu [ 2 ], na akú značku môže XSL procesor aplikovať danú šablónu. Do tela šablóny môžeme zapísať rôzne značkovanie, ktoré chceme mať na výstupe.

Na obrázku vidíme XSL štýl, pomocou ktorého zobrazíme obsah tejto práce, z XML dokumentu, ktorý je popisovaný vyššie. (obr. 3 ) Všimnime si, že v XSL dokumente je opäť značkovanie založené na XML. Značky, ktorým rozumie XSL procesor majú prefix "xsl". Hneď za hlavičkou súboru je šablóna <xsl:template match="/">, ktorá sa vykoná ako prvá v každom XSL dokumente ak je uvedená, pretože XSL Procesor prechádza stromom XML dát a vyhľadáva vhodné šablóny na transformáciu a backslash značí prvú značku v XML strome, v našom prípade to je značka <root>. Táto šablóna nám vyrobí hlavičku HTML súboru, naimportuje kaskádové štýly CSS a iniciuje vykonanie šablóny pomenovanej "toc" - table of content. Šablóna toc vytvorí jeden span s id rovné "toc" a pre všetky značky <chapter> vytvorí príkazom <xsl:for-each select="//chapter">... span ktorý obsahuje číslo kapitoly, HTML linku na danú kapitolu a príkazom <xsl:value-of select="@header"/> aj prislúchajúci nadpis kapitoly.

6.Výsledok transformácie - HTML dokument

Výstupom transformácie je HTML dokument, ktorý tvoria odkazy na jednotlivé kapitoly. Na obrázku vidíme zdrojový kód, vygenerovaný naším XSL štýlom. Obrázok nižšie predstavuje už výslednú podobu v HTML prehliadači.

7.Výsledok transformácie v prehliadači

Nakoniec si ešte uvedomme, že XSL môžeme použiť nie len ako štýl, ktorý určuje vzhľad dokumentu ale môžeme ho aj využiť na transformáciu z jedného jazyka (značkovania) do druhého jazyka, čo aj v tejto práci využívame. Dá sa tak riešiť napríklad aj konverzia formátov medzi rôznymi verziami spravovaných dokumentov.

Ak začneme rozmýšľať o rôznych dátových zdrojoch pre reporting ako sú relačné databázy, XML dáta alebo dáta poskytované priamo objektami, vzniká otázka, ako k týmto dátam pristupovať cez jednotné rozhranie, ktoré by odclonilo rôznosť týchto zdrojov. Napr: Crystal Report pristupuje k XML ako k dátovému zdroju pomocou špeciálneho drivera, ktorý rozumie požiadavkám v SQL a sprístupňuje tvorcovi zostavy XML ako nejakú databázovú tabuľku, prípadne skupinu tabuliek. V tomto prípade by sme mohli brať za akési rozhranie samotný jazyk SQL. Nemyslíme si však, že takýto relačný - databázový pohľad na dáta bude vždy vyhovovať. Napríklad uvažujme o objektoch nejakej aplikácie ako o dátových zdrojoch, v takom prípade mapovať dáta do relačných tabuliek nevyzerá byť dobrou voľbou. Intuitívne cítime, že komplikovanejšie dátové štruktúry viac vystihuje bohatšie (nie "tabuľkové") XML. Navyše XML nám umožňuje svojím značkovaním viac udržať, ak je to potrebné, logickú štruktúru dát a je oveľa viac čitateľné pre laika (používateľa) ako nejaký dátový model relačnej databázy. Nie je problémom ani mapovať relačnú databázu do XML, aj keď nemyslíme si že to bude treba, a pomocou XML Schémy kontrolovať aj obmedzenia a referenčnú integritu. Z týchto dôvodov začíname uvažovať o XML ako o všeobecnom dátovom zdroji. Keďže XML Schéma nám umožňuje "typovať" XML dokument a kontrolovať správnosť XML dokumentu voči nejakému značkovaniu (štruktúre), vhodným rozhraním sa ukazuje XML Schéma.

Niektoré výhody XML Schémy ako rozhrania:

• XML formát
• možnosť špecifikovať typ dátových položiek ako napr:string
• možnosť jednoduchého validovania dát
• výrazovo bohatý jazyk, možnosť zachytiť ľubovoľnú dátovú štruktúru
• dokumentačný jazyk, obsahuje možnosť dokumentovať každú dátovú položku

Ako sme už skôr uviedli, zdá sa nám prirodzená deľba procesu prípravy reportu takáto:

• práca dátového špecialistu
• práca tvorcu zostavy (používateľa).

Voľba XML Schémy ako rozhrania nám to potvrdzuje. Tvorca zostavy nepotrebuje vedieť dátové záležitosti (napríklad: kde sú uložené dáta, v akom tvare či databáze), o to sa už postará dátový špecialista. Tvorca zostavy iba špecifikuje pomocou XML Schémy, aký XML strom dát potrebuje. Dátový špecialista ich upraví do požadovaného tvaru, zvaliduje pomocou XML Schémy a poskytne tvorcovi zostavy. Ten však nemusí čakať na skutočné dáta, stačí, že vie v akom tvare prídu (XML Schéma) a už môže tvoriť výstupnú zostavu, prípadne požiada o vygenerovanie ukážkových dát. Dáta preň v procese modelovania teda nie sú podstatné, zaujíma ho iba ich štruktúra prípadne dátové typy jednotlivých položiek. Takouto ďeľbou práce sa znižujú prehnané nároky na tvorcu zostavy (používateľa), ktorý je znalý problematiky, ktorej sa report dotýka. Dátového špecialistu zasa odbremeňuje od návrhu zostavy, ktorej nerozumie. Kladie naň jedine požiadavku sprístupnenia dát v jasne špecifikovanej podobe (pomocou XML Schémy). Samozrejme, že sa tvorba reportu nedá takto úplne striktne rozdeliť, ale XML Schéma je tu prvkom, ktorý nám spája dva pomerne samostatné procesy. Tu nám veľmi pomáha spomínaná schopnosť samopopisovania XML Schémy. Ostáva tu len otázka vhodného sprístupnenia tejto "dokumentácie" obom aktérom.

Riešení je viacero. Spomeniem aspoň nasledujúce riešenie Ralfa Schweigera PhD dostupné na adrese http://www.xsbrowser.com.
8.XSBrowser

Je to zaujímavý prehliadač DTD,XML Schém, ktorý sprístupňuje obsah XML Schémy, zobrazuje elementy a ich atribúty ako HTML linky, ktorými sa dostávame k obsahu daného elementu. V pravej časti zobrazuje dokumentačné informácie vytiahnuté z XML Schémy vzťahujúce sa k aktuálne vybranému elementu či jeho atribútu. Analyzovanie XML dokumentov a práca s nimi je tu riešená Java appletom. Preto je toto riešenie dostupné pre všetky HTML prehliadače podporujúce JavaScript a Java applety. Takýto alebo podobný prehliadač XML Schémy, by bol vhodný pre potreby oboch našich pracovníkov, ktorý potrebujú pracovať s XML Schémou.

Pre potreby tvorcu zostavy v našej aplikácii, tiež použijeme podobné riešenie s našou vlastnou funkčnosťou, ktoré však využije vstavaný XML parser prehliadača Microsoft Internet Explorer v6.0. Naše riešenie zobrazí XML Schému ako strom dostupných elementov, ich atribútov a bude rozšírené o možnosť aktívne pracovať s XML Schémou v procese modelovania zostavy (drag and drop dátových položiek).

Ďalej nás bude iste zaujímať ako modelovať XMLSchému, aj tu sa núka hneď niekoľko riešení. Jedným z momentálne najlepších editorov, podporujúcich modelovanie XMLSchémy, je známy XMLSpy, ktorý vidíme na obrázku nižšie. Umožňuje modelovať, validovať XMLSchému podľa poslednej verzie štandardu. Jednou zo zaujímavých vlastností je generovanie XMLSchémy podľa dodaného XML dokumentu. Samozrejme takto generovaná XML Schéma nie je vždy postačujúca ale návrh XMLSchémy sa takto značne zrýchli a uľahčí.
9.XMLSpy

Ďalej by sme sa chceli zmieniť o zaujímavom návrhu Davida Carlsona, ktorý publikoval vo svojej knihe Modeling XML Applications with UML. [ ] Okrem iného v nej navrhol spôsob ako modelovať XMLSchému pomocou jazyka UML. Je to zaujímavá myšlienka, ktorá žial ešte stále nie je podporená v dostupných CASE systémoch. Vychádza z možností objektového návrhu v CASE systémov a modeluje XML Schému ako množinu prepojených objektov, kde jedna trieda/objekt zvyčajne predstavuje jeden element cieľového XML popisovaného danou XML Schémou. Na obrázku vidíme namodelovanú XML Schému jazyka PSML Portal Structure Markup Language, ktorým je možné zachytiť definíciu portletov v projekte Apache Jetspeed.
10.UML model predstavujúci XMLSchému k PSML

Na adrese http://www.xmlmodeling.com je po zaregistrovaní dostupný nástroj hyperModel, ktorý dokáže pracovať s takto namodelovanou XML Schémou, exportovanou z CASE systému do formátu XMI. Výsledkom tohto nástroja môže byť platná XMLSchéma alebo je možné túto XMLSchému v prehliadači, ktorý zobrazuje dokumentačné položky z XML Schémy. Na ďalšom obrázku vidíme už konkrétne XML, ktoré vyhovuje vyššie namodelovanej XMLSchéme.
11.Ukážka PSML

V predošlej kapitole sme sa zaoberali XML Schémou ako rozhraním, ktoré delí proces prípravy reportu na dve časti: prípravu dát a prípravu prezentácie dát. Proces prípravy dát závisí najmä od typu použitého dátového zdroja, preto sa nedá jednoducho zovšeobecniť. Každý dátový zdroj má svoje špecifiká a je potrebné zohľadniť rôzne prístupy. Ak sa jedná o databázu, najčastejším spôsobom získavania dát bude použitie klasických reportovacích nástrojov, napríklad už spomínaný Crystal Report. Nesmieme však zabúdať na to, že databáza je často iba skladom dát a potrebné dátové vzťahy sú dodané až objektami nejakej aplikácie. V takom prípade je potrebné exportovať dáta priamo z objektov danej aplikácie. Aj pri XML ako dátovom zdroji je niekedy potrebné dáta transformovať na XML dáta vhodné pre reporting, či už zahrnutím ďalších externých zdrojov alebo zjednodušením zložitej štruktúry, či poskytnutím iného pohľadu na tie isté dáta. Napríklad môžeme mať XML, ktoré popisuje študentov a ich vyučujúcich a požiadavku na dva rôzne reporty. Jeden bude prehľadom vyučujúcich a počtu študentov, ktorých učia. Druhý prehľadom študentov a vyučujúcich, ktorí ich učia. Vidíme, že v prvom prípade by nám vyhovovali XML dáta zoskupené najprv podľa vyučujúcich, v druhom prípade naopak najprv podľa študentov.

Ak sa uchýlime k XML ako všeobecnému dátovému zdroju a k XML Schéme, ktorá ho popisuje, ako k rozhraniu môžeme pracovať na spoločnom riešení druhej časti tvorby reportu: prípravy prezentácie dát. V tejto práci sa preto ďalej zameráme na druhú časť, teda prácu tvorcu reportu. Na obrázku máme zachytený proces prípravy prezentácie reportu. Je rozčlenený na tri fázy

• modelovanie
• generovanie
• spúšťanie zostavy (reportu)

z toho iba prvá prebieha v interakcii s tvorcom reportu. Všimnime si, že XML Schéma je vstupom do fázy modelovania a generovania a XML dáta sú vstupom iba do koncovej fázy spúšťania reportu.
12.Proces modelovania, generovania a spúšťania reportu

V tejto fáze tvorca reportu navrhuje vzhľad výstupnej zostavy, rozmiestňuje dátové polia, volí formátovanie, nastavuje štýly a podobne. Pre túto fázu máme napísanú aplikáciu Report Designer. Je to vizuálny nástroj, ktorý umožňuje modelovať výstupné zostavy, bližšie sa naň z hľadiska funkčnosti i implementácie pozrieme v ďalšej kapitole. Teraz je potrebné si uvedomiť, že vstupom do Report Designéra je XML Schéma, ktorá popisuje XML dáta, z ktorých chceme vyrobiť report. Výstupom je interná definícia reportu v XML formáte.

Pre generovanie je opäť potrebná XML Schéma a namodelovaná zostava zachytená v XML definícii reportu. Výsledkom tejto fázy je XSL štýl, ktorým možno požadované dáta prezentovať v namodelovanom tvare. Výsledkom následnej transfomácie pri spúšťaní reportu je HTML dokument, ale pri takto zvolenom koncepte generovania a modelovania je možné jednoducho vytvoriť a použiť generátory XSL štýlov, ktoré transformujú aj do iných používaných formátov napr:PDF,RTF a podobne. Táto fáza prebieha na strane servera, používateľ už do nej aktívne nevstupuje. Viac o tejto fáze uvedieme v kapitole 8.Generovanie a spúšťanie zostavy.

V poslednej fáze spájame vygenerovaný XSL štýl s XML dátami. Transformácia prebieha obyčajne na strane servera klient dostáva odpoveď - report vo forme HTML dokumentu, ktorý je výsledkom transformácie. Iniciátorom tejto fázy je obyčajne koncový uživateľ, ktorý si volí požadovaný report z repozitára reportov a špecifikuje prípadné parametre vyplnením nejakého HTML formulára. Spustiť report ale môže aj nejaký proces, ktorý zaregistruje výtlačok (výsledok) reportu do nejakého repozitára a podobne.

Cieľom tejto práce je navrhnúť a implementovať nástroje na modelovanie a generovanie výstupných zostáv a na vybranom príklade ilustrovať ich použitie. V tejto kapitole predstavíme vizuálny nástroj pre tvorbu reportov nazvaný Report Designer, popíšeme hlavné črty, možnosti a výhody tohto nástroja. Zmienime sa aj o niektorých zaujímavých implementačných problémoch a na jednoduchom príklade rozvrhu ukážeme jeho použitie.

Report Designer je web aplikácia. Podrobnejšie sa o architektúre a systémových požiadavkách zmienime v kapitole 9.Systémové požiadavky, teraz len krátko. Na serveri je repozitár namodelovaných reportov a dostupných XML dátových zdrojov a ich XML Schém. Používateľ môže na vyžiadanie upravovať namodelované zostavy, vytvárať nové zostavy a dopĺňať dátové zdroje, poskytnutím XML Schémy a ďalších potrebných informácií. Celá aplikácia môže byť jednoducho začlenená do nejakého podnikového systému, intranetu, odkiaľ je možné prevziať aj autorizačné informácie, a tak podmieniť prístup k jednotlivým funkciám, či reportom a dátovým zdrojom. Na klientskej strane je potrebný HTML prehliadač, ktorý podporuje nové web technológie, čo je značnou výhodou, pretože nie je nutné inštalovať špeciálneho klienta a navyše keďže je to web aplikácia je toto riešenie dostupné kdekoľvek z internetu. Terajšie riešenie je postavené na prehliadači firmy Microsoft Internet Explorer 6.0 a technológiách HTML, CSS, JavaScript, DHTML, HTC, XML, XSL. [ 2 ] [ 3 ]

Zastavme sa pri technológii HTC - HTML komponentoch, ktoré boli použité pri programovaní klienta. HTML komponenty rozširujú zaujímavým smerom prácu s DOM - dokument object model a DHTML, umožňujú rozšíriť sadu povolených značiek v HTML a prisúdiť im vlastné chovanie. Môžeme tak zapuzdriť požadovanú funkčnosť, a takýto komponent veľmi jednoduchým spôsobom opätovne využívať. Na obrázku je príklad komponentu kontextového menu. Všimnime si ako jednoducho môžeme toto menu vytvoriť.
13.Ukážka HTML komponenty - kontextové menu

Značka <UI:POPUP_MENU>... nám príslušné menu vytvorí, a pritom okrem identifikátora a akéhosi vnoreného xml, ktoré hovorí, čo má byť v danom menu, nič viac neobsahuje. Implementácia tejto funkčnosti je skrytá v importovanom súbore

<?IMPORT NAMESPACE="UI" IMPLEMENTATION="popup.htc">

Stručný náčrt implementácie vidíme na ďalšom obrázku.
14.Ukážka zdrojového kódu - popup.htc

Vidíme, že môžeme čítať a nastavovať PROPERTY, to sú atribúty našej značky

<UI:POPUP_MENU atribút="hodnota property">...

METHOD metódy nášho komponentu - značky, ktoré môžeme vyvolať z JavaScriptu dokonca ATTACH, EVENT môžeme zachytávať a vytvárať udalosti. (napr: pohyb myšou je udalosť). Náš komponent môže obsahovať akoby vlastnú HTML stránku, ktorá sa zahrnie do hlavnej stránky. Používaním týchto HTML komponentov je kód prehľadnejší, riešia sa možné konflikty v JavaScripte a máme možnosť efektívne znovu využívať naprogramovaný kód. [ 3 ]

Skôr ako popíšeme XML Schéma Viewer, pozrime sa na nasledujúce obrázky. Tie zobrazujú jednoduché XML dáta k rozvrhu a príslušnú XML Schému. Z týchto dát neskôr vyrobíme report - rozvrh hodín. Ak neuvedieme inak, v prípade, že budeme písať o XML dátach a XML Schéme, tak budeme myslieť tieto dokumenty.
15.XML dáta - rozvrh


16.XML Schéma - rozvrh

XML Schéma Viewer (ďalej len XSV) je HTML komponent, ktorý nám umožňuje pracovať so schémou ako so stromčekom značiek. Ďalší obrázok nám dokumentuje našu XML Schému zobrazenú vo XSV. Aj keď možností ako zapísať XMLSchému pre nejaký dokument je viacero, XSV ju zobrazuje stále ako ten istý stromček, pretože pre bežného používateľa je to asi najprijateľnejší spôsob. Samozrejme XML Schéma poskytuje značné možnosti, ale my uvažujeme o schémach, resp. XML dátach vhodných pre reporting a v týchto prípadoch nečakáme nejaké veľmi náročné konštrukcie. A tak hnedá ikonka predstavuje element, zelená atribút elementu, ku ktorému sa viaže. Zdvojená hnedá ikonka predstavuje iteráciu (povolený výskyt viacero rovnakých značiek ako súrodencov) a nakoniec ikonka so šípkou naznačuje, že ide o referovaný element (takto je možné rekurzívne vytvoriť strom ľubovoľnej hĺbky).
17.Prehliadač XML Schém

Ďalším základným komponentom Report Designera je Modeler tabuľky (MT), ktorý umožňuje vizuálne modelovať HTML tabuľku, pridávať, odoberať stĺpce, riadky, vnorené tabuľky, vymieňať bunky, ich obsah, presúvať celé riadky, spájať, rozdeľovať bunky. Keďže reporty sú zväčša tabuľkovo orientované, pre tvorcu reportu je HTML tabuľka základným stavebným prvkom. MT poskytuje sadu metód, ktorými možno pristupovať k elementom tabuľky, tak možno nastaviť CSS štýly a atribúty. Ale nie len to, MT umožňuje vložiť nejaké HTC komponenty a priamo ich vkladať do buniek tabuľky. Tak možno vložiť do tabuľky aj textové elementy, alebo tzv. dátové polia, to je obsah elementov alebo atribútov nášho XML dokumentu. Tie môžeme vkladať do tabuľky drag and drop priamo z XSV.
18.Panel nástrojov pre tabuľku


19.Nastavenie štýlu pre element

Z predchádzajúceho plynie, že v MT môžeme pracovať na úrovni buniek tabuľky, ale aj na úrovni vložených elementov. Skutočne je to tak, na prvom obrázku máme vybranú (vyselektovanú) bunku, ktorá obsahuje text "Deň/Hodina", a na nej robíme operáciu - vkladáme stĺpec. Na druhom obrázku pracujeme s vloženým elementom, textom "Deň/Hodina", nastavujeme mu CSS štýl. Všimnime si ešte namodelovanú tabuľku, obsahuje tri riadky v prvom dátové polia $name$, $year$. V druhom riadku je vložený text "Deň/Hodina" a ďalšie dátové pole, podobne v treťom. Dátové položky teda máme rozmiestnené, štýly nastavené, zostáva už len vyznačiť iterácie.

Nebol by to report, ak by sa tam niečo neopakovalo. Ako sme už spomenuli, iterovateľné dátové polia sú v XSV označené zdvojenou hnedou ikonou. To však nestačí pre vygenerovanie XSL šablóny potrebujeme mať informáciu, ktoré namodelované elementy patria k danej iterácii, resp. ktoré namodelované elementy a ich obsah majú iterovať spolu s dátami. Na obrázku vidíme, že priradiť element tabuľky nejakej iteráci,i môžeme veľmi jednoducho pomocou kontextového menu. Na každý element v tabuľke vieme takto nastaviť jej príslušnosť jednej alebo viacerým iteráciám.
20.Nastavenie iterácie na element

Na ďalšom obrázku vidíme zoznam všetkých iterácií, kde v dialógovom okne Iterácie pole Položka predstavuje dátovú položku z XMLSchémy, cez ktorú bude daná iterácia iterovať. Kliknutím na ikonu naľavo môžeme zobraziť, ktoré elementy patria danej iterácii. V MT sa daným elementom zvýrazní pozadie farbou, ktorú máme definovanú pri danej iterácii. Kvôli CSS štýlom, však nie vždy je toto zvýraznenie možné, preto treba použiť tlačidlo z nástrojovej lišty, ktoré nám umožní potlačiť zobrazovanie CSS štýlov.
21.Modelovanie iterácií

Pre každú iteráciu sa drží zoznam (kolekcia) elementov tabuľky, ktoré obsahuje. Na obrázku máme namodelované tri iterácie. Prvá days iteruje cez položku day v XML dátach pozri (obr. 15 ), na obrázku je vyznačená modrou farbou a obsahuje jediný element tabuľky, tretí riadok (TR). To znamená, že pre každú značku <day/> (pondelok, utorok...) sa vo výstupnej zostave vytvorí jeden riadok tabuľky. Druhá iterácia je na obrázku vyznačená hnedou farbou a je vnorená do prvej. Obsahuje bunku (TD) riadka tabuľky, ktorý patrí predchádzajúcej iterácii. Táto iteruje cez značky <hour/>

<day title="pondelok">
  <hour title="8.00"/>
  <hour title="9.00"/>
  ...
</day>

vnorené v značke <day/>. Vo výstupnej zostave sa pre každú značku <hour/> vytvorí jedna bunka tabuľky s príslušným obsahom. Posledná iterácia nám slúži na zobrazenie hodín v predchádzajúcom riadku pre každý stĺpec tabuľky, v ktorom sa nachádzajú rozvrhované akcie. Z toho plynie, že druhá iterácia by mala mať najviac taký počet značiek v XML dátach ako posledná.

Ako sme už spomínali, namodelovaná zostava sa ukladá do interného XML formátu, ktorý sa použije pri generovaní výstupnej zostavy. Keďže ide o XML dokument, samozrejme je k nemu aj XML Schéma, ktorá je k dispozícii v dvoch súboroch tw.xsd a base.xsd v prílohe tejto práce. Ako ukážeme, práve s týmito súbormi pracuje Report Designer pri nastavovaní vlastností elementov tabuľky a ukladaní zostavy. Táto XML Schéma sa teda využíva nie len na kontrolu a validáciu (prípadne verziovanie), či daný XML dokument je skutočne správne namodelovanou výstupnou zostavou, ale slúži aj pre vnútornú potrebu Report Designera. Komponent na ďalšom obrázku nám umožňuje nastavovať vlastnosti jednotlivých elementov tabuľky na základe spomínaných schém, povolí nastaviť len tie atribúty, ktoré XMLSchéma skutočne obsahuje. Takto môžeme jednoducho rozširovať možnosti nastavovania atribútov elementov v Report Designer tým, že tieto atribúty doplníme do XML Schémy.
22.Nastavenie vlastností

Všimnime si naviac atribúty s prefixom TW. Tieto atribúty musia obsahovať validný XPATH výraz a vyhodnotia sa až pri spúšťaní výstupnej zostavy. Takto môžeme celkom správne špecifikovať colSpan=2 na prvej bunke v prvom riadku tabuľky pri modelovaní zostavy, ale TW:colSpan by mal mať hodnotu počtu hodín v XML dátach plus jedna, čo skutočne výrazom count(//hours/hour)+1 aj dostaneme.

Aby sme mohli s namodelovanou zostavou ďalej jednoducho pracovať, zvolili sme si na jej uloženie XML formát, ktorého ukážku vidíme na obrázku. Všimnime si, že obsahuje dve značky na hlavnej úrovni <LAYOUT>, tá nesie informácie o vzhľade zostavy a <ITERATIONS> obsahuje informácie o namodelovaných iteráciach. Obsah značky <ITERATIONS> si rozoberieme v ďalšej kapitole 8.Generovanie a spúšťanie zostavy, kde aj ukážeme jej použitie v procese generovania. Teraz si bližšie všimnime značku <LAYOUT>, tá obsahuje HTML definíciu tabuľky s nastavenými CSS štýlmi a atribútmi. Je obohatená o atribúty a elementy s prefixom TW. Atribúty s prefixom TW a ich význam sme už rozoberali vyššie a elementami môžu byť len <TW:DATAFIELD_ELEMENT> a <TW:TEXT_ELEMENT>. Prvý element predstavuje dátovú položku, ktorú sme umiestnili drag and drop z XSV do tabuľky a druhý predstavuje HTML formátovaný text. Uvedomme si ešte, že tieto elementy sú HTML komponenty vložené do MT a teda obsah značky <LAYOUT> môže browser jednoducho bez akejkoľvek ďalšej inicializácie zobrazovať. Pri ukladaní layoutu zostavy, tak ako aj pri komponente na prácu s atribútmi elementov, využívame XML Schému interného formátu zostavy. Ukladajú sa tak skutočne iba v XML Schéme povolené HTML atribúty a navyše naše špeciálne atribúty s prefixom TW.
23.Interný XML formát pre uloženie namodelovanej zostavy

Namodelovaná zostava je uložená v repozitári na serveri. Na požiadanie sa z danej zostavy a príslušnej XMLSchémy na strane servera vygeneruje XSL štýl. Generovanie je naprogramované v Jave a zapuzdrené v JSP. Využité sú aj JSP tag library pre prácu s XML dokumentom a pre XSL transformácie. Na XSL transformácie je použitý Xalan - XSLT stylesheet processors in Java a na prácu s XML s Xalanom dodaný XML parser. Oba vstupné dokumenty i výstupný XSL štýl sú v XML formáte, preto celé generovanie je práca s XML DOM. Na prácu s XML DOM v Jave je použitý štandardný balík org.w3c.dom.
24.Zachytenie iterácií

Na obrázku máme namodelovanú zostavu v internom XML formáte. Pozrime sa teraz bližšie na obsah značky <ITERATIONS>, ktorá nesie dôležité informácie pre generovanie iterácií. Každá zo značiek <ITERATION> predstavuje jednu namodelovanú iteráciu z Report Designera. Každá iterácia má okrem mena, farby a vlastného idetifikátora aj zoznam elementov, atribút elements, kde má uvedené identifikátory všetkých elementov z HTML tabuľky, ktoré patria danej iterácii. Z obrázku vidno, že iterácii days patrí iba posledný riadok tabuľky element s id rovné 1004580210275. Podobne iterácii innerHours patrí bunka tabuľky s patričným id. Na základe týchto informácií vytvoríme príkazy <xsl:for-each select="..."> pre každú iteráciu tak, ako to vidno na ďalšom obrázku vygenerovaného XSL štýlu.
25.Vygenerovaný XSL štýl

Nižšie uvedený kód nám zabezpečí spomínané nahradenie hodnoty atribútov napr:colSpan za TW:colSpan. V prvom riadku získame NodeList attrs všetkých atribútov, ktoré majú prefix TW v XML dokumente data, čo je XML dokument našej namodelovanej zostavy, pozri (obr. 24 ). V cykle prejdeme cez všetky Node xnode v attrs a nájdeme ich rodičov Node pnode a lokálne meno localName, čo je meno bez prefixu TW. Získame referenciu na atribút Attr attr od rodiča pnode podľa lokálneho mena a nasadíme mu hodnotu atribútu s prefixom xnode uzavretú v zložených zátvorkách. Nakoniec odstránime atribút s prefixom xnode.

NodeList attrs = XPathAPI.selectNodeList(data,"//@TW:*");
Node xnode, pnode;
String localName;
Attr attr;

for(int j=0; j<attrs.getLength(); j++){
  xnode=attrs.item(j);
  pnode = (Node) ((Attr) xnode).getOwnerElement();
  localName = xnode.getLocalName();

  attr = ((Element) pnode).getAttributeNode(localName);
  attr.setValue("{" + xnode.getNodeValue() +"}");
  ((Element)pnode).removeAttributeNode(((Attr)xnode));
}

Predchádzajúci kód teda napríklad z pôvodného

<TD colSpan="2" TW:colSpan="="count(//hours/hour)+1)" ...

vytvorí

<TD colSpan="{count(//hours/hour)+1)}" ...

zložené zátvorky hovoria, že ide o XPATH výraz, ktorý sa bude interpretovať.

Na obrázku (obr. 24 ) si ešte všimnime elementy <TW:DATAFIELD_ELEMENT>, tie predstavujú dátové položky. Výber skutočných hodnôt z XML dát týchto dátových položiek v XSL štýle zabezpečí nasledujúci kód. V cykle si postupne pre všetky dátové položky dataFields pripravíme pomocný node xsl:value-of s namespace, ktorý hovorí, že ide o XSL príkaz. Metódou getPath(...) získame cestu k danému elementu v XML dátovom strome na základe XML Schémy a aktualného kontextu (iterácie). Nastavíme atribút select pomocneho node na hodnotu path a nahradíme ho za pôvodný element. Výsledkom teda bude napríklad <xsl:value-of select="root/organization/year" />.

String path;
Element pom;
Node tmpNode;
NodeList dataFields;

Node root=XPathAPI.selectSingleNode(data,"//ROOT");
dataFields=XPathAPI.selectNodeList(((Node) it), ".//TW:DATAFIELD_ELEMENT", root);
try{
  //pretvorim TW:DF
  for(int i=0; i<dataFields.getLength();i++){
    tmpNode=dataFields.item(i);
    pom=data.createElementNS("http://www.w3.org/1999/XSL/Transform", "xsl:value-of");
    path=getPath(((Element) tmpNode).getAttribute("refId"), itPath, schema)
    pom.setAttribute("select", path);
    tmpNode.getParentNode().replaceChild(((Node)pom), tmpNode);
  }
}catch(Exception e){
  System.err.println(e);
}

Takýmto spôsobom je vygenerovaný celý XSL štýl na obrázku (obr. 25 ), ktorý sa potom použije na vytvorenie výstupnej zostavy. Ak si používateľ vyžiada spustenie zostavy, vyberie sa tento XSL štýl z repozitára spojí sa s príslušnými XML dátami a výsledok transformácie sa zašle ako odpoveď.
26.Namodelovaná zostava

Na týchto dvoch obrázkoch vidíme už výsledok spustenia reportu nad našimi XML dátami (obr. 15 ) v HTML prehliadači na obrázku dole a na hornom obrázku vidíme, ako je namodelovaná táto zostava v prostredí Report Designera.
27.Výstupná zostava

Výstupom však nemusí byť iba HTML dokument. Použitím iných generátorov XSL štýlov môžeme generovať aj do formátov ako napr: PDF,RTF.

Celé riešenie je web aplikácia, preto požiadavky na prevádzku systému sú minimálne. Pre jednoduchú inštaláciu bol na klientskej strane kladený veľký dôraz na využitie možností internetového prehliadača bez ďalších rozšírení. Server je postavený na Open Source produktoch.

• Server
  • Hardware:Pentium III 800MHz, 256MB RAM
  • Software:
    • Windows NT (Linux)
    • JVM - Java virtual machine
    • Tomcat 3.1.2 (HTTP Server + JSP a Servlets engine)
  Aplikácia bola odladená na Windows platforme, ale keďže serverovská časť je napísaná v Jave dá sa portovať aj na Linux a iné platformy.
• Klient
  • Hardware:Pentium 233MHz, 128MB RAM
  • Software:
    • pre modelovanie:
      • Windows 98+
      • Microsoft Internet Explorer 6.0
      Pod Windows 95 je možné použiť Microsoft Internet Explorer 5.5, je však potrebné doinštalovať Microsoft XML parser verzie 3.0 v replace mode.
    • pre spúšťanie výstupných zostáv:
      • Windows, Linux, Mac, Unix
      • MSIE, Netscape, Mozilla, Opera
      Akýkoľvek HTML prehliadač s podporou CSS level 2. Zostavy boli testované pod Win/MSIE.

Pre lepší výkon možno použiť Apache web server so zavedením Tomcatu ako modulu. Tomcat bol obohatený o javovský projekt Xalan, java balík javax.servlet a XML,XSL taglib knižnice.