[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Final comments, mostly editorial



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: ]]&gt;!</p>
#|kawa:2|#

Note the ">" is serialized as "&gt;" 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 "]]&gt;".
This is for historical reasons of SGML-compatibility.
An implementation SHOULD warn if literal "]]>" is seen.
--
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/