Re: Final comments, mostly editorial John Cowan 07 Dec 2013 19:24 UTC

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   
together. After one taste, you'll duck
soup the rest of your life.