[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Final comments, mostly editorial
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
> 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.