0

Suppose I have some SSML:

<speak>
  <p>Now I will read some numbers.</p>
  <p>
    <say-as interpret-as="digits">369148034</say-as>,
  <p>
</speak>

When I send this as the text of a voice message with AWS PinpointSMSVoice (via the AWS JS SDK), the message fails with "Bad Request". However, if I combine everything to one line and convert double quotes to single quotes, AWS accepts it and it works.

In reading more about SSML in general, I see the following warning:

Don't forget to use double quotes around attribute values. Standards for well-formed, valid XML require attribute values to be enclosed in double quotation marks.

My hunch is that there is a bug in the AWS JS SDK which is preventing the proper encoding of a multiline string with double quotes. I don't think it's escaping properly, but I don't know for sure.

The question is... is this just a quirk of AWS? Or in practice, should SSML use single quotes for attributes? Or, double quotes?

Brad
  • 159,648
  • 54
  • 349
  • 530
  • *"if I combine everything to one line and convert double quotes to single quotes"* ...you have to do both of these things? – Michael - sqlbot Jul 23 '20 at 13:30
  • @Michael-sqlbot Yep! If I do just one, I get a request error. Interestingly enough, if I put this regular SSML with new lines and double quotes into the tester on the AWS Console, it works. That's partially why I think the issue is with the SDK. The SDK documentation does mention the newline problem, but it doesn't say anything about double quotes. However, their example uses single quotes. I've never used SSML before, so I'm just trying to fully understand what's happening. – Brad Jul 23 '20 at 15:37
  • Will you show the actual code from a minimalistic verifiable example of something broken vs. working? Needs to be code somebody else can run to duplicate the error and success conditions. – Michael - sqlbot Jul 23 '20 at 21:41

1 Answers1

0

The answer from Google is it depends on your implementation. "you may need to escape quotation marks" or if they are encoding it xml allows " . They also say "You should also avoid XML control characters like '<', '>', '&', quotes, and quotation marks in the text to be converted to audio" in other words potentially invalid XML.

TL;DR;

It depends.

lloyd
  • 1,683
  • 2
  • 19
  • 23
  • Those two paragraphs seem to be addressing different things. The first is agreeing that the AWS JS SDK is broken, in that it isn't escaping this data automatically. The second paragraph is addressing ambiguity between characters in text, where the user may forget to escape reserved entities. That's my take on it anyway. – Brad Jul 23 '20 at 08:18