Email list hosting service & mailing list manager

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)

Re: Final comments, mostly editorial Per Bothner 28 Nov 2013 04:45 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/