WXT

Utgangspunktet er en illusjon om at dersom verden (les: veven) er velformet så er en URI og et XPATH-uttrykk tilstrekkelig til å identifisere et hvilket som helst element i et hvilket som helst dokument i verden. Nå er ikke verden spesielt velformet, men noen illusjoner er gode å ha og jeg velger å beholde denne. Designen i første fase av prosjektet er basert på følgende prinsipper:

• Løsningen skal være scriptbasert og scriptet skal være XML-basert.
• Løsningen skal forutsette velformet XML i alle sammenhenger og altså bygge på illusjonen om en velformet verden.
• Det skal kunne utvikles brukergrensesnitt for forskjellige formål og forskjellige brukergrupper.
• Det skal være mulig å kjøre scripttolking fra kommandolinja.
• Løsningen skal være basert på et fundamentalt og utbyggbart klassehierarki for representasjon og kopling av dokumenter, dokumentfragmenter og dokumenttransformasjoner.
• Løsningen skal være basert i sin helhet på brukerens filer og den eneste filtypen som introduseres spesielt for formålet er scriptet.
• Løsningen skal kreve et minimalt inngrep i brukerens dokumenter og ingen informasjon skal gå tapt dersom WXT velges bort som verktøy.

Basiskomponenter og funksjoner

WXT kjenner i dag følgende typer dokumenter:

• Template. Malen for en side (Page) som skal bygges. En velformet XML-fil.
• Transformation. En XSL-transformasjon som kan anvendes på alle andre dokumenttyper. En transformasjon er i dag det samme som en XSLT-transformasjon.
• Module. Resultatet av at en template fylles med innhold fra en eller flere Content-filer.
• Content. En velformet XML-fil.
• TextContent. En vilkårlig tekstfil. For å kunne importere fra filer som ikke har XML-natur. Typiske eksempler er programkode. Ekstrakter fra TextContent-dokumenter plasseres normalt som Text-noder i resultatdokumentet.

Det er mulig å lage vilkårlig lange kjeder av transformasjoner og bygginger ved å la en Page inngå som Content eller Template for en ny Page.

Alle typer dokumenter skal kunne utsettes for transformasjoner. Transformasjoner kan parameterstyres og de kan anvendes på Templates eller Contents før de brukes til å bygge med og de kan anvendes på Pages etter at de er bygd. Fleksibiliteten i transformasjoner er en fleksibilitet som ikke belaster logikken i WXT. Dette gjør det mulig å oppnå mye med enkle midler.

Det er mulig å importere direkte fra en fil til en annen ved hjelp av en Processing Instruction (PI), uavhengig av den strukturen som er gitt i scriptet.

Basisfunksjonaliteten baserer seg på sammenhenger mellom dokumenter, struktur, slik som den er beskrevet i scriptet og PI-er som er lagt inn i dokumentene som lovlige XML-elementer.

En prinsippskisse for strukturen i et enkelt script kan se slik ut:

Script and contents

Vi kan si at vi konstruerer sidene P1 og P2 slik:

P1=wxt(T,C1,C3)
P2=wxt(T,C2,C4)

Selve scriptet kan være slik:

<?xml version="1.0" encoding="utf-8"?>
<wscript version="1.0">
<defintions>
  <template id="T" location="templates/t_template.xml"/>
</defintions>
  <module name="p1" location="pages/p1.xml" template="T">
    <xmlcontent location="contents/c1.xml"/>
    <xmlcontent location="contents/c3.xml"/>
   </module>
    <module name="p2" location="pages/p2.xml" template="T">
      <xmlcontent location="contents/c2.xml"/>
      <xmlcontent location="contents/c4.xml"/>
    </module>
</wscript>

Hvis vi tar med en kombinasjon av alle mulige transformasjoner, og begrenser figuren til en side for oversiktens skyld, blir det slik:

Script and transformed contents

Vi transformerer begge Content-filene og Template-fila før vi bruker dem til å bygge en Page som i sin tur transformereres før den skrives til fil. Vi kan framstille konstruksjonen av siden P1 slik:

P1=t3(wxt(t1(T),t2(C1),t2(C1)))

Et utdrag av scriptet kan se slik ut

...
<transformation id="t1" location="transform/t1.xslt"/>
<transformation id="t2" location=" transform /t2.xslt"/>
<transformation id="t3" location=" transform /t3.xslt"/>
<template name="T" transformation="t1" location="templates/t3.xslt"/>

<module name="P1" template="T" transformation="t3"
      location="pages/p1.xml">
  <xmlcontent transformation="t2" location="blocks/C1.xml"/>
  <xmlcontent transformation="t2" location="blocks/C2.xml"/>
</module>
...

Når vi da vet at vi kan ta en Page som Template eller Content for en ny Page, ser vi at vi kan i prinsipp få til det meste av lenkede transformasjoner.

Foruten denne overordnede struktureringen av dokumenter i forhold til hverandre, er WXT basert på utstrakt bruk av prosesseringsinstruksjoner, PI, og XPATH-uttrykk. For eksempel vil en PI som importerer en del av en side, ingressen, kunne se slik ut:

<?_wxt importxml uri="http://www.it.hiof.no/~borres/test/p.xml"
              xpath="//div[@id='ingress']"?>

Slike PI-er er lovlig innhold i en hvilken som helst XML-dialekt og ulike programmer som betjener seg av slike tolker dem etter sine regler. Alle PI-er som starter med _wxt fanges opp av WXT. Alle andre PI-er forblir ubehandlet og kan eventuelt behandles av andre programmer senere. For eksempel er PHP basert på PI-er på en vevside.

Disse grunnfunksjonene er i seg selv ikke spesielt krevende å implementere ved hjelp av en rimelig god DOM-API, og utgjør et ganske tynt skikt av kode mot den funksjonaliteten som finnes i API-en. WXT er interessant fordi det går et par steg videre i å legge sammensatte operasjoner til rette på en strukturert måte og ved at det er en kombinasjon mellom XML generelt og XHTML spesielt.

Det er en rekke andre funksjoner som er definert for WXT, men det vil føre for langt å gå gjennom alle disse her.