3 ms·
You are allowed to chain CDATA-tags: ]]]]><![CDATA[> > CDATA sections may occur anywhere character data may occur; (http://www.w3.org/TR/REC-xml/#sec-cdata-se
by TimWolla 12y ago
You are allowed to chain CDATA-tags: ]]]]><![CDATA[>
> CDATA sections may occur anywhere character data may occur;
(http://www.w3.org/TR/REC-xml/#sec-cdata-sect http://www.w3.org/TR/REC-xml/#sec-cdata-sect)
- TheLoneWolfling 12y agoIs it just me who sees this as a very bad idea?
- dietrichepp 12y agoIt's really handy for some use cases. For example, if you are writing documentation involving XML, you might put your example XML in CDATA sections. The way CDATA works is also far simpler than XML's predecessor, SGML. I'd say it's a good feature. It sucks that there are some shoddy libraries out there, but oh well.
- deleted 12y ago[deleted]
- TheLoneWolfling 12y agoI mean chaining CDATA tags as a way to escape CDATA tags as a bad idea. It'll break anything that doesn't expect it - in particular I can see anything that does round-trips from/to XML breaking.
- jerf 12y agoEverything already must expect it. Nothing in XML prevents "some text content <![CDATA[blah blah]]> other text content" from appearing in a text node. There is no obligation that CDATA must be the only thing in a text node. IIRC, many parsers will already return multiple nodes for text if you put an entity in the middle ("text & text" coming back as three nodes), so you're already really and truly broken (i.e., not just "theoretically" broken) if you can't handle consecutive text-like nodes and merge them in some manner. This is especially true since you can entity-encode anything at all, so you already must be able to handle "hello world" properly anyhow or you've got a straight-up bug.