Per Bothner scripsit:

> My reading of the XML specification is this is for the sake of SGML
> compatibility, which no-one cares about any more ...

It was introduced into the XML spec for the sake of SGML compatibility,
yes, not merely a recommendation for those who actually need
compatibility But it is in itself a hardwired rule of XML.

> Note SRFI-107 is not a specification of XML documents or XML parsers.
> It is an *XML-like* syntax for embedding in S-expressions.  As such,
> why should an "SRFI-107 processor" enforce an arbitrary constraint
> that ">" must be escaped when following "]]" when not in a CDATA
> section?  That's just a pointless extra rule.

Well, at the moment, any SRFI 107 xml-literal that doesn't contain
an enclosed-expression or a SRFI 109 construct (support for which is
optional) is well-formed XML, *except* if it contains the sequence "]]>"
in character content.  That's a pointless exception.

MicroXML, which is very close to xml-literals except for not allowing
namespaces, uses the rule that *every* ">" in character content must be
escaped.  I'd be happy if xml-literals adopted that rule.

By the way, I don't think SRFI 109 constructs really make sense in
attribute values.  In XML, all newline characters in attribute values
are replaced by the parser with spaces anyway (though this is not true
in MicroXML), and most XML applications blow away leading and trailing
spaces and reduce runs of spaces to a single space.

--
John Cowan <xxxxxx@ccil.org>             http://www.ccil.org/~cowan
Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash
    him with a Cshell!  Vi didn't I mount it on a troff?" --Francis Turner