Per Bothner scripsit (reordered):

> Still mulling how to handle "]]>".
>
> 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.

Strengthen this to "MUST warn" and I can live with it, though I would
still prefer to make it an error.

> >>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

I wasn't addressing "]]>" at this point, but SRFI 109.  On reflection,
however, the line continuation, indentation, and comment features only
remove things rather than adding them, and so are fairly harmless.
I continue to be opposed to special syntax for formats, because I am
opposed to formats altogether, but since they are optional I don't
really care.

> Note the ">" is serialized as ">" in the Print part of the REPL.

Be sure to serialize explicit newlines as "
" (or the equivalent)
in attribute values, too.

--
Take two turkeys, one goose, four               John Cowan
cabbages, but no duck, and mix them             http://www.ccil.org/~cowan
together. After one taste, you'll duck          xxxxxx@ccil.org
soup the rest of your life.
        --Groucho