indented-xml-string: simplify handling of Apple-restricted chars

[LiberalArtist]

Instead of an ad-hoc scheme of pre-escaping and un-escaping,
convert string x-expressions containing these characters into
(lists of) equivalent x-expressions using the Racket representations
of the entity and character references Apple mandates,
and let the XML library take care of the rest.

[LiberalArtist]

I started on some contract enhancements, too, but I need to think more thoroughly about what you said on the mailing list re CDATA. Again, I'm super excited you've made this library! I thought I was going to have to write one.

[otherjoel]

Thanks! It might be a bit before I can properly process this; any delay is due to my schedule, not lack of interest.

[otherjoel]

A slightly different test:

> (define test-xpr
    `(feed (author (name "Punch & Judy"))
           (title [[type "text"]] "Punch & Judy's <friend> © ℗ \"George\" Escapes!")
           (notes (div "Here & < > are escaped, but ' \" © ℗ ™ are not"))))

> (display (indented-xml-string test-xpr))
<feed>
  <author>
    <name>Punch &amp; Judy</name>
  </author>
  <title type="text">Punch &amp; Judy&apos;s &lt;friend&gt; &#169; &#8471; &quot;George&quot; Escapes!</title>
  <notes>
    <div>Here &amp; &lt; &gt; are escaped, but ' " © ℗ ™ are not</div>
  </notes>

This should be correct, in a normal world. I’m 90% sure this will be fine. But I don’t know if Apple cares that the result uses the decimal entity instead of the hex one.

In digging around a little more I found this, which seems to suggest that Unicode characters are actually fine and that Apple’s real issue is with named entities not being valid XML (see the part just before the example feed). If that’s the case then perhaps I’ve misread the Apple guidelines and the whole strategy is wrong; rather than replacing Unicode characters we should be scanning for any named entities and throwing exceptions.

Probably what I need to do is produce and submit a mock podcast to Apple Podcasts.

[otherjoel]

Upon reflection I will just merge this, since, regardless of Apple foibles we will need a way to properly escape for the entities that are defined by the XML spec (' and ") and this is a much better way of handling that.

Then I can reorganize to get cleaner contract boundaries, and then look at validating strings/x-expressions to ensure they will produce valid feeds after escaping. Part of that will mean ensuring there are no non-XML named entities present. (Or just translating them, similar to this gist)

[otherjoel]

Thanks!