This page is part of the web mail archives of SRFI 107 from before July 7th, 2015. The new archives for SRFI 107 contain all messages, not just those from before July 7th, 2015.
Still mulling how to handle "]]>".
I'm inclined to think you're right, but I don't see any benefit in adding a restriction to prohibit "SRFI 109 constructs" in attribute values - it would seem to make the rules and syntax more complicated, just to reduce flexibility, without any obvious benefit.I'm primarily concerned that, when translated into actual XML, it won't have the effects that people think it will have.
I don't understand what you mean by "when translated into actual XML". If an xml-constructor containing "]]>" in element content is evaluated it would (assuming some DOM-like implementation) create a text node containing "]]>". Which is perfectly valid. If this is the "serialized" (e.g. written out to an XML file) then it is the job of the serializer to replace "]]>" by "]]>". Note the syntax is intended for not only XML content, but also HTML and related syntaxes. "]]>" is not strictly valid, but it is "in practice valid" - browsers (at least Chrome and Firefox) don't complain. Furthermore, it appears to be valid HTML5, according to my reading of the spec and the validators I've tried. I did implement an experimental warning in Kawa: #|kawa:1|# #<p>Weird: ]]>!</p> /dev/stdin:1:12: warning - literal ']]>' is only valid following '<![CDATA[' <p>Weird: ]]>!</p> #|kawa:2|# Note the ">" is serialized as ">" in the Print part of the REPL.Perhaps a warning is a reasonable compromise. In the SRFI, perhaps we could add:
The XML and HTML standards (up through HTML 4.x) do not allow the literal text
"]]> in element content - instead it should be escaped as in "]]>". This is for historical reasons of SGML-compatibility. An implementation SHOULD warn if literal "]]>" is seen. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/