Final comments, mostly editorial
John Cowan
(27 Nov 2013 23:59 UTC)
|
Re: Final comments, mostly editorial
Per Bothner
(28 Nov 2013 03:52 UTC)
|
Re: Final comments, mostly editorial
John Cowan
(28 Nov 2013 04:07 UTC)
|
Re: Final comments, mostly editorial
John Cowan
(28 Nov 2013 04:10 UTC)
|
Re: Final comments, mostly editorial Per Bothner (28 Nov 2013 04:46 UTC)
|
Re: Final comments, mostly editorial
John Cowan
(28 Nov 2013 04:51 UTC)
|
Re: Final comments, mostly editorial
Per Bothner
(07 Dec 2013 01:24 UTC)
|
Re: Final comments, mostly editorial
John Cowan
(07 Dec 2013 19:24 UTC)
|
Re: Final comments, mostly editorial
Per Bothner
(08 Dec 2013 08:37 UTC)
|
Re: Final comments, mostly editorial
John Cowan
(08 Dec 2013 17:13 UTC)
|
Re: Final comments, mostly editorial
Per Bothner
(08 Dec 2013 20:27 UTC)
|
Re: Final comments, mostly editorial
John Cowan
(08 Dec 2013 23:23 UTC)
|
On 11/27/2013 08:07 PM, John Cowan wrote: > 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 *or* if it contains a name-less end-tag. > That's a pointless exception. I think the name-less end-tag is a bigger 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. Right now SRFI-107's syntax for xml-constructor is a superset of the corresponding syntax for XML. That would no longer be true if we required ">" to be always quoted. > 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. 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. -- --Per Bothner xxxxxx@bothner.com http://per.bothner.com/