If it is just "syntax sugar" and Parsers can replace it with Text... why does DOM defines an own Node type for it (wouldn't Text be enough)?
It would be enough, and probably should have been. Note that DOM implementations are allowed but *not required* to produce CDATA nodes. It is completely conformant for a DOM builder to only create Text nodes. The only reason CDATA is called out as a separate type in DOM is so that CDATAness can be preserved when a document is parsed and then reserialized. This is useful if the result of the serialization will be edited by humans in text editors, the primary raison d'etre for CDATA sections in the first place. However, the CDATAness should have no impact when considering the DOM tree itself.
Yes, the design of DOM could have been better here without a separate CDATA interface, but this is hardly the only flaw in DOM's design. DOM shoudl in no way be considered normative for what is and is not significant in XML documents. The much better thought out XML infoset does not consider CDATA sections in any way different from text nodes.
.
If a Parser works according to the XML Specs it produces CDATA nodes and a serializer shall be able to reproduce the XML document with CDATA.
This statement is demonstrably false. You have misunderstood the specs.
It is a quite different thing how applications use CDATA, there may be different ways to use it. And it is the applications decisions how it is used. Sure, there are good designs and not so good designs but as long as they are in the scope of the specs every usage is valid.
Using CDATA sections as semantically meaningful will cause your systems to break sooner or later, probably sooner. They will limit your choice of tools. It's wrong. Don't do it.
--
Elliotte Rusty Harold [EMAIL PROTECTED] Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
