hoe hou je een state bij met XSLT?

[Bananenplant]

ik moet met een paar kameraden voor een project een validator maken die checkt of de inputs in een xml-document voldoen aan de eisen opgesteld in een ander xml-document. op zich zal dit wel lukken, maar er wordt vervolgens een error report verlangd:

code:

<report>
<ok>
</report>

als het goed is en

code:

<report>
<error>fout bij item 1: (verder geblaat)</error>
<error>fout bij item 5: (verder geblaat)</error>
</report>

als het fout is

ons probleem is het volgende: we hebben geen manier om bij te houden of er fouten zijn opgetreden. in een ordentelijke programmeertaal zou je een boolean declareren om de state bij te houden hierover, maar wat ze in XSLT 'variabele' noemen is gewoon een constante .
hebben jullie een idee van hoe je zoiets aan zou kunnen pakken? een <report>-object met meerdere ok's (voor elke geslaagde test) en fouten is niet zo moeilijk, maar dat wil de opdrachtgever weer niet ^^;; !

[ Voor 8% gewijzigd door Bananenplant op 26-02-2003 11:39 . Reden: tags vergeten ]

[whoami]

Kan je dat dan? Ik bedoel, ik heb XSLT nog nooit echt aanzien als een programmeertaal. (Misschien zit ik hier wel fout, maar goed).
Ik zie XSLT als een manier om een XML document mbhv een XSL stylesheet te transformeren naar een ander XML document, of een HTML pagina, oid....

Nouja, ik weet te weinig af van XSLT en XSL om daar een goed antwoord op te weten, en ik weet ook niet of mijn bovenstaande stelling wel juist is, dus zal ik me maar beperkten tot wat lurken in dit topic.
_{ff wachten op mbravenboer ofzo...}

[mbravenboer]

ucchan: wat ze in XSLT 'variabele' noemen is gewoon een constante .

Het is misschien verwarrend, maar toch is een XSLT variabele echt variabel. Het is namelijk een wiskundige variabele: de waarde van de variabele ligt niet vast in de XSL Transformatie (vergelijk met expressie, logische formule, functie), maar verschilt per toepassing van de transformatie (of template voor lokale variabelen). Hij is dus variabel per toepassing en niet variabel tijdens een toepassing. Dat kan je inderdaad constant noemen als je dat wilt .

De oplossing is om functioneel te denken. Helaas wordt functioneel denken alleen weer zo matig door XSLT ondersteunt dat het je niet bepaald gemakkelijk wordt gemaakt om te leren functioneel te gaan denken.

Ik denk dat de beste tip die je kan krijgen een verwijzing is naar de EXSLT node-set functie (die ondersteunt wordt door erg veel XSL processors), of nog mooier: XSLT 2.0 (neem bijvoorbeeld Saxon).

Je kan met de node-set functie of XSLT 2.0 namelijk opnieuw templates gaan toepassen op resultaten van templates. In XSLT 1.0 is dit niet mogelijk, waardoor je dus altijd je hele transformatie in 1 keer moet implementeren. Dit is vaak gewoon erg lastig.

Als je opnieuw templates kan gaan toepassen kan je je transformatie opdelen in meerdere stappen en wordt het dus allemaal een stuk eenvoudiger.

Voor meer info kan je uiteraard naar de website van EXSLT gaan: http://www.exslt.org of bekijk de XSLT 2.0 working drafts. De implementatie van Saxon kan je hier vinden: http://saxon.sourceforge.net/ .

In dit webgoeroe.net nieuwtje: http://www.webgoeroe.net/item/1053 staat nog een link naar een artikel bij IBM over de toepassing van EXSLT en de node-set functie.

[ Voor 5% gewijzigd door mbravenboer op 26-02-2003 11:55 ]

[mbravenboer]

whoami: ik heb XSLT nog nooit echt aanzien als een programmeertaal. (Misschien zit ik hier wel fout, maar goed).

Het ligt er maar net aan wat je als programmeertaal ziet, maar XSLT zou over het algemeen toch wel onder de definitie van een programeertaal vallen .

[Bananenplant]

ik vind het wel net zoiets vaags als het feit dat er geen stringvergelijking bestaat maar wel functies om de lengte van een string te geven of substrings te zoeken. net alsof ze je willen pesten ofzo.

maar we zullen er eens goed naar kijken !

/edit: het aantal nuttige dingen dat er met google te vinden valt is wel mager, hoor. kun je misschien een voorbeeld geven^^? ik heb wel dingen gezien waardoor er xsl ipv xml opgeleverd werd....

[ Voor 29% gewijzigd door Bananenplant op 26-02-2003 12:55 ]

[mbravenboer]

ucchan: ik vind het wel net zoiets vaags als het feit dat er geen stringvergelijking bestaat maar wel functies om de lengte van een string te geven of substrings te zoeken.

Het probleem is dat de 'API' van XSLT in de standaard van de taal zelf is opgenomen. Dit zorgt voor een minimalistische neiging in het aantal beschikbare functies en dat is niet goed. EXSLT biedt hiervoor ook de oplossing.

kun je misschien een voorbeeld geven^^?

Waarvan? Van het gebruiken van meerdere transformatie ronden? Dat kan ik wel doen, maar geef dan even aan wat je wilt zien .

[Bananenplant]

nou, bijvoorbeeld:

code:

<result>
<ok />
<ok />
<ok />
</result>

naar:

code:

<result>
<ok />
</result>

en:

code:

<result>
<ok />
<ok />
<error>fout1</error>
<ok />
<error>fout2</error>
</result>

naar:

code:

<result>
<error>fout1</error>
<error>fout2</error>
</result>

ik vraag me dus af hoe je nu de output (dit wat ik net neerzette zou nu gegenereerd kunnen worden) naar die functie direct en hoe je die vervolgens benadert.

[mbravenboer]

Ok, dat zijn mooie voorbeelden. Ik zal een voorbeeld maken met XSLT 2.0. Die kan je dan zelf omzetten naar EXSLT als je geen Saxon mag/kan gebruiken.

[mbravenboer]

Ik heb wat gemaakt. Het is niet echt netjes, maar het illustreert de aanpak wel goed denk ik. In een nette aanpak zou je de "ok" eigenlijk moeten vervangen door een identity transformatie zodat er simpelweg error knopen in de output ontstaan.

Transformatie:

XML:

<xsl:transform
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  version="2.0">

  <xsl:output method="xml"/>
  
  <!-- result with error messages -->  
  <xsl:variable name="temp">
    <xsl:apply-templates select="/" mode="validate"/>
  </xsl:variable>
    
  <!-- main -->
  <xsl:template match="/">
    <debug>
      <validated>
        <xsl:copy-of select="$temp"/>
      </validated>
      <result>
        <xsl:apply-templates select="$temp" mode="finish"/> 
      </result>
    </debug>
  </xsl:template>
  
  <!-- validating -->
  <xsl:template match="a[c]" mode="validate">
    <error>content model of a doesn't allow a c</error>
  </xsl:template>
 
  <xsl:template match="*" mode="validate">
    <ok>
      <xsl:apply-templates select="*" mode="validate"/>
    </ok>
  </xsl:template>

  <!-- creating a result -->
  <xsl:template match="*[//error]" mode="finish">
    <xsl:copy-of select="//error"/>
  </xsl:template>
  
  <xsl:template match="*[count(//error) = 0]" mode="finish">
    <ok/>
  </xsl:template>

</xsl:transform>

Input:

XML:

<a>
  <b/>
</a>

Output:

XML:

<?xml version="1.0" ?>

<debug>
  <validated>
    <ok>
      <ok/>
    </ok>
  </validated>
  <result>
    <ok/>
  </result>
</debug>

Input:

XML:

<a>
  <a>
    <c/>
  </a>
  <a>
    <c/>
  </a>
</a>

Output:

XML:

<?xml version="1.0" ?>

<debug>
  <validated>
    <ok>
      <error>content model of a doesn&apos;t allow a c</error>
      <error>content model of a doesn&apos;t allow a c</error>
    </ok>
  </validated>
  <result>
    <error>content model of a doesn&apos;t allow a c</error>
    <error>content model of a doesn&apos;t allow a c</error>
  </result>
</debug>

Overigens is dat allemaal veel netter te doen in een echte transformatie taal. XSLT voelt voor dergelijke serieuze transformaties gewoon niet lekker aan: het is erg goed in het template gebaseerd herschrijven van XML constructies, maar veel meer moet je er niet mee doen.

[Anoniem: 34810]

offtopic:
[quote]whoami schreef op 26 februari 2003 @ 11:52:
Ik bedoel, ik heb XSLT nog nooit echt aanzien als een programmeertaal. [/quote]

leesvoer ;)

[ari3]

ucchan schreef op 26 February 2003 @ 12:16:
ik vind het wel net zoiets vaags als het feit dat er geen stringvergelijking bestaat maar wel functies om de lengte van een string te geven of substrings te zoeken. net alsof ze je willen pesten ofzo.

Er bestaan wel degelijk stringvergelijkingen in XSLT. Voorbeelden:

code:

$str1=$str2
'abc'='def'
$var='een tekst'
a/b/c/text()=d/e/f/text()

Men had er goed aan gedaan meteen een match en replace functie in de standaard op te nemen en dingen als string-length en substring achterwege te laten. Immers kun je met een reguliere expressie alle mogelijke validatie-, vergelijkings-, zoek- en vervangoperaties doen.

[terzijde]Deze onwerp fout wordt telkens opnieuw gemaakt: men verzint een taal en bedenkt dan sterk limiterende functies voor text-operaties. Uiteindelijk zie je dan altijd dat er toch functies voor het toepassen van reguliere expressies opgenomen in een latere versie van de standaard. Voorbeelden: JavaScript 1.3 en Java2 1.4[/terzijde]

[mbravenboer]

ari3 :Men had er goed aan gedaan meteen een match en replace functie in de standaard op te nemen [reguliere expressie]

We hebben het hier al eens over reguliere expressies in XSLT gehad. In XSLT 2.0 zal er inderdaad de mogelijkheid voor het matchen van strings tegen patterns komen, maar eerlijk gezegd kan ik er niet echt blij van worden.

XML is bedoeld om data gestructureerd te representeren in de vorm van een boom. Het is daarmee vergelijkbaar met een abstract syntax tree representatie van een stuk concrete syntax. De XML structuur zou daarom zo gestructureerd moeten zijn dat de structuur van de tekst knopen irrelevant is. Helaas zie je dit vaak erg fout gaan. XSLT gebruikt een concrete syntax voor XPath, SVG gebruikt een heel ranzig systeem voor path data, XHTML gebruikt concrete syntax om een CSS style te verbinden aan een XHTML element. W3C XML Schema definieert een concrete syntax voor datums en ga zo meer door.

Dit ondermijnt het hele concept van XML. Als de transformatie-taal voor XML dit nu ook nog gaat aanmoedingen door structuur in tekst te kunnen gebruiken, is er grote kans dat er nog meer XML talen komen die niet begrijpen wat XML is.

[Bananenplant]

zo, we zijn een eind op weg en nog bezig... we zitten nog wel met het probleem dat we niet weten wat de match moet zijn ipv "/" als we intern het truukje ook weer toe willen passen (we willen namelijk uitvinden of een radiobutton een valide waarde heeft en dus ook 1 error geven ipv "rood is niet blauw" "rood is niet geel" etc).

iig bedankt !

[ari3]

mbravenboer schreef op 27 February 2003 @ 12:31:
[...]
De XML structuur zou daarom zo gestructureerd moeten zijn dat de structuur van de tekst knopen irrelevant is. Helaas zie je dit vaak erg fout gaan. XSLT gebruikt een concrete syntax voor XPath, SVG gebruikt een heel ranzig systeem voor path data, XHTML gebruikt concrete syntax om een CSS style te verbinden aan een XHTML element. W3C XML Schema definieert een concrete syntax voor datums en ga zo meer door.

In een XML document is de structuur van de tekstknopen slechts irrelevant als het platte tekst ofwel ongetypeerde data bevat. En zelfs over platte tekst kun je nog discussies hebben of dat zo is. Met het toepassen van een schema kun je hooguit garanderen dat een tekstknoop een bepaalde structuur heeft. In de context van presentatie van gegevens uit een XML document is de structuur wel degelijk van belang.

Dit ondermijnt het hele concept van XML. Als de transformatie-taal voor XML dit nu ook nog gaat aanmoedingen door structuur in tekst te kunnen gebruiken, is er grote kans dat er nog meer XML talen komen die niet begrijpen wat XML is.

Waar jij bang voor bent is dat uit een tekstknoop de structuur van het XML document afgeleid zou moeten worden (bijvoorbeeld doordat er zowel een datum in JJJJMMDD als DDMMJJJJ formaat in zou kunnen staan). Je hebt gelijk als je stelt dat dit onwenselijk is.

Dit gezegt, moet het wel mogelijk blijven om structuur in tekst te kunnen gebruiken en wel om deze reden:

De enige manier om een bepaalde knoop uit een XML document te krijgen is het aanleggen van selectiecriteria. Deze criteria beperken zich niet tot het aanwezig zijn van een zeker element of knoop, maar vaak ook de inhoud van een tekstknoop of een attribuut. En soms ook de structuur van de tekstknoop. Dit is inherent aan de doelstelling, namelijk: het transformeren.

[mbravenboer]

ari3: In een XML document is de structuur van de tekstknopen slechts irrelevant als het platte tekst ofwel ongetypeerde data bevat.

De informatie die een XML document bevat wordt vaak aangeduid met de InfoSet. De tekst in een tekst node is in deze InfoSet slechts pure tekst. Vanuit XML oogpunt zou je geen structuur op moeten nemen in deze tekst omdat het geen onderdeel is van de structuur die je terug ziet in de InfoSet.

Concrete syntax voor datums (zoals 2003-02-27 of 20030227 of wat dan ook) is daarom slecht: het bevat een structuur die niet zichtbaar is in de structuur van het XML document. Waarom gebruiken we nu uberhaupt XML?

soms ook de structuur van de tekstknoop. Dit is inherent aan de doelstelling, namelijk: het transformeren.

Nee, de doelstelling is het transformeren van XML. Als het XML document niet voldoende gestructureerd is moet je naar de inhoud van de tekst gaan kijken en inderdaad heb je dan dus middelen als reguliere expressies over karakters hard nodig.

Het is natuurlijk onrealistisch om te gaan eisen dat dit in alle situaties niet nodig zal zijn omdat je uiteraard ergens een grens moet gaan trekken. Ik ben wel bang dat wanneer regexp matching als een spannende nieuwe features van XSLT gepresenteerd wordt, het gebruik van substructuur in tekst knopen alleen nog maar zal toenemen.

[Anoniem: 66949]

Als je toch een error report gaat uitvoeren; zou ik ook de lijnnummer en kolomnummer meegeven waar de fout bevind. Als dit mogelijk is in XSLT.

[Bananenplant]

heh bah, we hebben het voorelkaar met saxon, maar ineens blijkt ie het met xalan te moeten doen . en dat doettie net niet... een fout dat hij een #RFREEFRAG niet naar een NodeList kan converteren .

[mbravenboer]

De nieuwere Xalans ondersteunen ook EXSLT dus je kan dan EXSLT's node-list gebruiken om een zo'n result fragement om te zetten naar nodes die je weer opnieuw kan transformeren.

Als je op een oudere Xalan werkt moet je upgraden of uitzoeken wat de processor specifieke functie is om dit te doen.

[mbravenboer]

Zie: http://xml.apache.org/xalan-j/extensionslib.html