preserving markup

Discussion in 'XML' started by David Schwartz, Jun 6, 2008.

  1. 've got some javascript and HTML I want to enter directly into my xml
    document. I've entered the JS and HTML content into a tag that's
    defined as text in the schema. When I process my xml, the > and < in
    the JS and HTML are output as named entitles &lt; and &gt;. As a
    result, this content is interpreted by the browser as page content
    rather than code/markup to be processed and rendered.

    I've tried using just the non-escaped content as well the following
    templates but the named entities always appear in the output.

    <xsl:template match="code">
    <div style="MARGIN-LEFT: 30px">
    <xsl:text disable-output-escaping="yes">&lt;![CDATA[ </
    xsl:text>
    <xsl:value-of select="."/>
    <xsl:text disable-output-escaping="yes">]]&gt;</
    xsl:text>
    </div>
    </xsl:template>

    <xsl:template match="code">
    <div style="MARGIN-LEFT: 30px">
    <xsl:value-of select="." disable-output-escaping="yes"/>
    </div>
    </xsl:template>

    Any help would be appreciated!!

    TIA,
    David
     
    David Schwartz, Jun 6, 2008
    #1
    1. Advertising

  2. Disable-output-escaping should be an absolute last-resort solution;
    there is almost always a better way.

    If your stylesheet needs to force the content of some elements to be
    output as a CDATA section to support broken downstream processing, use
    xsl:eek:utput's cdata-section-elements attribute.

    Though personally I consider that a hideous concept. No properly-written
    downstream application should care whether you use <![CDATA[]]> or
    individually escape characters; semantically those two approaches are
    exactly the same. I grant that some older tools are broken in this
    regard, but ... yecch.
     
    Joseph J. Kesselman, Jun 6, 2008
    #2
    1. Advertising

  3. If your stylesheet needs to force the content of some elements to be
    > output as a CDATA section to support broken downstream processing, use
    > xsl:eek:utput's cdata-section-elements attribute.


    Thanks for the quick response Joel. Not sure what you mean by 'broken
    downstream processing'. I'm outputing HTML (and Javascript), not XML.
    cdata-section-elements appears to be appropriate only where
    method=xml. Perhaps I'm missing something?

    Is this what you had in mind?

    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/
    Transform">
    <xsl:eek:utput omit-xml-declaration="yes" method="html" cdata-section-
    elements="code"/>
    <xsl:template match="code">
    <div style="MARGIN-LEFT: 30px">
    <xsl:value-of select="." />
    </div>
    </xsl:template>
    </xsl:stylesheet>
     
    David Schwartz, Jun 7, 2008
    #3
  4. David Schwartz

    Peter Flynn Guest

    David Schwartz wrote:
    > If your stylesheet needs to force the content of some elements to be
    >> output as a CDATA section to support broken downstream processing, use
    >> xsl:eek:utput's cdata-section-elements attribute.

    >
    > Thanks for the quick response Joel. Not sure what you mean by 'broken
    > downstream processing'.


    Browsers. Most (all?) of them are hopelessly broken when it comes to
    handling XML. Fortunately...

    > I'm outputing HTML (and Javascript), not XML.


    ....in which case you can get away with it.

    ///Peter
    --
    XML FAQ: http://xml.silmaril.ie/
     
    Peter Flynn, Jun 7, 2008
    #4
  5. Thanks but you didn't address whether the output statement was what
    was intended.
     
    David Schwartz, Jun 9, 2008
    #5
  6. David Schwartz wrote:
    > I'm outputing HTML (and Javascript), not XML.
    > cdata-section-elements appears to be appropriate only where
    > method=xml. Perhaps I'm missing something?


    Yes, <xsl:eek:utput cdata-section-elements="code"/> was what I intended.

    Some references (including Michael Kay's book, which is one of the best
    hardcopy references I've seen for XSLT) do claim that
    cdata-section-elements is marked as "not applicable to html output".
    However, I've just rechecked and I don't see that restriction in the
    XSLT Recommendation itself. All I can say is "try it, and if it doesn't
    work ask the processor's authors why not."

    But: No program ought to care whether you've used CDATA sections or
    individual-character escaping; that distinction is purely a convenience
    for humans. Any program which *insists* on one representation or the
    other is not processing the documents as intended by their spec. There
    are a few special cases where CDATA sections are worth considering --
    mostly when the document source is intended to be hand-edited by humans
    -- but even there I consider them excessively fragile. So I would also
    beat up whoever wrote the code that is foisting this requirement upon you.
     
    Joseph J. Kesselman, Jun 9, 2008
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jeremy Phillips
    Replies:
    1
    Views:
    457
    J├╝rgen Exner
    Jul 23, 2004
  2. Jeremy Phillips
    Replies:
    2
    Views:
    437
  3. Pete
    Replies:
    2
    Views:
    3,431
    Cosmin Marin
    Jun 11, 2004
  4. TTroy
    Replies:
    16
    Views:
    811
    Peter Nilsson
    Jan 31, 2005
  5. Replies:
    4
    Views:
    562
Loading...

Share This Page