[XSL] XML nodes met NULL values

[Fatamorgana]

Ik zit met het volgende probleem:

In een XML document komt het resultaat van een query te staan, dus alle database record fields komen als nodes in de XML. Nu zijn er soms ook waarden in de database NULL. Dan komen deze ook als NULL values in de XML tree.

Dan ga ik deze XML matchen met een XSL sheet en dan gaat ie over zijn nek bij die NULL values (Nullpointer exception). Heel logisch, maar hoe kan ik in XSL testen op NULL values? Ik mag deze nodes wel in een variabele zetten, op het beeld zetten enzo, maar er iets mee doen zoals vergelijkingen of andere operaties ho maar.

Weet iemand hier een oplossing voor, want dit is echt heel lastig...

[gorgi_19]

Kan je je query anders niet aanpassen, in de trant van

code:

Select (IsNull(veldnaam,' ') as Ikke) FROM tabelnaam

[mbravenboer]

Fatamorgana: In een XML document komt het resultaat van een query te staan, dus alle database record fields komen als nodes in de XML. Nu zijn er soms ook waarden in de database NULL. Dan komen deze ook als NULL values in de XML tree.

Een hoe zien deze NULL values er dan uit in XML?

In de XML Schema recommendation wordt een standaard methode voor een Null Values aangegeven. Dit zou je eventueel kunnen gebruiken, maar met een eigen mechanisme als bijvoorbeeld <null/> is ook helemaal niets mis.

Dan ga ik deze XML matchen met een XSL sheet en dan gaat ie over zijn nek bij die NULL values (Nullpointer exception). Heel logisch

Dat is helemaal niet logisch: XSLT kent helemaal geen notie van NullPointers, dat is een begrip uit veel imperatieve programmeer-talen. Het lijkt mij eerlijk gezegd vrijwel onmogelijk dat door de aanwezigheid van een NULL waarde (hoe die ook is gerepresenteerd is in XML) een NullPointerException onstaat tijdens de transformatie.

maar hoe kan ik in XSL testen op NULL values? Ik mag deze nodes wel in een variabele zetten, op het beeld zetten enzo, maar er iets mee doen zoals vergelijkingen of andere operaties ho maar.

Je omschrijvingen kloppen absoluut niet met wat XSLT normaal doet. Weet je wel zeker dat je echt XSLT gebruikt? XSLT kent geen notie van 'op het beeld zetten' en kent alleen immutable variabelen.

Als je XSLT gebruikt, is de oplossing vrij eenvoudig:

1. Kies (of bepaal) hoe NULL waarden worden omgeslagen in het XML document.

2. Maak aparte templates voor velden met NULL waarden en doe daar mee, wat je wilt.

XSLT is volledig gebaseerd op pattern-matching in de vorm van XPath, dus het is een eitje om op NULL waarden te matchen.

[Fatamorgana]

Op zondag 14 juli 2002 19:41 schreef mbravenboer het volgende:

[..]
Dat is helemaal niet logisch: XSLT kent helemaal geen notie van NullPointers, dat is een begrip uit veel imperatieve programmeer-talen. Het lijkt mij eerlijk gezegd vrijwel onmogelijk dat door de aanwezigheid van een NULL waarde (hoe die ook is gerepresenteerd is in XML) een NullPointerException onstaat tijdens de transformatie.
[..]

Misschien moet ik er bij zeggen dat ik dit alles met Java (Servlets) doe. Alles gebeurt dus in het geheugen en daar kan zeker wel een NULL value staan.

XSLT kent geen notie van 'op het beeld zetten' en kent alleen immutable variabelen.

Met op het beeld zetten bedoel ik dat ik deze variable met bv: XSL:VALUE-OF SELECT="mijnval" neerzet.

XSLT is volledig gebaseerd op pattern-matching in de vorm van XPath, dus het is een eitje om op NULL waarden te matchen.

Probeer maar eens een pattern te matchen met een NULL value, dan krijg je echt een null pointer exception.

[mbravenboer]

Fatamorgana: Misschien moet ik er bij zeggen dat ik dit alles met Java (Servlets) doe. Alles gebeurt dus in het geheugen en daar kan zeker wel een NULL value staan.

XSL transformaties kennen helemaal geen notie van null. Als jij een XPath expressie wilt evalueren met value-of of apply-templates en er staat daar een null waarde, dan levert de expressie gewoon niets op. Een NullPointerException is daarom helemaal geen normale XSLT fout, tenzij het een implementatie fout is, wat mij onwaarschijnlijk lijkt.

Probeer maar eens een pattern te matchen met een NULL value, dan krijg je echt een null pointer exception.

Sorry, maar dat is echt onzin. Het kan best zijn dat die NullPointerException ergens ontstaat, maar dit komt niet door de XSL Transformatie. Null is uberhaupt geen onderdeel van XML, laat staan dat er een NullPointerException kan ontstaan.

Null wordt zoals ik al probeerde aan te geven gewoon op een bepaalde manier gerepresenteerd in het XML document. Je moet uitzoeken hoe dit wordt gerepresenteerd en daarmee rekening houden in je transformatie.

Je moet je probleem eens netjes onderverdelen in stappen: (1) bekijk hoe de XML eruit ziet. Wordt de XML uberhaupt wel netjes opgebouwd? Treedt daar misschien al niet een exception op? (2) bepaal waarnaar je deze XML wilt transformeren. (3) schrijf een transformatie die de input naar de gewenste output transformeert.

[Fatamorgana]

Ik zal vandaag wel ff een voorbeeld geven met output, dan kun je zien hoe het in elkaar zit. De XML is goed en de XSL ook, zolang er geen NULL waarden uit de database komen. Als er geen records uit de query komen met NULL dan geen error en heb ik alles op het scherm staan. Dus het gaat echt fout daar.

[mbravenboer]

Fatamorgana: Ik zal vandaag wel ff een voorbeeld geven met output

Ok, dat is prima. Dat praat een stuk makkelijker en dan kan ik wellicht even een voorbeeld geven .

Laat als het even kan het XML resultaat van de query zien, de transformatie die je daarop wilt uitvoeren (XSLT dus) en een schetsje van het gewenste resultaat .

[Fatamorgana]

Op maandag 15 juli 2002 06:42 schreef mbravenboer het volgende:

[..]
Laat als het even kan het XML resultaat van de query zien, de transformatie die je daarop wilt uitvoeren (XSLT dus) en een schetsje van het gewenste resultaat .

Ik moet ff wachten tot ik op m'n werk ben, maar dan geef ik alle info die ik heb. Het is echt een rot probleem en ik hoop dat het op te lossen is. Ik ben nog niet zo super lang met XML/XSL aan het werken dus als ik soms niet alles in 1 keer zie kan dat goed kloppen. Maar al doende leert men.

[Croga]

Ik zie dat je een deel met een Java servlet doet... Ontstaat de exception niet in het Java gedeelte? Dan wordt ie mischien als letterlijke "NullPointer Exception" doorgegeven aan de XSLT.....

[Fatamorgana]

Hier alle info:

Allereerst een stukje XML:

code:

<result>
  <record>
    <id>3</id>
    <targetgroup>Everyone</targetgroup>
    <utgid>5</utgid>
  </record>
  <record>
    <id>2</id>
    <targetgroup>ICT medewerker</targetgroup>
    <utgid></utgid>
  </record>
</result>

Dan een stukje xml die iets doet met de utgid:

code:

<xsl:if test="utgid=1">
  yo
</xsl:if>

Dan de output in de browser:




En als laatste een stukje van de error:

utgidjava.lang.NullPointerException at org.apache.xml.utils.TreeWalker.dispatachChars(TreeWalker.java:259) at org.apache.xml.utils.TreeWalker.startNode(TreeWalker.java:403) at org.apache.xml.utils.TreeWalker.traverse(TreeWalker.java:167) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:325)


Zoals te zien is, gaat de eerste output wel goed omdat er een waarde staat in de utgid, de tweede is echter leeg, maar in memory is dit dus de beruchte NULL. Die vergelijking die ik dan doe in XSL geeft dan ook netjes een NullPointerException...

[mbravenboer]

Fatamorgana: En als laatste een stukje van de error

Hum.... als de fout echt hierdoor wordt veroorzaakt (en dat lijkt er wel op omdat de fout uit org.apache.xml.utils.TreeWalker komt) is het een grove implementatie fout in Apache's Xalan.

Ik zou graag even de volledige stylesheet willen hebben zodat ik hem even kan draaien. Misschien dat een nieuwere Xalan versie het probleem oplost voor je.

Die vergelijking die ik dan doe in XSL geeft dan ook netjes een NullPointerException...

Dat zou niet moeten mogen: de test zou gewoon moeten falen (false opleveren). Er is helemaal geen notie van null in XML en ook niet in XSLT. Deze test mag daarom nooit een NullPointerException opleveren...

Overigens zou ik zelf liever

code:

utgid/text() = '1'

gebruiken omdat utgid een XML element is. Vergelijken op de manier zoals jij doet is waarschijnlijk wel toegestaan, maar ik vind het niet zo duidelijk. Je hebt kans dat hiermee je probleem ook al opgelost is, maar dat zou dan eerder het karakter van een workaround hebben dan dat van een echte oplossing .

Voor zover ik het nu kan zien lijkt het dus een implementatie fout in Xalan en kan jij er niets aan doen behalve het downloaden van een nieuwe versie of het vinden van een work-around.

[mbravenboer]

PS:

mbravenboer: Ik zou graag even de volledige stylesheet willen hebben zodat ik hem even kan draaien.

Of als die erg groot is een draaibaar relevant stuk .

[Fatamorgana]

Op maandag 15 juli 2002 09:55 schreef mbravenboer het volgende:
PS:
[..]

Of als die erg groot is een draaibaar relevant stuk .

Ik ga ff een stukkie bruikbaar XSL geven, alleen moet je dan wel ff deze XML met Java genereren om er ook echt NULL values in te kunnen schieten.

[mbravenboer]

Ik werk altijd met Java, dus das geen probleem . M'n standaard shell-scripts om XSLT toe te passen werken ook gewoon met trax (en dus Xalan) via deze lib.

[Fatamorgana]

Ik heb zoveel mogelijk overbodige info er uit gelaten, ik hoop dat dit genoeg is, de XML plus XSL:

code:

<xmlstart>
  <island name="gettargetgroups">
    <result>
    <record>
      <id>3</id>
      <targetgroup>Everyone</targetgroup>
      <utgid>5</utgid>
    </record>
    <record>
      <id>2</id>
      <targetgroup>ICT medewerker</targetgroup>
      <utgid></utgid>
    </record>
    </result>
  </island>
</xmlstart>


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:template match="/">
  <html>
    <head>
    <title>Test</title>
    </head>
    <body bgcolor="#999999" link="#ffffff">
    <form name="inputform" action="doeiets" method="post">
      <xsl:for-each select="//island[@name='gettargetgroups']//result/record">
        <input type="checkbox">
        <xsl:attribute name="name">
          <xsl:value-of select="concat('tgid_', position())"/>
        </xsl:attribute>
        <xsl:attribute name="value">
          <xsl:value-of select="id"/>
        </xsl:attribute>
        </input>
        <xsl:value-of select="targetgroup"/>
      </xsl:for-each>
      <input name="action" type="submit" value="Save"/>
    </form>
    </body>
  </html>
</xsl:template>
</xsl:stylesheet>

Het is dus de bedoeling dat die checkboxen wel of niet gechecked gaan worden. Als in de utgid iets staat dan is ie checked en als ie NULL is dus niet. Deze check zit er nu niet in, want die levert die Exception op, maar zal dus bij die attribute moeten komen.

[Stephan Oudmaijer]

Probeer het eens met een andere transformer

code:

javax.xml.transform.TransformerFactory factory= javax.xml.transform.TransformerFactory.newInstance();
javax.xml.transform.Transformer transformer= factory.newTransformer( new javax.xml.transform.stream.StreamSource( pageContext.getServletContext().getRealPath( stylesheet ) ) );
transformer.transform(new javax.xml.transform.stream.StreamSource(new java.io.StringReader(xmlString)), new javax.xml.transform.stream.StreamResult( response.getWriter() ) );

new java.io.StringReader(xmlString) mag ook een document zijn o.i.d.

[mbravenboer]

Ok, ik check het zo ff thuis (kan ruim uurtje duren voordat ik daar ben). Waar ik nu zit heb ik al m'n tools niet zo lekker bij de hand.

Die XSL Formatting Objects namespace lijkt me trouwens sowieso al niet zo nodig .

CK :Probeer het eens met een andere parser

Aangezien de fout in Apache coe onstaat neem ik aan dat hij al via javax.xml.transform met Xalan werkt...

[Fatamorgana]

Yep, ik gebruik Xalan.

[Fatamorgana]

utgid/text() = '1' geeft trouwens ook een NullPointerException...

[mbravenboer]

Fatamorgana: utgid/text() = '1' geeft trouwens ook een NullPointerException...

Hum maf...

We zoeken het ff uit . Moment.

[mbravenboer]

Hum.... ik krijg eigenlijk in geen enkel geval een foutmelding als ik iets met de if-check erbij zet.... Misschien gebruik je een hele oude versie van JAXP? Ik gebruik Java 2 v1.4.0.

Ik heb van de gelegenheid gebruik gemaakt om je stylesheet even wat te verbouwen zodat hij wat mooier wordt . Dit resultaat werkt dus in 1.4.

Input:

code:

<?xml version="1.0"?>

<xmlstart>
  <island name="gettargetgroups">
    <result>
    <record>
      <id>3</id>
      <targetgroup>Everyone</targetgroup>
      <utgid>5</utgid>
    </record>
    <record>
      <id>2</id>
      <targetgroup>ICT medewerker</targetgroup>
      <utgid></utgid>
    </record>
    </result>
  </island>
</xmlstart>

Transformatie (merk de meerdere templates op):

code:

<?xml version="1.0"?>

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

  <xsl:output method="xml" indent="yes" encoding="UTF-8"/>

  <xsl:template match="xmlstart">
    <html>
    <head>
      <title>Test</title>
    </head>
    <body>
      <xsl:apply-templates select="island"/>
    </body>
    </html>
  </xsl:template>

  <xsl:template match="island[@name='gettargetgroups']">
    <form name="inputform" action="doeiets" method="post">
    <xsl:apply-templates select="result/record"/>
    <input name="action" type="submit" value="Save"/>
    </form>
  </xsl:template>

  <xsl:template match="record">
    <input type="checkbox" name="{ concat('tgid_', position()) }" value="{id}">
    <xsl:if test="string-length(utgid/text()) > 0">
      <xsl:attribute name="checked">true</xsl:attribute>
    </xsl:if>
    </input>
    <xsl:value-of select="targetgroup"/>
  </xsl:template>
</xsl:transform>

en tot slot het resultaat (allemaal niet bepaald valid XHTML waarschijnlijk, maar goed...)

code:

<?xml version="1.0" encoding="UTF-8"?>

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Test</title>
  </head>
  <body>
    <form method="post" action="doeiets" name="inputform">
    <input value="3" name="tgid_1" type="checkbox" checked="true"/>Everyone
    <input value="2" name="tgid_2" type="checkbox"/>ICT medewerker
    <input value="Save" type="submit" name="action"/>
    </form>
  </body>
</html>

[Fatamorgana]

Dus jij schiet echte NULL values in de XML nodes en dan gaat ie niet over zijn nek bij de transformatie?

[mbravenboer]

Fatamorgana: Dus jij schiet echte NULL values in de XML nodes en dan gaat ie niet over zijn nek bij de transformatie?

Hum... ik heb al een paar keer geprobeerd aan te geven dat XML geen null kent .

Null wordt hier gerepresenteerd als een leeg XML element, wat helemaal niets met null te maken heeft. Je moet dus niet denken in termen van null waarden, maar in termen van XML elementen en de structuur daarvan.

Ik controleer of een element leeg is met behulp van de string-length function call en een vergelijking > 0. Dit kan misschien nog wel beter of leuker, maar het functioneert.

[Fatamorgana]

Op maandag 15 juli 2002 12:13 schreef mbravenboer het volgende:

[..]

Hum... ik heb al een paar keer geprobeerd aan te geven dat XML geen null kent .

Ik weet wat jij bedoelt, ik ga ff een voorbeeld zoeken om aan te geven wat ik bedoel. In mijn situatie heb ik toch echt NULL values die in de XML tree worden geschoten, maar dat ga ik duidelijk proberen te maken. Dus ff wachten tot ik alles bij elkaar heb gezocht.

[mbravenboer]

Fatamorgana: In mijn situatie heb ik toch echt NULL values die in de XML tree worden geschoten, maar dat ga ik duidelijk proberen te maken. Dus ff wachten tot ik alles bij elkaar heb gezocht.

Ik ben benieuwd .

Nog even om aan te geven wat ik denk dat jij bedoelt. Dit is het resultaat als utgid de waarde null heeft:

code:

<utgid></utgid>

Je ziet hierboven hoe ik hier rekening mee houdt in de transformatie: er komt immers een ander resultaat uit.

Als ik je helemaal verkeerd begrijp moet je even een stukje XML posten met iets wat nog NULL zou moeten zijn .

[Fatamorgana]

Een heel klein stukje van de code:

code:

Document d = null;
d = builder.newDocument();
d.createTextNode(rs.getString(i));

rs is een ResultSet met het resultaat van een database query. Er zijn velden in deze resultset die NULL velden van de database bevatten. Via createTextNode wordt deze waarde in de XML tree geschoten. Het resultaat van rs.getString(i) is dus NULL soms en deze gaat in de XML tree. Er zit in de XML in het geheugen dus echt een NULL value (meerdere) en tijdens transformeren gaat ie op zijn bek.

Ik hoop dat dit helpt???

In memory staat dus tussen:<utgid> en </utgid> soms een NULL.

[tomato]

Dus je zou zeggen dat het fout gaan wanneer je createTextNode een NULL value geeft?

[mbravenboer]

Fatamorgana: Het resultaat van rs.getString(i) is dus NULL soms en deze gaat in de XML tree.

Inderdaad.

Er zit in de XML in het geheugen dus echt een NULL value (meerdere) en tijdens transformeren gaat ie op zijn bek.

Nopes, daar ga je de mist in: er zit geen null waarde in de XML waardoor een NullPointerException kan ontstaan tijdens de transformatie.

Er zit een text-node met daarin de string NULL in het XML document.
Onzin: ResultSet.getString levert geen "NULL" op, maar null.

Daarop kan je gewoon pattern-matchen:

code:

utgid/text() = 'NULL'

[mbravenboer]

tomato: Dus je zou zeggen dat het fout gaan wanneer je createTextNode een NULL value geeft?

Ah ja. dat zou ook kunnen maar dan wordt er dus helemaal geen XML opgebouwd en zit je probleem dus helemaal niet in XSLT.

Dat zou ook nog samen kunnen gaan met de foutmelding (die uit een apache package kwam) omdat de DOM implementatie ook van Apache is . Ik had al eerder vermoedens dat het niet door XSLT kwam, maar de apache namespace in de NullPointerException zetten me op het verkeerde been .

Als dit inderdaad zo is: laat het element gewoon leeg als er een null waarde wordt opgeleverd of gebruik (liever) een apart XML element om null te presenteren. Bijvoorbeeld <null/> of de XML Schema oplossing die ik eerder postte.

[Fatamorgana]

Op maandag 15 juli 2002 12:58 schreef mbravenboer het volgende:
Nopes, daar ga je de mist in: er zit geen null waarde in de XML waardoor een NullPointerException kan ontstaan tijdens de transformatie.

Toch vreemd dat ik WEL een heel XML document krijg die alleen met XSL matchen mis gaat en dan ook alleen als ik vergelijkingen ga doen. Gewoon weergeven gaat dus wel, de XML is dus goed.

Ook grappig is dat ALS ik de inhoud van die node in Java opvraag en hem print dat ik dan null op m'n scherm krijg en dit is niet dat er een text met "null" inzit. Als ik doe: if(nodeval == null) dat dit true geeft.

Nog even extra, wat er dus aan de hand is, is dat er: d.createTextNode(null) in de XML wordt gezet. En dit gaat goed, geen errors of niks, maar bij matchen is het dus raak.

[mbravenboer]

Fatamorgana: Toch vreemd dat ik WEL een heel XML document krijg die alleen met XSL matchen mis gaat en dan ook alleen als ik vergelijkingen ga doen. Gewoon weergeven gaat dus wel, de XML is dus goed.

Wacht ik weet het..... Je geeft waarschijnlijk de DOM direct aan de XSLT engine!

Hierdoor zit er dus een null waarde in de boom om de reden die tomato aangaf. Het opbouwen van die boom gaat dus goet. Het serializeren gaat kennelijk ook goed, maar meegeven aan de transformatie engine zorgt voor rare dingen als dit....

Oplossing: zorgen dat er geen null in de boom komt. Zorg zelf handmatig dat het goede resultaat in de boom komt als de waarde van een veld null is.

[Fatamorgana]

Op maandag 15 juli 2002 13:12 schreef mbravenboer het volgende:

[..]

Wacht ik weet het..... Je geeft waarschijnlijk de DOM direct aan de XSLT engine!

YEP!!!

Oplossing: zorgen dat er geen null in de boom komt. Zorg zelf handmatig dat het goede resultaat in de boom komt als de waarde van een veld null is.

Deze oplossing had ik dan ook al bedacht, maar het is wel erg arbeidsintensief om elke node die in de XML gezet wordt eerst te moeten gaan checken op null. Een echte performance killer. Ik had daarom gehoopt dat er tijdens de transformatie in XSL een functie als isnull() ofzo was die mijn probleem oploste.

[tomato]

mbravenboer: Wacht ik weet het..... Je geeft waarschijnlijk de DOM direct aan de XSLT engine!

Ik heb niet echt veel concrete ervaring hiermee, maar dat dacht ik zelf ook.

Is het dan niet vreemd dat je DOM gewoon geldig is (NULL values worden geaccepteerd), maar niet te gebruiken is door de XSLT engine? Zou deze niet gewoon iedere geldige DOM moeten accepteren? Hoe hij dan null values verwerkt is een andere vraag, maar gewoon behandelen als een empty string lijkt mij logisch...

[mbravenboer]

Fatamorgana: Deze oplossing had ik dan ook al bedacht, maar het is wel erg arbeidsintensief om elke node die in de XML gezet wordt eerst te moeten gaan checken op null.

Mwah dat valt wel mee. Je kan overal even een helper-function aanroepen:

code:

public Node blaat(String content) {
  Node result;

  if(content == null) {
    result = d.createElement("null");
  } else {
    result = d.createTextNode(rs.getString(i));
  }
}

Je krijgt dan netjes <null/> tags in je boom, waar je netjes op kan matchen in je XSL Transformatie.

Een echte performance killer.

Mwah, performance verlies zit niet in simpele if-constructies.

Ik had daarom gehoopt dat er tijdens de transformatie in XSL een functie als isnull() ofzo was die mijn probleem oploste.

Nee dus: XML kent geen null en verwacht dus ook geen null waarden in tekst-nodes. Vandaar ook dat de implementatie er over valt.

[Fatamorgana]

Dan gaan we het dus met die if constructie oplossen.

Bedankt voor alle hulp!!! (en vooral bedank tomato)

[mbravenboer]

Fatamorgana: Bedankt voor alle hulp!!!

Bedank vooral tomato maar, zonder zijn opmerking waren we wellicht nog een tijdje op zoek geweest naar de echte oorzaak van de fout .

Succes ermee verder .

[cyclone]

i like your user icon