XIQE/Interfaces

< Zpět na XIQE
Za tuto oblast zodpovídá Zdeněk Zikán.

Úvod

Sem budu průběžně dávat to, co sepíšu. Dělám to v DocBooku a z něj generuji Wiki, takže pokud budete chtít něco opravit, tak to napište do sekce Připomínky, abych to vzápětí nepřepsal novější verzí.

--Zdeněk Zikán

Připomínky

[sem pište svoje připomínky]

Úvod

XML je jazyk, který je v současnosti velice populární pro svou flexibilitu a používaný v nejrůznějších oblastech. Jedná se o jazyk pro sloužící pro značkování dat a je vhodný hlavně tehdy, když mají data hierarchickou strukturu. Pro potřeby ověření různých metod indexování XML dat a zjištění jejich efektivity vznikl projekt XIQE (XML Indexing and Querying Engine). Více informací o XIQE je možné nalézt v diplomové práci jeho autorky Ada01.

Účelem této práce je umožnit použití XIQE nejen jako experimentálního systému, ale také jako XML databáze a navrhnout tedy rozhraní pro použití systému „z vnějšku“, tak, aby uživatel mohl systém využívat bez znalosti jeho fungování a architektury.

Existující aplikační rozhraní pro práci s XML v jazyce Java

Java API for XML Processing (JAXP)

Java API for XML Processing

je sada několika API vybraných jako základní, nejdůležitějších API pro zpracování XML v Javě. Od verze Javy 1.5 je JAXP 1.3 součástí Java Core API. Z tohoto důvodu zde uvádím přehled a stručný popis tříd, které jsou součástí JAXP.

javax.xml*

javax.xml

Balík javax.xml obsahuje jedinou třídu a to XMLConstants, která definuje pouze konstanty (statické finální atributy typu String), často používané v XML dokumentech, například URI různých často používaných jmenných prostorů (XMLSchema, RelaxNG, XMLNS) či prefixy definované specifikací XML.

javax.xml.datatypes

Poskytuje mapování typů vyjadřujících datum v Javě a XML.

Obsahuje třídy:

• DatatypeConstants — obsahuje konstanty používané v operacích s datem.

• DatatypeConstants.Field — typově bezpečná výčtová třída reprezentující šest polí třídy Duration (viz dále).

• DatatypeFactory — tovární třída umožnující vytvářet instance tříd Duration a XMLGregorianCalendar (viz dále).

• Duration — třída reprezentující časové intervaly podle W3C XML Schema 1.0 a implementující různé operace nad nimi (porovnávání, sčítání, …).

• XMLGregorianCalendar — třída reprezentující „kalendář“; umožňuje nastavit datum a čas a z nich získat buď XML reprezentaci, nebo instanci třídy java.util.GregorianCalendar, umožňující pokročilejší práci s datem a časem.

• Výjimku DatatypeConfigurationException.

javax.xml.namespaces

Umožňuje práci s jmennými prostory XML.

Obsahuje rozhraní NamespaceContext sloužící k získání prefixu (resp. prefixů) daného URI nebo URI daného prefixu a třídu QName reprezentující tzv. kvalifikované jméno elementu, tj. identifikátor, skládající se ze jména, prefixu a URI.

javax.xml.parsers

Poskytuje třídy umožňující zpracování XML dokumentů.

• DocumentBuilder — slouží k převedení řetězcové reprezentace XML dokumentu na DOM reprezentaci (instanci třídy org.w3c.dom.Document).

• DocumentBuilderFactory — tovární třída pro vytváření parserů (instancí třídy DocumentBuilder) s různým nastavením — lze určit, jestli má být parser validující, má brát v potaz komentáře, jmenné prostory, má ignorovat ignorovatelné bílé místo apod.

• SAXParser — abstraktní třída definující API, které „obaluje“ třídy implementující org.xml.sax.XMLReader.

• SAXParserFactory — abstraktní třída definující API pro získání pro konfiguraci a vytvoření objektu typu SAXParser.

• Třídu výjimky ParserConfigurationException a chybovou třídu FactoryConfigurationError.

javax.xml.transform

Definuje obecná API pro zpracování transformačních instrukcí a transformaci.

Rozhraní:

• ErrorListener — umožňuje vytvořit vlastní ošetření chyb při transformaci. Instanci třídy implementující toto rozhraní je možné zaregistrovat pomocí metody setErrorListener třídy Transformer.

• Result — objekt implementující toto rozhraní obsahuje informace potřebné pro vytvoření stromu výsledku transformace. Toto rozhraní je implementováno (v Java Core API) třídami DOMResult, SAXResult a StreamResult.

• Source — objekt implementující toto rozhraní obsahuje informace potřebné pro jeho použití pro vstup (XML soubor nebo transformační instrukce). Toto rozhraní je implementováno (v Java Core API) třídami DOMSource, SAXSource a StreamSource.

• SourceLocator — slouží především pro účely označení místa (v XML souboru nebo transformačních instrukcích), kde došlo k chybě. Toto rozhraní je implementováno (v Java Core API) třídou DOMLocator.

• Templates — objekt implementující toto rozhraní je „runtime“ reprezentací zpracovaných transformačních instrukcí. Pomocí metody newTransformer se pak vytvoří objekt Transformer (viz dále).

• URIResolver — objekt implementující toto rozhraní může být zavolán transformačním procesorem k získání objektu Source odpovídající danému URI (použitém v document(), xsl:import nebo xsl:include).

Třídy:

• OutputKeys — poskytuje řetězcové konstanty pro nastavení výstupních vlastností objektu Transformer, nebo získání výstupních vlastností objektu Transformer nebo Template. Např. konstanty

• Transformer — abstraktní třída. Instance její podtřídy provádí transformaci zdrojového stromu na cílový. Transformer může být použit opakovaně a jeho nastavení se mezi jednotlivými transformacemi zachovává (pokud ho nepřenastavíme). Objekt typu Transformer by se neměl používat ve více souběžně spuštěných vláknech najednou. Různé instance typu Transformer mohou být použity ve více souběžných vláknech.

• TransformerFactory — tovární třída pro vytváření objektů typu Transformer a Templates.

• Výjimky TransformerConfigurationException a TransformerException a chybovou třídu TransformerFactoryConfigurationError.

javax.xml.transform.dom

Implementuje API specifické pro DOM.

Obsahuje rozhraní DOMLocator, třídy DOMResult a DOMSource, jejichž funkce je zřejmá (viz jim příslušná rozhraní SourceLocator, Result a Source v balíku javax.xml.transform).

javax.xml.transform.sax

Implementuje API specifické pro SAX2.

Rozhraní:

• TemplatesHandler — umožňuje vytvoření objektů typu Templates z událostí SAX2. Je potomkem org.xml.sax.ContentHandler a může být tedy použit na jeho místě. Poté, co přijdou všechny SAX události, objekt Templates může být vytvořen pomocí metody getTemplates().

• TransformerHandler — je potomkem org.xml.sax.ContentHandler, org.xml.sax.DTDHandler a org.xml.sax.ext.LexicalHandler.

Třídy:

• SAXTransformerFactory — abstraktní třída rozšiřující TransformerFactory a poskytující tovární metody specifické pro SAX. Umí vytvářet objekty TransformerHandler a TemplatesHandler (obojí potomky ContentHandler) a XMLFilter.

• SAXResult — verze Result specifická pro SAX. Pokud je mu předán ContentHandler, je nastaven pro příjem SAX2 událostí z transformace.

• SAXSource — verze Source specifická pro SAX. Umožňuje nastavit vstupní zdroj InputSource a XMLReader, který jej bude číst. (Obojí viz org.xml.sax.)

javax.xml.transform.stream

Implementuje API specifické pro streamy a URI.

Třídy:

• StreamResult — reprezentuje výsledek transformace (XML, čistý text, HTML, nebo jiný značkovaný text).

• StreamSource — reprezentuje zdroj transformace.

javax.xml.validation

Poskytuje API pro validaci XML dokumentů, tedy ověření toho, že daný XML dokument je instancí daného XML schématu. Toto API umožňuje odděluje validaci XML dokumentu od jeho parsování, díky čemuž je možné použít různá schémata pro validaci (DTD, W3C XML Schema, RelaxNG) a jednoduše spolu za běhu párovat XML dokumenty a schémata.

Třídy:

• Schema — reprezentuje schéma, tedy gramatiku, sadu omezení, na která je XML dokument testován. Třída je neměnitelná a vláknově bezpečná. Instance se vytváří obvykle pomocí SchemaFactory, odvozené podtřídy však mohou používat i konstruktor (protected).

• SchemaFactory — tovární třída pro vytváření Schema objektů. Jedná se o kompilátor schémat, který přečte externí reprezentaci schématu a převede ji do podoby použitelné pro validaci. Po načtení schématu je pomocí URI jeho jmenného prostoru určeno, o jaký se jedná jazyk. SchemaFactory není vláknově bezpečná a reentrantní, tzn. nesmí být použita z více než jednoho vlákna najednou a pokud běží metoda newSchema, nesmí být znovu rekurzivně volána.

• SchemaFactoryLoader — tovární třída pro vytváření objektů SchemaFactory. Tato třída je určená pro použití validačními API.

• TypeInfoProvider — poskytuje přístup k informacím o typech elementů a atributů tak, jak je zjišťuje ValidatorHandler. Implementaci získáme pomocí ValidatorHandler.getTypeInfoProvider(). Metody getElementTypeInfo a getAttributeTypeInfo pak vrací objekt implementující org.w3c.dom.TypeInfo, který nese informace o typu.

• Validator — procesor pro porovnání XML dokumentu s daným XML schématem. Třída není vláknově bezpečná a reentrantní, tzn. nesmí být použita z více než jednoho vlákna najednou a pokud běží metoda validate, nesmí být znovu rekurzivně volána. Metoda validate sice má parametry typu Source a Result, ale přijímá pouze SAXSource a DOMSource resp. SAXResult a DOMResult.

• ValidatorHandler — validátor pro SAX proudy. Třída implementuje rozhraní org.xml.sax.ContentHandler, není vláknově bezpečná ani reentrantní. ValidatorHandler kontroluje, jestli SAX události odpovídají omezením popsaným v Schema a případně modifikuje SAX události (např. přidává implicitní hodnoty, pokud nejsou uvedeny).

javax.xml.xpath

Poskytuje API nezávislé na objektovém modelu dokumentu pro vyhodnocování XPath dotazů.

Rozhraní:

• XPath — poskytuje přístup k prostředí vyhodnocování XPath dotazů — umožňuje zjišťovat a nastavovat zpracovatele proměnných a funkcí (XPathVariableResolver, XPathFunctionResolver), kompilovat a provádět XPath dotazy.

• XPathExpression — reprezentuje zkompilovaný XPath dotaz, který tak lze vícekrát provádět na různých vstupních datech.

• XPathFunction — reprezentuje XPath funkci. Obsahuje jedinou metodu Object evaluate(List args).

• XPathFunctionResolver — poskytuje přístup k množině uživatelem definovaných proměnných — metoda resolveFunction je volána kvalifikovaným jménem funkce a její aritou a vrací XPathFunction. XPathFunctionResolver není třeba pro vestavěné funkce XPath a nelze jej použít na jejich přepsání. Lze jej použít pouze na funkce v jiném jmenném prostoru.

• XPathVariableResolver — poskytuje přístup k množině uživatelem definovaných proměnných — metoda resolveVariable převede kvalifikované jméno proměnné na její hodnotu (tedy Object jí odpovídající).

Třídy:

• XPathConstants — nabízí konstanty reprezentující datové typy XPath 1.0 a URI pro objektový model DOM.

• XPathFactory — tovární třída pro objekty XPath.

Výjimky XPathException, XPathExpressionException, XPathFactoryConfigurationException, XPathFunctionException.

W3C DOM (org.w3c.dom*)

W3C DOM je objektový model dokumentu budovaný jako strom. Stromové modely dokumentu jsou vhodné pro reprezentaci XML dokumentu v paměti a snadnou práci s ním. Jejich nevýhoda je právě nutnost reprezentovat dokument (resp. uzel) celý v paměti a tedy vyšší paměťová režie, což je činí nevhodnými pro zpracování velkých XML dokumentů.

Schéma použití DOM v JAXP

org.w3c.dom

Poskytuje rozhraní na práci s DOM (Document Object Model). Toto API umožňuje číst a upravovat obsah a strukturu dokumentu

Rozhraní:

• Node — je hlavním rozhraním tohoto balíku reprezentuje uzel ve stromu XML dokumentu. Je možné pracovat se strukturou podstromu (odebírat, přidávat a zjišťovat informace o dceřinný a sourozeneckých uzlech, zjišťovat informace o rodičích, ...). Potomky tohoto rozhraní jsou Attr, CDATASection, CharacterData, Comment, Document, DocumentFragment, DocumentType, Element, Entity, EntityReference, Notation, ProcessingInstruction a Text. Některé z nich se liší svými možnostmi, např. Text neumožňuje mít dceřinné uzly (přestože rozhraní Node má metodu appendChild) a přidání takového uzlu vyvolá výjimku. Informace o uzlu je možné získat i bez jeho přetypování a to pomocí getNodeType, getNodeName a getNodeValue.

• DOMConfiguration — reprezentuje konfiguraci dokumentu a tabulku rozpoznaných parametrů. Konfigurovat lze např. to, zda se dokument bude validovat oproti schématu, jaké schéma bude použito, jestli mají být ve stromu dokumentu i komentáře, jak se má zacházet s bílým místem, odkazy na entity apod.

• DOMError — popisuje vzniklé chyby (řetězec, popisující chybu, typ chyby, závažnost, umístění a data, kterých se chyba týká).

• DOMErrorHandler — slouží pro ošetření vzniklých chyb — obsahuje jedinou metodu boolean handleError(DOMError).

• DOMImplementation — poskytuje metody pro provádění operací nezávislých na konkrétní instanci DOM stromu. Umožňuje vytvořit dokument požadovaného typu a zjišťovat a využívat vlastnosti konkrétní implementace DOM.

• DOMImplementationList — reprezentuje uspořádanou kolekci implementací DOM (DOMImplementation).

• DOMImplementationSource — umožňuje poskytovat jednu nebo více implementací DOM na základě vlastností a verzí, které uživatel od implementace požaduje.

• DOMLocator — popisuje umístění v dokumentu (použitelné např. pro identifikaci místa, kde vznikla chyba).

• DOMStringList — reprezentuje uspořádanou kolekci hodnot DOMString (reprezentovaných jako String).

• NamedNodeMap — reprezentuje kolekci uzlů, ke kterým je možné přistupovat podle jména. (Uzly jsou uspořádány a může k nim tak být přistupováno i podle indexu, ale toto uspořádání není definováno, slouží pouze k umožnění přístupu ke kolekci i jako k výčtu.)

• NameList — reprezentuje uspořádanou kolekci dvojic jméno a jmenný prostor (jmenný prostor může být i null).

• NodeList — reprezentuje uspořádanou kolekci uzlů (Node).

• TypeInfo — reprezentuje typ (tj. dvojici jméno typu a URI jmenného prostoru) odkazovaný uzlem typu Element nebo Attr specifikovaný ve schématu přiřazeném k dokumentu.

• UserDataHandler — s každým uzlem (Node) je možné asociovat dvojice klíč a libovolný objekt — uživatelská data (pomocí metody setUserData). Ke každé dvojici je možné přiřadit UserDataHandler, který je zavolán, když je uzel (ke kterému jsou data přiřazena) klonován, importován, adoptován (tj. přesouván z jednoho dokumentu do druhého), přejmenováván nebo mazán.

Dále obsahuje výjimku DOMException vyhazovanou v případě, že nějakou operaci nelze provést.

org.w3c.dom.bootstrap

Obsahuje třídu DOMImplementationRegistry — tovární třídu pro získávání implementací DOMImplementation. Implementace DOM můžou tuto třídu upravit, aby dodržely nové bezpečnostní standardy nebo k dodatečnému upravení chování některých tříd DOMImplementationSource.

org.w3c.dom.events

Balík definuje způsob zpracování událostí podle DOM2 Events Specification. Obsahuje výjimku EventException a rozhraní:

• Event — reprezentuje událost, poskytuje informace o kontextu události objektu, který události ošetřuje. Potomky tohoto rozhraní jsou: LSLoadEvent a LSProgressEvent z balíku org.w3c.dom.ls a dále:

• EventTarget — toto rozhraní by měly implementovat všechny uzly (Node) v DOM implementaci, která podporuje DOM Event Model. (A tedy je možné získat objekt tohoto typu přetypováním jakéhokoliv objektu Node.) Toto rozhraní umožňuje zaregistrovat EventListener a pomocí něj vyřizovat události zasílané objektu typu EventTarget.

• EventListener — hlavní způsob zpracování událostí. Uživatel implementuje EventListener a zaregistruje ho na uzlu (který implementuje EventTarget).

• DocumentEvent — slouží k vytváření událostí typů podporovaných implementací DOM. Používá se tehdy, když je nevhodné nebo zbytečné, aby uživatel vytvářel událost sám. Pokud nedostačují události z implementace DOM, uživatel může vytvořit vlastní.

org.w3c.dom.ls

Balík obsahuje rozhraní pro načítání a ukládání dat a výjimku LSException.

Rozhraní:

• DOMImplementationLS — obsahuje tovární metody pro vytváření objektů LSInput (načítání), LSOutput (ukládání), LSParser ().

• LSInput — reprezentuje vstupní zdroj dat. Umožňuje aplikaci zapouzdřit informace o vstupních datech (veřejný a systémový identifikátor, URI, znakový a/nebo bytový proud) do jediného objektu.

• LSOutput — reprezentuje informace o výstupu. Umožňuje aplikaci zapouzdřit informace o výstupních datech (systémový identifikátor, URI, znakový a/nebo bytový proud) do jediného objektu.

• LSParser — implementující objekt je schopen vytvořit nebo rozšířit existující DOM strom ze zdroje LSInput.

• LSSerializer — poskytuje API pro serializaci, tedy převod DOM stromu do XML dat (LSOutput). Serializace nijak neovlivňuje původní DOM strom.

• LSParserFilter — pokud je objekt tohoto typu zaregistrován u parseru (LSParser), jsou jeho metody volány během tvorby stromu a je možné tak upravovat nebo odebírat uzly, případně i předčasně ukončit tvorbu stromu.

• LSSerializerFilter — pokud je objekt tohoto typu zaregistrován u objektu LSSerializer, jsou jeho metody volány během serializace určit, které uzly budou serializovány.

• LSLoadEvent — reprezentuje událost značící dokončení načítání dokumentu. Je potomkem výše zmiňované org.w3c.dom.events.Event.

• LSProgressEvent — reprezentuje událost značící průběh načítání dokumentu, která upozorňuje aplikaci na pokrok v průběhu načítání dokumentu.

• LSResourceResolver — slouží pro přesměrování odkazů na externí zdroje, např. při tvorbě XML dokumentu z databáze.

SAX (org.xml.sax*)

SAX SAX01 (Simple API for XML)

je API sloužící k vytváření reprezentace XML dokumentu na základě událostí zasílaných XML parserem. Výhodou SAXu (a obecně API založených na událostech) oproti DOMu je hlavně to, že není nutné uchovávat celý dokument v paměti, což je činí vhodnými pro zpracování i velkých XML dokumentů.

Pro představu uvádím příklad zpracování XML dokumentu SAX parserem. Následující dokument:

<?xml version="1.0" ?> <korenovy_element> <jiny_element>nějaký text</jiny_element> </korenovy_element>

by měl vygenerovat následující posloupnost událostí:

start document start element: korenovy_element start element: jiny_element characters: nějaký text end element: jiny_element end element: korenovy_element end document

Schéma použití SAX v JAXP

org.xml.sax

Poskytuje základní SAX API.

Rozhraní:

• Attributes — reprezentuje seznam XML atributů, ke kterým je možno přistupovat pomocí indexu, jména kvalifikovaného jmenným prostorem nebo jména kvalifikovaného prefixem.

• ContentHandler — hlavní rozhraní, které většina SAX aplikací implementuje. Dostává informace o logickém obsahu dokumentu. Aplikace, která potřebuje být informována o SAX událostech implementuje ContentHandler a zaregistruje ho u SAX parseru (metoda setContentHandler).

• DTDHandler — dostává informace o základních událostech souvisejících s DTD — notacích a neparsovaných entitách.

• ErrorHandler — pokud aplikace potřebuje sama ošetřovat chyby, implementuje ErrorHandler a zaregistruje ho u XMLReader (setErrorHandler). Hlášení chyb tímto způsobem má mít přednost před vyhazováním výjimek.

• EntityResolver — pokud chce aplikace implementovat vlastní zacházení se vstupními zdroji, implementuje EntityResolver a zaregistruje ho u XMLReader (setEntityResolver). EntityResolver pak umožňuje převádět veřejné a systémové identifikátory na zdroje InputSource. Toho lze využít např. pokud XML dokument generujeme z databáze nebo jiných specializovaných vstupních zdrojů nebo naše aplikace používá URI místo URL.

• XMLReader — základní rozhraní pro implementaci SAX2. Umožňuje nastavovat vlastnosti, registrovat objekty na zpracování obsahu, DTD, chyb a spustit parsování dokumentu.

• XMLFilter — potomek XMLReader, který se chová stejně jako XMLReader, ale umožňuje zpracovávat události z jiných XMLReaderů a řetězit tak zpracování.

• Locator — slouží k zjištění místa dokumentu, kde došlo k události. Objekt implementující toto rozhraní se předá pomocí metody setDocumentLocator objektu ContentHandler.

Třída:

• InputSource — zapouzdřuje informace o vstupním zdroji.

Dále balík obsahuje výjimku SAXException a její potomky SAXNotRecognizedException (nerozeznaný identifikátor), SAXNotSupportedException (nepodporovaná operace), SAXParseException (chyba během parsování nebo varování).

org.xml.sax.helpers

Obsahuje pomocné třídy jako např. základní implementace některých rozhraní.

• AttributesImpl — základní implementace rozhraní Attributes, která obsahuje navíc metody pro úpravu, aby list mohl být upravován a znovu používán.

• DefaultHandler — základní třída pro SAX2 aplikace, která poskytuje implementaci rozhraní EntityResolver, DTDHandler, ContentHandler, ErrorHandler.

• LocatorImpl — poskytuje běžnou implementaci rozhraní Locator.

• XMLFilterImpl — základní třída pro odvozování XML filtrů. Nedělá nic, pouze předává požadavky XMLReaderu a události jejím příslušným zpracovatelům a podtřídy můžou podle potřeby jednotlivé metody překrývat.

• Adaptéry ParserAdapter (obaluje starší rozhraní Parser ze SAX1 a reprezentuje ho jako XMLReader) a XMLReaderAdapter (dělá opak).

• XMLReaderFactory — tovární třída na implementace XMLReader.

• NamespaceSupport — zapouzdřuje logiku pro práci s jmennými prostory XML.

org.xml.sax.ext

Obsahuje rozšíření rozhraní SAX2, které SAX2 ovladače nemusí nutně podporovat. Jsou nezávislá na jádru SAX2.

Rozhraní:

• Attributes2 — potomek rozhraní Attributes. Poskytuje dodatečné informace o atributech (jestli je atribut deklarovaný v DTD a jestli byla dosazena jeho implicitní hodnota podle DTD).

• DeclHandler — zpracovává události týkající se DTD deklarací (deklarace atributu, elementu, interní a externí entity).

• EntityResolver2 — potomek rozhraní EntityResolver. Rozšiřuje toto rozhraní o nové mapování odkazů na externí entity na vstupní zdroje (InputSource).

• LexicalHandler — slouží ke zpracování lexikálních informací (komentáře, hranice CDATA sekcí, entit a DTD deklarací).

• Locator2 — potomek rozhraní Locator. Rozšiřuje informace poskytované tímto rozhraním o kódování a verzi XML dané entity.

Třídy:

• Attributes2Impl — rozšíření rodičovského AttributesImpl o funkce, které jsou navíc v rozhraní Attributes2.

• DefaultHandler2 — rozšíření rodičovského DefaultHandler implementující navíc rozhraní LexicalHandler, DeclHandler, EntityResolver2.

• Locator2Impl — rozšíření rodičovského LocatorImpl o dodatečné informace o entitách (kódování a verze XML).

XML:DB API

XML:DB API je projekt XML:DB Initiative na vytvoření aplikačního rozhraní sloužícího pro sjednocení přístupu k různým nativním XML databázím. Jedná se o jakousi obdobu ODBC nebo JDBC u relačních databází.

XML:DB API v současnosti implementují například databáze eXist nebo Apache Xindice (dříve dbXML).

Za základ XML:DB API by se daly označit:

• Ovladače — každá databáze implementující XML:DB API poskytuje ovladač, který zapouzdřuje přístup k databázi. Jedná se o implementaci rozhraní Database a jsou spravovány třídou DatabaseManager.

• Kolekce — kontejnery pro uchovávání XML dokumentů (obvykle stejného nebo podobného typu). Jedná se o jakousi obdobu tabulek v relačních databázích.

• Služby — implementují různou funkčnost. Každá databáze může nabízet různé služby. Některé z nich jsou jsou definovány v XML:DB API (implementace XPath dotazů, XUpdate, správu kolekcí, transakce, ...), další může definovat konkrétní databáze.

• Zdroje — reprezentuje různé typy dat (XML, binární data). Jedná se o rozhraní Resource.

• Úrovně API (API Core Levels)

— jelikož XML:DB API má být modulární, je nutné pro zjednodušení práce vývojářů s různými databázemi vlastnosti shlukovat (např. podle důležitosti). XML:DB API definuje dvě úrovně — 0, kterou musí implementovat každá databáze implementující XML:DB API a 1, která tuto rozšiřuje o rozhraní XPathQueryService.

Základní jednoduché případy použití XML:DB ukazuje např. XMLDB01.

org.xmldb.api

Obsahuje pouze třídu DatabaseManager, která je vstupním bodem celého API. Umožňuje pracovat s implementacemi databází, zjišťovat API Core Levels a získávat kolekce.

org.xmldb.api.base

Poskytuje základní rozhraní:

• Database — zapouzdřuje funkcionalitu ovladače databáze (rozhodnutí, zda umí zpracovat dané URI, jaké API Core Level databáze implementuje a získání kolekce). Každá XML databáze toto rozhraní musí implementovat. Instance je pak zaregistrována u DatabaseManager a uživatel by měl dále přistupovat pouze k němu (s výjimkou inicializace třídy Database).

• Collection — reprezentuje kolekci zdrojů dat (Resource) uloženou v XML databázi. Mezi kolekcemi může (ale nemusí) být stromová hierarchie. Kolekce poskytuje přístup ke zdrojům (Resource) a službám (Service), které nad kolekcemi a zdroji v nich mohou operovat.

• Resource — kontejner pro data uložená v databázi. Jelikož tato data mohou být různých typů, je nutné zjistit před jejich použitím typ (getResourceType()) a podle toho data (Object getContent()) přetypovat. XML:DB API definuje dvě podrozhraní — BinaryResource a XMLResource.

• Service — poskytují různá rozšíření ke kolekcím a práci s nimi. Některé služby jsou definovány už v XML:DB API — CollectionManagementService, TransactionService, XPathQueryService, XUpdateQueryService. Samotné rozhraní Service neobsahuje žádné speciální metody, je na uživateli, aby si obdrženou Service přetypoval na příslušný podtyp.

• ResourceIterator — iterátor přes zdroje (Resources). I přes název se nejedná o potomka java.util.Iterator.

• ResourceSet — množina zdrojů Resource, obvykle získaná jako výsledek dotazu.

• Configurable — poskytuje metody pro nastavení a zjištění vlastností objektu. Potomky tohoto rozhraní jsou Collection, Database, Service a dále z balíku org.xmldb.api.modules rozhraní CollectionManagementService, TransactionService, XPathQueryService a XUpdateQueryService.

Dále třídu ErrorCodes obsahující konstanty s chybovými kódy a výjimku XMLDBException vyhazovanou všemi chybami v XML:DB API (typ chyby je rozlišován právě přes konstanty v ErrorCodes).

org.xmldb.api.modules

Obsahuje některé specializace rozhraní Resource a Service:

• BinaryResource — reprezentuje binární data uložená v databázi.

• XMLResource — reprezentuje XML data uložená v databázi. Umožňuje je získat prostřednictvím uzlu DOM stromu nebo pomocí SAX (přes org.xml.sax.ContentHandler).

• CollectionManagementService — umožňuje základní manipulacemi s kolekcemi uvnitř databáze (přidání a odstranění). Pokročilejší správa se u různých databází liší, proto ji toto rozhraní neřeší.

• TransactionService — umožňuje spojit operace nad kolekcemi do transakcí.

• XPathQueryService — umožňuje provedení XPath dotazů nad kolekcí nebo zdrojem v kolekci.

• XUpdateQueryService — umožňuje provedení XUpdate dotazů nad kolekcí nebo zdrojem v kolekci.

Dom4j

Rozhraní a implementace pro práci s XML DOM. TODO: dokončit!

JDOM

Nástroj pro práci s XML DOM (podobně jako dom4j). Slouží jako reprezentace XML dokumentu. K jeho vytvoření používá XML parser (který sám neimplementuje). JDOM má za cíl být co nejsnadněji použitelné, ale jelikož není stavěné na rozhraních, ale na třídách, je jeho použití v XIQE nevhodné a proto se jím dále nebudu zabývat. Zmiňuji jej především proto, že patří ke známým nástrojům pro práci s DOM. JDOM01

Xerces Native Interface

Xerces Native Interface je rozhraní, které mohou implementovat XML parsery (implementuje jej např. Xerces2 parser). Je postaveno na stejných principech jako SAX (tj. zasílá informace o toku dokumentu), ale s několika rozdíly:

• XNI se snaží poskytovat všechny informace o dokumentu, beze ztráty. SAX například nepředává takové informace jako kódování externích entit.

• XNI umožňuje vytvořit řetěz komponent parseru, kde mohou být informace o dokumentu plně modifikovány. SAX umožňuje pouze malé možnosti takovéto modifikace při čtení XML dokumentu. Toho lze využít například pro vytvoření DOM nebo SAX parseru HTML dokumentu, vložení dokumentů odkazovaných přes XInclude tak, aby to bylo transparentní vůči validátoru apod.

XNI obsahuje sadu rozhraní, pomocí kterých je možné definovat komponenty a konfiguraci parseru.

StAX

StAX (Streaming API for XML) je API založené stejně jako SAX nebo XNI na proudovém zpracování XML dokumentu. Narozdíl od SAX a XNI nepracuje jako „push“ (tj. parser zasílá události klientovi v průběhu zpracování XML dokumentu), ale „pull“ API (tj. klient ovládá chod parseru). Díky proudovému zpracování zachovává výhody SAX a XNI (malou paměťovou režii oproti rozhraním založených na vytváření stromu v paměti, jako je DOM, schopnost zpracovávat rozsáhlé XML dokumenty). Důvod, proč vznikla „pull API“ je ten, že tento přístup je většině programátorů bližší a vzniklé aplikace bývají jednodušší. StAX oproti SAX a XNI umožňuje snadněji vytvářet XML dokumenty. Další výhodou je to, že lze zpracovávat více XML dokumentů najednou v jednom vlákně. (To je způsobené tím, že zpracování řídí klient.)

XMLPULL

Jedná se o starší „pull“ rozhraní než StAX. Důvod, proč se mu nebudu podrobněji věnovat je ten, že v něm byly dělány kompromisy v návrhu určené k minimalizaci spotřeby paměti (především je upřednostňován procedurální přístup před objektovým), aby mohlo být používáno v zařízeních s malou pamětí v prostředí J2ME a nehodí se příliš pro použití v prostředí desktopových nebo serverových aplikací.

JAXB (Java Architecture for XML Binding)

Framework JAXB umožňuje vázat XML schémata na Java objekty a jejich prostřednictvím pak zpracovávat XML dokumenty. Poskytuje rozhraní pro načtení XML dokumentu jako stromu Java objektů (unmarshalling) a jeho opětovné uložení do XML (marshalling). Umožňuje pracovat s XML dokumenty bez znalosti modelů pro zpracování XML jako DOM, SAX, apod. Třídy v Javě by pak měly reprezentovat pouze vztahy definované v XML schématu.

Ke zpracování pomocí JAXB dochází takto:

• Pro XML data, která se budou zpracovávat je k dispozici nějaké schéma (např. XML Schema).

• Na základě schématu je kompilátorem vazeb vytvořena sada tříd jazyka Java založených na daném schématu.

• Vygenerované třídy jsou obvyklým způsobem zkompilovány do bytekódu.

• XML dokument (v podobě souboru na disku, DOM stromu, SAX zdroje, řetězce v paměti apod.) splňující dané schéma je načten a zpracován. Z dříve připravených tříd je vygenerován strom reprezentující strukturu a obsah XML dokumentu. Součástí tohoto kroku může být i validace.

• Prostřednictvím vytvořeného stromu a rozhraní vygenerovaných tříd je možné „dokument“ upravovat. Během těchto úprav nemusí být validní vůči zadanému schématu (i když je možné validaci explicitně vyvolat).

• Výsledek se pak opět převede na jeden nebo více XML dokumentů. Součástí tohoto kroku může být i validace.

Schéma fungování JAXB

Castor XML

Castor XML je framework, který umožňuje definovat vztah mezi XML daty a objekty, které je reprezentují a tyto dvě reprezentace mezi sebou převádět. Castor využívá sadu popisovačů (ClassDescriptor a FieldDescriptor) k tomu, aby objekt v Javě převedl na jeho XML reprezentaci a naopak.

Požadavky uživatele

Pro navržení vhodného rozhraní je potřeba stanovit požadavky uživatele na systém. Dokumenty jsou v systému XIQE, stejně jako v jiných XML databázích, tříděny do kolekcí. Některé XML databáze podporují hierarchickou strukturu kolekcí. Bez ohledu na současný stav projektu XIQE byl určen seznam důležitých operací, které by systém měl v budoucnu podporovat. Uživatel by tedy měl mít možnost:

• založit kolekci dokumentů

• vrátit kolekci dokumentů na základě názvu

• smazat kolekci dokumentů

• přejmenovat, resp. přesunout kolekci dokumentů

• vložit dokument (v podobě objektu File, String, DOM stromu, SAX nebo StAX zdroje) do kolekce

• s kolekcí dokumentů:

• vyhledat v ní dokument podle názvu

• provést nad ní XPath dotaz

• provést nad ní XQuery dotaz

• provést nad ní XUpdate

• s dokumentem:

• provést nad ním XPath dotaz (TODO: opravdu? nevadí nám to, že uživatel dokument může měnit a v kolekci tedy nebude aktuální podoba dokumentu, nad kterou se dotaz prování?)

• převést jej na DOM (Document), SAX (SAXResult), StAX (XMLEventReader)

• s výsledkem XPath dotazu:

• převést jej na DOM (Document), SAX (SAXResult), StAX (XMLEventReader) — s tímto si zatím nejsem jistý; můžeme takhle vrátit výsledek XPath dotazu, když to nemusí být well-formed XML dokument? (může obsahovat např. jen atributy)

Současný stav XIQE a návrh změn

Vzhledem ke svému zaměření systém XIQE má podporu pro různé způsoby ukládání XML dat — umožňuje tak ověřit různé způsoby indexace a efektivního uchovávání a vyhledávání v datech. Uživatel by však měl dostat k dispozici pohodlný nástroj se sadou přepřipravených ukládacích struktur, mezi kterými si může snadno vybrat. Systém XIQE nemá žádnou podporu pro snadnou manipulaci s kolekcemi. Dále nepodporuje hierarchické struktury kolekcí — o tomto však bylo rozhodnuto, že se nyní nebude implementovat, jelikož uživatel si může hierarchické kolekce simulovat pomocí prostředků souborového systému (pomocí struktury adresářů). Momentálně je k dispozici podpora pouze pro ukládání kolekcí na lokálním souborovém systému a v paměti. Zvažuje se možná budoucí podpora klient-server architektury a komunikace prostřednictvím počítačové sítě. Pozdější implementace už by hierarchické kolekce mohly podporovat, pravděpodobně prostřednictvím XML:DB API, kde již pro hierarchické kolekce podpora je.

XML:DB API

Jako základní rozhraní, které bude systém XIQE podporovat bylo vybráno XML:DB API. Obsahuje podporu pro vše, co je potřeba a uživateli může být známé — je použito v několika různých XML databázových systémech.

Jeho implementace byla započata, třídy jsou v balíku org.xiqe.xmldb. Tyto třídy budou používat org.xiqe, které již slouží jako jakési „nativní“ rozhraní XIQE. Některé třídy byly implementovány za použití tříd XML:DB API SDK — tyto poskytují některé základní metody a naše třídy je pak rozšiřují. Pravděpodobně však bude od použití SDK upuštěno z důvodů jeho závislosti na nástroji Xerces Xer01 a z licenčních důvodů (pokud bychom chtěli SDK upravit, museli bychom zachovat jeho licenci, a některé části XIQE by pak museli používat XML:DB Initiative Software License).

JAXP

Jako další rozhraní, které bude podporováno bylo pro svou velkou rozšířenost vybráno JAXP. Podpora pro model dokumentu W3C DOM již v současnosti v XIQE je podporováno jako jeden z modelů dokumentu (druhý, který je momentálně podporován je Dom4j). Podpora pro SAX byla odložena jako úkol s nižší priporitou. Podpora pro transformační API z JAXP je záležitostí, která je na straně uživatele, proto ji XIQE podporovat nebude. Ve spolupráci s Bc. Petrem Vlčkem byla navržena podpora pro XPath pomocí JAXP a na její implementaci pracuje v rámci své diplomové práce.

Rozhraní org.xiqe

Rozhraní a třídy v tomto balíku byly původně určeny jako vnější rozhraní, zatím je však nikdo neimplementoval. Jelikož XML:DB API nabízí vše, co je třeba, bude určeno jako primární rozhraní pro uživatele s tím, že, org.xiqe bude sloužit jako rozhraní, které bude využíváno rozhraním org.xiqe.xmldb, které k němu bude tvořit jakýsi wrapper a umožňovat co nejtransparentnější manipulaci s různými typy kolekcí — tj. aby uživatel mohl pracovat úplně stejným způsobem s kolekcí v paměti, na lokálním disku i na vzdáleném serveru. Rozhraní org.xiqe by pak mohlo být využito v případě, že bychom v budoucnu narazili na něco, co by nebylo možné pomocí XML:DB API snadno vyřešit. Dále je uživatel bude moci využívat v případě, že mu nevadí nepřenositelnost jeho softwaru na jinou XML databázi. (V případě používání XML:DB API by uživateli při přechodu k jiné XML databázi, která nabízí nadmnožinu toho, co umí XIQE, mělo stačit změnit URI, pomocí kterých přistupuje ke kolekcím)

Obsah přiloženého CD

Součástí práce je i přiložené CD, kde jsou k dispozici:

• zdrojový kód této práce ve formátu XML (DocBook)

• tato práce ve formátech LaTeX, PDF a XHTML, vygenerovaná pomocí šablony fithesis a nástroje XSLT2 Mgr. Jana Pavloviče

• aktuální revize ze Subversion repository projektu XIQE

• JavaDoc dokumentace k popisovaným rozhraním

Bibliografie

• Zkratka: Sta01, název: Introduction to dbXML, autor: Kimbro Staken

• Zkratka: Sta02, název: An Introduction to the XML:DB API, autor: Kimbro Staken , datum: 9. 1. 2002

• Zkratka: Ada01, název: Systém pro indexování XML dokumentů, autor: Štěpánka Adámková , releaseinfo: diplomová práce, publikoval: Masarykova Univerzita , místo: Brno , datum: 2005

• Zkratka: XMLDB01, název: API Use Cases, autor: Kimbro Staken , publikoval: Members of the XML:DB API Mailing List , datum: 20. 9. 2001

• Zkratka: SAX01, název: SAX Project

• Zkratka: JDOM01, název: JDOM Project

• Zkratka: Har01, název: An Introduction to StAX, autor: Elliotte Rusty Harold , datum: 17. 10. 2003

• Zkratka: Har02, název: The XMLPULL API, autor: Elliotte Rusty Harold , datum: 14. 9. 2002

• Zkratka: Kaw01, název: The JAXB API, autor: Koshuke Kawaguchi , datum: 8. 1. 2003

• Zkratka: Enh01, název: Enhydra Zeus project website, publikoval: ObjectWeb Consortium

• Zkratka: Xer01, název: Xerces project website, publikoval: The Apache Software Foundation

• Zkratka: JWST, název: The Java Web Services Tutorial, publikoval: Sun Microsystems

• Zkratka: Ogb01, název: Manage XML collections with XAPI, autor: Uche Ogbuji , datum: 11. 1. 2005