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.
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 <cowan@xxxxxxxx> 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