Skip to main content
N
naglists1-Visitor
1-Visitor
February 22, 2011
Question

xsl question: converting < to < (and disabling output escaping if necessary)

  • February 22, 2011
  • 14 replies
  • 4508 views
Hi,
Support has said that datamerge is working as designed by returning
(as stored in the database) as and that it is up to me to convert
markup from < to < on output via the XSLT. That conversation is ongoing.

BUT if one of you XSL gurus knows how to do this, maybe I can leave support
alone.

I have tried swapping the overall output method to text (that was a hail
mary) and believe this is the "best" answer but it fails:
<xsl:value-of select="translate(self::node(),'&lt;','&lt;')"&lt;br"/>disable-output-escaping="yes"/>

The following "works" in that it returns the string to Editor with a ! where
there should be a < so the select and the translate are working:
<xsl:value-of select="translate(self::node(),'&lt;','!')"&lt;br"/>disable-output-escaping="yes"/>

All attempts to use the < fail with the following:
FATAL ERROR:
javax.xml.transform. TransformerException: Error reported by XML parser.

ERROR:
Failed to update query: (my query name)
com.arbortext.epic.datamerge.DataMergeException: Failed to construct XSL
Stylesheet transformer.



Any thoughts?

(FWIW: Michael Kay can be found responding to this question (more or less),
in his own inimitable way, "Fix the #$#% program generating the bad
markup!")

--
Paul Nagai

    14 replies

    Show previous replies
    N
    naglists1-VisitorAuthor
    1-Visitor
    February 28, 2011
    Ok, my datamerge is now returning XML to Editor! Whoo hoo!

    Setting parseResultSet to true in the DMF does have the desired result BUT
    you must also change the top level template in the sample XSL from:
    <xsl:template match="/">

    To:
    <xsl:template match="@*|node()">

    OR include a template for each element that might be returned by the query.

    I wasn't paying attention to the XSL ... I was assuming something was wrong
    with the Datamerge itself. This XSL "error" exists in the hardware.xsl
    packaged in the Excel sample, so when I tried implementing parseResultSet
    before (based on scant documentation in one of the .ent files support
    pointed me to), while it changed my output, it did not have the desired
    result. Clay's assertion that he'd gotten it to work allowed m to look
    beyond Datamerge and look more closely at the XSL (and take another look at
    the raw XML being returned).

    There is still a problem with the way that numeric data is handled, but the
    SPR is open and will hopefully be addressed in a release soon.

    Thanks everyone.

    N
    naglists1-VisitorAuthor
    1-Visitor
    March 1, 2011
    Doh! From:
    <xsl:template match="/">
    <xsl:apply-templates/>
    </xsl:template>

    To:
    <xsl:template match="@*|node()">
    <xsl:copy>
    <xsl:apply-templates/>
    </xsl:copy>
    </xsl:template>


    B
    bibach1-Visitor
    1-Visitor
    March 1, 2011
    On Mon, Feb 28, 2011 at 6:04 PM, Paul Nagai <-> wrote:
    > Doh! From:
    > <xsl:template match="/">
    > <xsl:apply-templates/>
    > </xsl:template>
    >
    > To:
    > <xsl:template match="@*|node()">
    > <xsl:copy>
    > <xsl:apply-templates/>
    > </xsl:copy>
    > </xsl:template>

    Better make that...

    <xsl:template match="@*|node()">
    <xsl:copy>
    <xsl:apply-templates select="@*|node()"/">
    </xsl:copy>
    </xsl:template>

    ...or you'll lose your attributes. The default for an attribute-less
    xsl:apply-templates is select="node()", which does not include
    attributes.

    One gotcha you may want to keep an eye out for is mishandling of
    content in columns that are not intended to be parsed as XML. A stray
    "<" or "&" could cause some errors or odd results. Unfortunately, the
    "parseResultSet" solution is a broad stroke. Perhaps a future
    enhancement to datamerge will provide more granular control, such as
    support for the XML datatype standardized with (IIRC) SQL2003.

    -Brandon Smiley Happy
    N
    naglists1-VisitorAuthor
    1-Visitor
    March 1, 2011
    Good catch. Noted!

    On Mon, Feb 28, 2011 at 3:25 PM, Brandon Ibach <
    brandon.ibach@single-sourcing.com> wrote:

    >
    Terms & ConditionsAccessibility statement