Major Concern about multi-data- approach to SSML encoding

[paulgrudnitski]

It's exciting to see this specification reach this stage. Congratulations to the many contributors.

One aspect of this multiple vs. single attribute debate that I have not seen discussed is "performance" - as in run-time performance - when implementing either approach. After having implemented this draft specification (the single-attribute approach) one thing that I can state for certain is that sniffing/selecting for up to 29 different data-ssml-* attributes on every html element/tag in the DOM is going to be 20+ times worse than sniffing/selecting 1 data-ssml attribute and unpacking that json to tease out the ssml information via a json processor.

From experience, when a TTS player has to rip through the DOM in real time, scanning each element for all of data-ssml-* attributes that the TTS player supports (up to 29!?) before sending the information off to the device's (or player's) speech synthesis API ... well that's going to be a brutal experience full of unwanted pauses unless you are running on some amazing equipment which doesn't exist in the K-12 space where I've done my implementation.

Just my $0.02 cents: don't let style win over substance.

[AutoSponge]

Thank you for the comment. It's still being reviewed by the TF. We will pay attention to performance as implementations are presented.