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 (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 cowan@xxxxxxxx
soup the rest of your life.
--Groucho