Andra föreslagna frågespråk

[Bon99] ger, utöver XQL och DBHS-frågespråket ”LORE” (se vidare under avsnitt 5.1.6), en översikt kring ytterligare tre föreslagna frågetekniker, vilka presenteras i det jär delavsnittet. Gemensamt för samtliga frågespråk är att utvecklarna har behövt ta fram särskilda datamodeller för att få språken att på ett korrekt sätt koppla mot XML:s struktur.

XML-QL – ”XML Query Language” är en prototyp till en omarbetad variant av SQL. Semantiken och syntaxen för XML-QL är densamma som för SQL, men en avgörande skillnad är att XML-QL har försetts med en operator som konstruerar ett XML-dokument av resultatet av en fråga. Operatorn benämns därför ’CONSTRUCT’ och följer efter de SQL-lika ’SELECT’ [sökväg till nod uttryck enligt XPath] ’WHERE’ [villkor]. XML-QL läser inledningsvis in aktuella DTD:er och söker därefter, med hjälp av matchning av elementmönster (på motsvarande sätt som XSL), igenom aktuella XML-dokument efter element som matchas mot sökvillkoret ”WHERE”. Lyckas matchningen av sökvillkoret mot ett eller flera element, skapar ”CONSTRUCT”-satsen ett nytt XML-dokument, som listar innehållet av de element som XML-QL funnit i sökningen. XML-QL finns som en försöksprodukt, implementerad i java, av det forskningsprojekt som utvecklar språket [ATT00].

Motsvarande jämförelse av XML-QL mot SQL som gjordes med XQL i avsnitt 5.1.4 ger följande för XML-QL:

• Det kan endast hantera existenskvantifiering, vilket har sin orsak i språkets

arbetssätt. Då XML-QL arbetar med mönstermatchning av element i XML- dokument jämfört elementens ”utseende” i DTD:n, utgör frågeuttrycket i sig en existenskvantifierad fråga. En lyckad sökning svarar på frågan att det finns något element så att [sökvillkoret]. Eftersom vi i XML inte har någon metod för att räkna antalet instanser av en konceptuell entitet (till exempel en medarbetare i ett XML-dokument som lagrar alla medarbetare), kan inte XML-QL formulera några uttryck som rör ”alla” instanser eller upprepningar av det element som vi vill undersöka. Det finns dock vissa möjligheter att indirekt tolka betydelsen av ett sökresultat utanför XML-QL:s existenskvantifiering. Att en fråga misslyckas kan till exempel tolkas som att det gäller för det sökta elementet att det inte finns något sådant element. I själva språket finns dock ingen annan kvantifieringsmetod än existenskvantifiering.

• Det kan utföra ”joins” såväl inom ett enskilt som mellan flera oberoende

dokument. Detta möjliggörs tack vare att XML-QL är en implementation som är åtskild från själva XML-systemet och därför kan läsa in flera DTD:er med tillhörande XML-dokument och ställa dessa mot varandra i sökarbetet. Att lyckas med en ”join” ställer dock krav på att frågeställaren känner materialet i XML- dokumenten då till exempel XML-QL inte kan förhindra felaktiga resultat till följd av att till exempel två XML-dokument har var sitt element som går under

samma elementnamn med med olika innebörd i de respektive XML-dokumentens DTD:er.

• Det har stöd för relativa och ofullständiga sökvägar, samt kan använda sig av

”wildcards”.

• Det kan med hjälp av sin ’CONSTRUCT’-operator, skapa nya element i form av

resultat av körningar som XML-dokument. Med denna förmåga följer också möjligheten att gruppera och ordna resultat av körningar.

• Det har inga implementerade aggregat, vilket beror på språkets tidiga

utvecklingsskede samt att det ännu inte kopplats mot något DBHS.

• Det har, likt SQL, stöd för nästlade frågor, vilket följer på förmågan att läsa in

flera XML-dokument och deras respektive DTD:er oberoende av varandra.

• Det har inget uppdateringsspråk, vilket beror på avsaknaden av en koppling

mellan XML-QL och ett DBHS. Avsaknaden av uppdateringsspråk innebär att XML-QL inte kan utföra motsvarande operationer för SQL:s ”INSERT-”, ”UPDATE-” och ”DELETE-operationer”. För SQL:s del möjliggörs uppdateringsspråket tack vare språkets koppling till RDBHS.

• Det har inget stöd för abstrakta datatyper och kan ej heller utföra ”coercion”,

något som även här beror på avsaknaden av DBHS-koppling i utvecklingsarbetet. XML-QL utvecklas av AT&T Laboratories.

XML-GL – ”XML Graphic Query Language“ är ett grafiskt frågespråk för XML, där XML-dokument och DTD:er visualiseras med hjälp av grafer i form av träd. Varje graf har en etikett som anger vilket XML-dokument det är fråga om, samt vilken DTD som hör till dokumentet.

Någon implementation finns ännu inte, men avsikten enligt [Bon99] är att skapa en användarvänligt gränssnitt för direktmanipulerade frågor via det grafiska gränssnittet. Genom att kombinera olika grafer och däri ingående noder med varandra, skall sökuttryck kunna formuleras grafiskt. Även i fallet med XML-GL har utvecklarna behövt ta fram en särskilt anpassad datamodell att basera frågespråket på, för att en koppling mot XML:s struktur skall vara möjlig.

Motsvarande jämförelse mot SQL som för XQL och XML-QL, ger följande om XML- GL:

• Det kan hantera existenskvantifiering samt negation.

• Det kan utföra ”joins” i ett enskilt dokument och mellan olika oberoende

dokument. Detta uppnås genom att noder från det egna dokumentets graf eller från olika dokuments grafer, kopplas samman.

• Det har endast stöd för ”wildcards”. Ofullständiga och relativa sökvägar (på

samma form som i till exempel XSL) stödjs inte, eftersom XML-GL inte använder sig XPath för att matcha URI-sökvägar i XML-dokumenten.

• Det kan skapa nya element vilket uppnås genom att språket upprättar en ny graf

som representerar resultatet av en frågeoperation. På motsvarande sätt kan XML- GL också ordna och gruppera sina resultat.

• Det har implementerat samtliga SQL:s aggregat.

• Det saknar stöd för nästlade frågor, vilket har sin grund i att ”joins” endast kan

utföras med hierarkier på samma nivå. Genom att utföra två join-operationer, först en på det nästlade uttryckets nivå, och därefter en på huvuduttryckets nivå, kan dock ett likvärdigt frågeresultat erhållas.

• Det har ett uppdateringsspråk vilket består i att lägga till, ändra innehållet i eller ta

bort noder och hela grafer. Funktionaliteten medger också att vi kan lägga till nya instanser av en konceptuell entitet i ett XML-dokument, till exempel en ny kund i ett XML-dokument som lagrar kunder.

• Det saknar stöd för abstrakta datatyper och kan ej heller utföra ”coercion”, vilket

till stor del har sin grund i att XML-GL inte är kopplat till något DBHS. XML-GL utvecklas av Stefano Ceri med flera vid Politecnico di Milano.

XSL har redan presenterats i avsnitt 2.4.1 och presenteras ytterligare i avsnitt 5.3 med tillhörande bilagor. Utöver den funktionalitet hos språket som redan beskrivits i den här rapporten, lyfter [Bon99] fram XSL som en möjlig grund att bygga ett frågespråk för XML på. I egenskap som frågespråk koncentrerar sig [Bon99] på XSL:s mönstermatchningsfunktion, där XSL matchar innehållet i ett XML-dokuments XPath- struktur mot ett antal, i XSL-mallen, upprättade ”<xsl:template>”-regler. Denna funktionalitet skulle kunna användas till att generellt söka data i XML-dokument.

En funktionalitetsjämförelse med SQL, ger för XSL följande:

• Det har stöd för existenskvantifiering och negation. I likhet med XML-QL

använder sig XSL av existenskvantifiering som grund för sin funktionalitet, genom att XSL matchar URI-uttryck, enligt XPath, i XML-dokumenten. XSL tar dock ingen hänsyn till förekommande DTD:er.

• Det saknar stöd för ”joins”. Det finns inget sätt i XSL att röra sig utanför det i

XSL-mallen angivna XML-dokumentet.

• Det har stöd för relativa och ofullständiga sökvägar och ”wildcards”, vilket bland

annat möjliggörs tack vare stödet av matchning av URI-uttryck enligt XPath.

• Det har stöd för att skapa nya element. Det formaterade dokument som XSL

genererar utgör det nya elementet och av detta följer givetvis att XSL kan ordna och gruppera datan i de skapade elementen.

• Det har, likt XQL, implementerat metoden ”count()”, vilket ger åtminstone ett

aggregat.

• Det har stöd för nästlade frågor. Ett XSL-uttryck i form av till exempel en <xsl-

template:apply>-mall kan definieras inuti en annan dito mall. På detta sätt kan nästlade sökuttryck byggas upp.

• Det saknar uppdateringsspråk. XSL kan inte påverka datan i ett XML-dokument,

utan kan endast läsa in dokumentet och därefter formatera datan enligt de regler som definierats i XSL-mallen.

• Det saknar stöd för abstrakta datatyper och kan ej heller utföra ”coercion”. XSL

har inget begrepp om datatyper, utan hanterar, likt XML, all data som textsträngar.

5.1.6 ”LORE” – Ett DBHS för XML

I [Ser97] presenteras den teoretiska grunden för en helt egen DBHS-miljö med tillhörande frågespråk, avsedd särskilt för semistrukturerad data. Systemet benämns

”Lightweight Object Repository” (LORE) och är en databashanterare baserad på en

objektorienterad datamodell. Det är att betrakta som ”lightweight” då det inte har utrustats med loggnings-, diskhanterings- eller säkerhetsfunktioner. Däremot har det utrustats med andra grundläggande DBHS-funktioner, som till exempel frågespråk, konkurrenskontroll och fillåsning. Frågespråket för systemet benämns ”LORE

Language” (LOREL) och det har det objektorienterade frågespråket Object Query Language” (OQL) som grund. Vidare är LORE:s datamodell, kallad ”Object Exchange Model” (OEM), nära kopplad till en, inom objektorienterad databasteroi, generell

objektorienterad databashanteringsmodell, benämnd ”Object Data Management Group

Standard” (ODMG Standard). ODMG standarden uttrycker en övergripande och

sammanhängande arkitektur för objektorienterade DBHS, så kallade ODBHS. De grundläggande komponenterna i ODMG-standarden utgörs av en objektorienterad datamodell, språk för att specificera datamodellen4, ett frågespråk (OQL) samt ett antal API:n för att kunna koppla ODBHS mot de vanligaste objektorienterade programmeringsspråken (bland annat C++ och Java) [ODM00].

Utvecklingen av LORE och LOREL initierades 1994 och hade inledningsvis fokus på att utgöra en DBHS-plattform för semistrukturerad data i allmänhet, men då med Webben i synnerhet. Efter XML:s tillkomst i familjen av semistrukturerade märkordsspråk, har utvecklingsarbetet av LORE och LOREL kommit att försöka inkludera även XML i sin DBHS-miljö.

Enligt [Ser97] består den grundläggande funktionaliteten hos LORE och LOREL i datamodellen OEM. Principiellt sett kan data som representeras med hjälp av OEM, ses som grafer där hörnen utgör objekt och kanterna har försetts med rubriker eller namn, som beskriver relationen mellan hörnen (objekten). Ett objekt kan antingen vara av atomär typ, vilka i LORE utgörs av de grundläggande datatyperna, vilka även inkluderar till exempel multimediatyper. Alla övriga objekt är komplexa objekt, vilka identifieras med hjälp av kantens rubrik och objektets identitetsnummer eller ”object identity

number” (oid). På detta sätt kan LORE representera instanser av en konceptuell entitet i

XML-dokumentet, till exempel flera kunder i det XML-dokument som lagrar kunder.

4

På motsvarande sätt som till exempel SQL är ett så kallat ”Data Definition Language” (DDL) och ett så kallat ”Data Manipulation Language” (DML) till RDBHS, utgör ”Object Definition Language” (ODL),

”Object Interface Definition Language” (IDL) och ”Object Interchange Format” (OIF)

Varje nu upprepning av elementet (<kund></kund>) lagras som ett nytt objekt och kan unikt identifieras tack vare sitt oid. OEM:s grafliknande representation av data ger också möjlighet till att använda relations- och funktionsmatematik till att till exempel finna indirekta vägar (transitiva beroenden) mellan olika objekt. Genom att översätta XML- elementen till objekt möjliggörs också att elementen kan ha ett oregelbundet antal subelement och attribut, likaväl som element- och attributuppsättningen kan vara ofullständig. Enligt [Mor99] är det oförmågan hos RDBHS att hantera entiteter med oregelbundet antal attribut och element, som utgör en motivering till att använda XML framför RDBHS datalagringsteknik i ett informationssystem. OEM och LORE möjliggör via objektorienterad teknik att XML-dokumentens förkomster av irregularitet kan bibehållas, samtidigt som datan kan kontrolleras av ett DBHS.

Det ligger utanför detta projekts uppgift att fördjupa sig i ODBHS och därtill kopplad teori. Vi låter därför förhållandena mellan XML och LORE sammanfattas enligt följande:

W Då vi vet att ODBHS har samma funktionalitet (i vissa fall än mer) som RDBHS

vad gäller att hantera, kontrollera och manipulera data i en databas, kan vi via LORE få tillgång till dessa egenskaper genom att i LORE, med OEM som grund, transformera XML-baserad (semistrukturerad) data till objektbaserad data. Med LOREL är det dessutom LORE-projektets målsättning att vi skall ges tillgång till en frågemiljö för XML likt den som SQL erbjuder för RDBHS.

[Bon99] tar upp LORE och LOREL i sin genomgång av föreslagna frågetekniker för XML och då systemet är ett helt eget DBHS, så framstår LORE och LOREL som mycket kraftfullt i perspektiv av de jämförelser med SQL som [Bon99] gör. LORE och LOREL skulle, med sin grund i att vara ett semistrukturerat DBHS, ha i princip samtliga de egenskaper och funktioner som ett RDBHS/SQL-system skulle ha.

Utvecklingsteamet vid Stanford University, har vid detta projekts genomförande, endast tagit fram prototyper av LORE för olika Solaris-versioner. Begränsningen i tillgängliga plattformar har, kopplat till vår bedömning av omfattningen och komplexiteten hos LORE, medfört att vi inte har kunnat prova LORE och LOREL med avseende på projektets problemspecificering.