https://xerces.apache.org/xerces2-j/: Xerces2 is the next generation of high performance, fully compliant XML parsers in the Apache Xerces family. This new version of Xerces introduces the Xerces Native Interface (XNI), a complete framework for building parser components and configurations that is extremely modular and easy to program. The Apache Xerces2 parser is the reference implementation of XNI but other parser components, configurations, and parsers can be written using the Xerces Native Interface. For complete design and implementation documents, refer to the XNI Manual. Xerces2 is a fully conforming XML Schema 1.0 processor. A partial experimental implementation of the XML Schema 1.1 Structures and Datatypes Working Drafts (December 2009) and an experimental implementation of the XML Schema Definition Language (XSD): Component Designators (SCD) Candidate Recommendation (January 2010) are provided for evaluation. For more information, refer to the XML Schema page. Xerces2 also provides a complete implementation of the Document Object Model Level 3 Core and Load/Save W3C Recommendations and provides a complete implementation of the XML Inclusions (XInclude) W3C Recommendation. It also provides support for OASIS XML Catalogs v1.1. Xerces2 is able to parse documents written according to the XML 1.1 Recommendation, except that it does not yet provide an option to enable normalization checking as described in section 2.13 of this specification. It also handles namespaces according to the XML Namespaces 1.1 Recommendation, and will correctly serialize XML 1.1 documents if the DOM level 3 load/save APIs are in use. 
/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 * 
 *      http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.xerces.dom;

import org.w3c.dom.CDATASection;
import org.w3c.dom.Node;


XML provides the CDATA markup to allow a region of text in which
most of the XML delimiter recognition does not take place. This is
intended to ease the task of quoting XML fragments and other
programmatic information in a document's text without needing to
escape these special characters. It's primarily a convenience feature
for those who are hand-editing XML.


CDATASection is an Extended DOM feature, and is not used in HTML 
contexts.


Within the DOM, CDATASections are treated essentially as Text
blocks. Their distinct type is retained in order to allow us to
properly recreate the XML syntax when we write them out.


Reminder: CDATA IS NOT A COMPLETELY GENERAL SOLUTION; it can't
quote its own end-of-block marking. If you need to write out a
CDATA that contains the ]]> sequence, it's your responsibility to
split that string over two successive CDATAs at that time.


CDATA does not participate in Element.normalize() processing.

@xerces.internal
Version:$Id: CDATASectionImpl.java 447266 2006-09-18 05:57:49Z mrglavas $
Since: PR-DOM-Level-1-19980818.
/**
 * XML provides the CDATA markup to allow a region of text in which
 * most of the XML delimiter recognition does not take place. This is
 * intended to ease the task of quoting XML fragments and other
 * programmatic information in a document's text without needing to
 * escape these special characters. It's primarily a convenience feature
 * for those who are hand-editing XML.
 * <P>
 * CDATASection is an Extended DOM feature, and is not used in HTML 
 * contexts.
 * <P>
 * Within the DOM, CDATASections are treated essentially as Text
 * blocks. Their distinct type is retained in order to allow us to
 * properly recreate the XML syntax when we write them out.
 * <P>
 * Reminder: CDATA IS NOT A COMPLETELY GENERAL SOLUTION; it can't
 * quote its own end-of-block marking. If you need to write out a
 * CDATA that contains the ]]> sequence, it's your responsibility to
 * split that string over two successive CDATAs at that time.
 * <P>
 * CDATA does not participate in Element.normalize() processing.
 *
 * @xerces.internal

 *
 * @version $Id: CDATASectionImpl.java 447266 2006-09-18 05:57:49Z mrglavas $
 * @since  PR-DOM-Level-1-19980818.
 */
public class CDATASectionImpl 
    extends TextImpl 
    implements CDATASection {

    //
    // Constants
    //

    
Serialization version. 
/** Serialization version. */
    static final long serialVersionUID = 2372071297878177780L;

    //
    // Constructors
    //

    
Factory constructor for creating a CDATA section. 
/** Factory constructor for creating a CDATA section. */
    public CDATASectionImpl(CoreDocumentImpl ownerDoc, String data) {
        super(ownerDoc, data);
    }  
    
    //
    // Node methods
    //

    
A short integer indicating what type of node this is. The named
constants for this value are defined in the org.w3c.dom.Node interface.

/** 
     * A short integer indicating what type of node this is. The named
     * constants for this value are defined in the org.w3c.dom.Node interface.
     */
    public short getNodeType() {
        return Node.CDATA_SECTION_NODE;
    }
  
    
Returns the node name. 
/** Returns the node name. */
    public String getNodeName() {
        return "#cdata-section";
    }

} // class CDATASectionImpl