Scala Programming Language
  1. Scala Programming Language
  2. SI-3368

Preserve CDATA sections, don't convert them to generic Text nodes.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: XML Support
    • Labels:
    • Environment:

      xml cdata escape escaping

      Description

      Sort of defeats part of the purpose of using a CDATA...

      scala> <hi><![CDATA[This & That]]></hi>
      res0: scala.xml.Elem = <hi>This &amp; That</hi>
      

        Activity

        Hide
        Dmitry Grigoriev added a comment -

        The task is incorrectly formulated IMHO. I consulted with XML pros and here's the situation.

        1. XML 1.0 http://www.w3.org/TR/REC-xml/#sec-cdata-sect says: "Within a CDATA section, only the CDEnd string is recognized as markup, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using "<" and "&". CDATA sections cannot nest."

        2. DOM Level 3 Core http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#DOMConfiguration defines DOMConfiguration parameter "cdata-sections" which determines whether CDATA must be converted to text nodes on serialization or not. There's also an entry in DOM FAQ for how this conversion must be done: http://www.w3.org/DOM/faq.html#CDTA-text

        Currently Scala converts CDATA nodes to Text nodes (cdata-sections=false). The behaviour I (and David Pollak for 3 years advocate for is to see CDATA sections serialized unchanged (cdata-sections=true), because:

        1. CDATA sections are necessary to embed Javascript code into XHTML pages;

        2. One already can define text nodes in XML literals;

        3. Generally, Scala should check XML literal wellformedness, but NOT perform any conversions. Same problem is tracked by ticket SI-1118 (<br/> vs <br></br>). Latest comments there show that guys came to preserving element emptiness mode as specified in XML literal, and that's great.

        So I suggest ticket should be renamed to "Preserve CDATA sections".

        Show
        Dmitry Grigoriev added a comment - The task is incorrectly formulated IMHO. I consulted with XML pros and here's the situation. 1. XML 1.0 http://www.w3.org/TR/REC-xml/#sec-cdata-sect says: "Within a CDATA section, only the CDEnd string is recognized as markup, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using "<" and "&". CDATA sections cannot nest." 2. DOM Level 3 Core http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#DOMConfiguration defines DOMConfiguration parameter "cdata-sections" which determines whether CDATA must be converted to text nodes on serialization or not. There's also an entry in DOM FAQ for how this conversion must be done: http://www.w3.org/DOM/faq.html#CDTA-text Currently Scala converts CDATA nodes to Text nodes (cdata-sections=false). The behaviour I (and David Pollak for 3 years advocate for is to see CDATA sections serialized unchanged (cdata-sections=true), because: 1. CDATA sections are necessary to embed Javascript code into XHTML pages; 2. One already can define text nodes in XML literals; 3. Generally, Scala should check XML literal wellformedness, but NOT perform any conversions. Same problem is tracked by ticket SI-1118 (<br/> vs <br></br>). Latest comments there show that guys came to preserving element emptiness mode as specified in XML literal, and that's great. So I suggest ticket should be renamed to "Preserve CDATA sections".
        Hide
        Alex Cruise added a comment -

        Good suggestion on the title, thanks.

        Show
        Alex Cruise added a comment - Good suggestion on the title, thanks.
        Hide
        Sebastian Nozzi added a comment -

        Is there a workaround to this?

        Show
        Sebastian Nozzi added a comment - Is there a workaround to this?
        Hide
        Christian Zahl added a comment -

        Is there any hope that this issue will ever been solved? In our application we need this in order to transfer data as an interface between two applications. As this is not working as intended (i.e. unparsed data xfer) we cannot make use of it.

        We see two alternatives:

        • encoding everything in base64
        • using a custom printer
        Show
        Christian Zahl added a comment - Is there any hope that this issue will ever been solved? In our application we need this in order to transfer data as an interface between two applications. As this is not working as intended (i.e. unparsed data xfer) we cannot make use of it. We see two alternatives: encoding everything in base64 using a custom printer
        Hide
        Alex Cruise added a comment -

        The separation of scala-xml into a separate project bodes well for making this kind of change more quickly, but unfortunately I think this particular one will require a change in the compiler XML API.

        Show
        Alex Cruise added a comment - The separation of scala-xml into a separate project bodes well for making this kind of change more quickly, but unfortunately I think this particular one will require a change in the compiler XML API.

          People

          • Assignee:
            Unassigned
            Reporter:
            Alex Cruise
            TracCC:
            Johannes Rudolph
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Development