SSML is heavily used by some publishers in Japan. Dropping them from EPUB 3 is unacceptable.

SSML is heavily used by some publishers in Japan. Dropping them from EPUB 3 is unacceptable.

@murata2makoto, you completely misunderstood what I said, probably I was not clear enough. It is by no means proposing to drop SSML from EPUB3.

§5.1.3.6 talks about custom attributes in XHTML content. The relevant text is:

Custom attributes MAY be included on any element in an XHTML Content Document provided such attributes are from a foreign namespace, which is defined as a namespace [XML-NAMES] that does not map to either of the following URIs:

• http://www.w3.org/1999/xhtml
• http://www.idpf.org/2007/ops

My reading is that the aim is to protect some privileged namespaces. As SSML can be spread over all over the content document, my proposal is to protect the SSML namespace, i.e., adding https://www.w3.org/2001/10/synthesis to that list.

@iherman

Sorry for my confusion. I agree to list the SSML namespace in this list.

The ops namespace is there because we wanted to ensure control over anything "epub" (i.e., avoid a reading system adding an attribute that looks like it comes from a spec). The xhtml namespace purpose kind of eludes me, as HTML attributes aren't in any namespace.

We kind of violated the rules of good behaviour by minting SSML attributes in the first place (I don't know that that was coordinated in any way). And given that the world is moving on from this idea, I don't know how important it is to worry about.

We could always throw a blanket restriction over "http(s)://www.w3.org/" and call it a day?

We could always throw a blanket restriction over "http(s)://www.w3.org/" and call it a day?

and the idpf.org namespaces? Maybe a blanket over w3.org and idpf.org is fine. Essentially, external bodies should not mess with these namespaces...

Works for me!