Remove PLS section from authoring specification

All this section describes is how to use an HTML link element to associate a lexicon, but do we need to explain that, and is the EPUB specification even the right place for it?

Lexicon files also never needed to be a core media type as they've never required a fallback (the exception on linked resources is also broader, so we don't have to say anything about the "pronunciation" rel value).

We don't have a section on how to use CSS 3 Speech, for example, so do we need to persist this section any longer? Nothing is invalidated from an authoring perspective by removing it that I can find.

If anything, the section should be a separate note as it defines behaviour that should be supported by browsers. (We really shouldn't have defined the speech features in isolation in IDPF.)

I'm fine leaving the reading system recommendation to support lexicons and the speech module for aural rendering, even if support hasn't materialized.

The issue was discussed in a meeting on 2021-06-10

List of resolutions:

Resolution No. 1: Remove PLS section from the authoring document, close issue 1690

View the transcript

1. Removing the PLS section

See github issue #1690.

Matt Garrish: basically we created this for 3.0 without W3C input, and as it turns out there hasn't been wide uptake
… if we really want this to work it shouldn't be the epub content document spec
… is it time to remove this until there is some real world implementation? possibly after taking this to W3C

Dave Cramer: so the spec text basically just describes how to use the link element, which is really an HTML thing, not an epub specific thing
… do we keep statements about these things not requiring fallbacks?

Matt Garrish: we already say link element doesn't need fallback, nothing changes by cutting this

Dave Cramer: yes, i'm also concerned about people seeing this and thinking that it does more than it really will

Matt Garrish: right, and if we really want this to work, we should take it from here and make a standard for it, or turn it into a note

Marisa DeMeglio: good in theory, but i've never seen it used in the wild

Matt Garrish: there are also other avenues to pursue to get to the same goal, parts of ARIA for example

Proposed resolution: Remove PLS section from the authoring document, close issue 1690 (Wendy Reid)

Ben Schroeter: +1

Toshiaki Koike: +1

Shinya Takami (高見真也): +1

Matt Garrish: +1

Masakazu Kitahara: +1

Wendy Reid: +1

Dave Cramer: +1

Resolution #1: Remove PLS section from the authoring document, close issue 1690

Dave Cramer: do we need to have the CG look at it? No?

Marisa DeMeglio: https://www.w3.org/TR/2021/WD-spoken-html-20210518/

Wendy Reid: if any issues come up, we can redirect to one of the WG or CG that are working on this already

Marisa DeMeglio: interesting work done with SSML in HTML

SSML is used by at least one textbook publisher, which is the biggest in Japan. I will ask if PLS is also used.

I oppose to this change, since PLS is used in Japan. The existing section describes best practices, which are useful.

If it helps in understanding why what we have is problematic purely from a standardization perspective, have a look at the reading system support instructions. In only four bullets:

they confuse the reading system as the text-to-speech engine, and are too simplistic as a definition of how to write a tts engine that supports pls
they are contradictory - pls defines how to select lexemes (first preferred otherwise first in document order) that a conforming tts engine has to follow, not last in document order regardless of preference as we define
they stray into areas the reading system can't control - precedence of lexicon/ssml will be controlled by the tts engine (this is where our ssml definition is similarly underspecified)
they don't even clearly define that you have to obtain and use the linked lexicons

We would have been better off saying only that a reading system:

must use a PLS-compliant text-to-speech engine to render xhtml content documents
must initiate the text-to-speech engine using all PLS lexicons linked to from the xhtml content document

Everything else is just a test that the engine is conforming - whether it applies the right lexeme, whether it misses some text nodes, etc.

But how likely are we to make this work now versus publishing it someplace it could get a wider audience?

Our definition for using the link element is reasonable by comparison, but we're still straying into browser territory here by defining these expectations for voicing HTML. Let's do this properly if we want to do this.

@murata2makoto

@murata2makoto

you said, in #1690 (comment):

SSML is used by at least one textbook publisher, which is the biggest in Japan. I will ask if PLS is also used.

then, shortly after (by github's account, on the same day) in #1690 (comment)

I oppose to this change, since PLS is used in Japan.

Does this mean that you have asked the aforementioned publisher whether PLS is used and the answer is 'Yes'? Would it be possible to have more understanding on how it is used? Also, does this publisher also provide a reading system that implements this feature or is there any other RS that does?

@iherman

@iherman

Indeed, there is a commercial user, which is different from the one I had in mind. I am not surprised if SSML/PLS is used in other countries. More about this later.

Also, does this publisher also provide a reading system that implements this feature or is there any other RS that does?

This is the key, and I'd be interested to hear how they made it work with our mixed-up requirements.

Also, does this publisher also provide a reading system that implements this feature or is there any other RS that does?

At least one RS does. Another one is extremely likely. I am asking them to report here.

E-Book Production Guidelines: Accessibility through Text-to-Speech published by the Japanese Ministry of Internal Affairs and Communications in 2015 recommends SSML and PLS. Another report published by the same ministry in 2016 is about a prototypical implementation. Both reports are written in Japanese, but PLS is mentioned many times.

Murata-san's point is correct.
As I posted in the tag "Remove PLS lexicon section # 1700", SSML and PLS are used in various ways in Japan. Especially digital textbooks are remarkable.

Here is an example of a site where PLS is listed. (Japanese only).
*https://www.lentrance.com/features/
*https://www.itrc.net/contents/wg/uat/2016-5.pdf
*https://www.soumu.go.jp/main_content/000354698.pdf

Just to remind, while working on pronunciation section, it would be good to keep in mind the work of APA pronunciation task force
https://www.w3.org/TR/pronunciation-explainer/

https://www.w3.org/TR/pronunciation-user-scenarios/

Their approach is extensively based on SSML. In order to make EPUB specs future proof as well as backward compatible (based on information from Japanese friends), what about having an informative section which briefly explains PLS and SSML and points to best practices?
SSML is also supported by many TTS e.g. Festival, Google cloud, MS speech service etc.

it would be good to keep in mind the work of APA pronunciation task force

I do keep saying we should take PLS support to that task force, as PLS was designed as the default vocabulary language for the SSML lexicon element but isn't connected to their specification. It's not clear you can use a lexicon with their implementation.

This issue is a lot like how we hoped epub:type would gain traction as a sort of ARIA role hybrid. Unfortunately, nothing happened on either front.

what about having an informative section which briefly explains PLS and SSML and points to best practices?

Do we want to do this within the EPUB core spec or should we look at publishing SSML+PLS+CSS3 Speech as a separate working group note on pronunciation, sort of wrapped up like an extension to EPUB? I've favoured doing that, too. At least that way it would be clear that this is still a largely experimental area.

Matt wrote:

If anything, the section should be a separate note as it defines behaviour that should be supported by browsers. (We really shouldn't have defined the speech features in isolation in IDPF.)

But how likely are we to make this work now versus publishing it someplace it could get a wider audience?

I believe that these arguments apply to Media Overlay as well. Why do we keep MO and drop PLS?

Practically, use of SSML and PLS in XHTML content documents is extremely unlikely to be accepted by WHATWG, since WHATWG cares what browser vendors implement.

Since a Japanese ministry has believed that SSML and PLS are good solutions for accessibility, dropping PLS from EPUB3 may lead to negative outcome.

@murata2makoto

@murata2makoto EPUB 3.3 will not drop PLS to use in existing EPUB files and in future ones for compatibility.

@shiestyle

@shiestyle

You mean that PLS is not "dropped" even if EPUB 3.3 does not normatively mention it. I think that dropping normative requirements on PLS is dropping PLS.

I believe that these arguments apply to Media Overlay as well. Why do we keep MO and drop PLS?

Putting aside that media overlays have support and PLS does not, so is not an issue moving through to REC, media overlays doesn't require any hacking or extending of HTML. It's uses SMIL which is already defined by W3C.

Publishing SSML+PLS+CSS3 Speech as a separate note also makes a lot of sense as it could finally tie together why we touch on these technologies in the specification.

There's no coherence for having ssml mentioned as an html extension and pls (not even a core media type) dropped in at the end of the section. Other than a reading system requirement that ssml:ph takes precedence over a lexicon entry, nothing suggests these technologies are supposed to work together, or establishes a link between pls and ssml lexicons (not even the reference to the overview, which just names the technologies). CSS 3 Speech isn't mentioned anywhere except in a single bullet that reading systems that support tts should support it (the overview omits this one entirely).

Publishing as a note doesn't change anything any more than having Multiple Renditions as a note. What it does is remove the problematic nature of getting these technologies to REC and also improves our flexibility if HTML-native solutions are developed.

@mattgarrish

@mattgarrish

I guess that SSML+PLS+CSS3 Speech as a separate note is agreeable by every stakeholder.

@mattgarrish

@mattgarrish

I guess that SSML+PLS+CSS3 Speech as a separate note is agreeable by every stakeholder.

I think this is a good consensus plan. Administratively, it may better if the WG gives an advance approval (@dauwhe @wareid @shiestyle) because that would also mean removing SSML from the spec, and not only PLS. At this moment, #1700 only removes PLS (because that is what the WG resolution contains).

I'll prep #1700 to add the new note on TTS enhancements, but agree we need a new resolution.

Navigation Menu

Repository navigation

Remove PLS section from authoring specification #1690

1. Removing the PLS section

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Remove PLS section from authoring specification #1690

Description

Activity

iherman commented on Jun 11, 2021

1. Removing the PLS section

murata2makoto commented on Jun 11, 2021

murata2makoto commented on Jun 12, 2021

mattgarrish commented on Jun 13, 2021

iherman commented on Jun 14, 2021

murata2makoto commented on Jun 14, 2021

mattgarrish commented on Jun 14, 2021

murata2makoto commented on Jun 14, 2021

murata2makoto commented on Jun 14, 2021

okayama247 commented on Jun 15, 2021

avneeshsingh commented on Jun 15, 2021

mattgarrish commented on Jun 15, 2021

murata2makoto commented on Jun 16, 2021

shiestyle commented on Jun 16, 2021

murata2makoto commented on Jun 16, 2021

mattgarrish commented on Jun 16, 2021

mattgarrish commented on Jun 16, 2021

murata2makoto commented on Jun 16, 2021

iherman commented on Jun 17, 2021

mattgarrish commented on Jun 17, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions