Clarifying the scope of this TR (informative, not algorithmic)

[murata2makoto]

I propose that we explicitly clarify the scope of this document.

This TR is intended to define what kinds of information user agents should consider when generating spoken presentation of documents containing ruby — including ruby annotations themselves, morphological analysis, and particle pronunciation — but not how such information should be processed.

Because authors use ruby in highly diverse ways, it is unlikely that any single deterministic algorithm could reliably produce appropriate text-to-speech output in all cases. Therefore, implementation details — including heuristics, rule-based systems, and AI-based analysis — should be left to implementers.

Clarifying this in the introduction or scope section would help reviewers understand that this document complements, but does not overlap with, specifications like Specification for Spoken Presentation in HTML or the unofficial Web Speech API.

[murata2makoto]

Here is my proposal for closing this issue.

1. Change the title of the first section from "Purpose" to "Scope".

2. Add "and to identify the types of information that user agents should consider when generating spoken presentation" at the end of the first paragraph.

3. Add these two paragraphs after the first.

This document does not prescribe specific implementation algorithms. Because authors use ruby in highly diverse ways, it is unlikely that any single deterministic approach can reliably produce appropriate results in all cases. Therefore, implementation details—such as the use of heuristics, rule-based systems, or AI-based analysis—are intentionally left to implementers.

The scope of this document is limited to defining which information sources should inform spoken presentation (e.g., ruby base, ruby annotation, morphological analysis, and particle pronunciation), rather than defining how this information should be processed. This approach ensures that the document complements, but does not overlap with, other specifications such as Specification for Spoken Presentation in HTML or the unofficial Web Speech API draft maintained by the WICG.

[xfq]

While it is unlikely that any single deterministic approach will reliably produce suitable results in all cases, could there be a mechanism for authors (and even users) to specify which kind of result they want (e.g., read only the base text, only the annotations, or both)?

[murata2makoto]

could there be a mechanism for authors (and even users) to specify which kind of result they want (e.g., read only the base text, only the annotations, or both)

I am very skeptical, especially because there are many existing HTML and EPUB publications.

[murata2makoto]

While I understand the motivation, I believe that defining any author- or user-controlled mechanism to select between reading base, annotation, or both would be outside the scope of this document.
The purpose of this TR is to identify what information (e.g., ruby base, annotation, morphological analysis, etc.) should inform spoken presentation, not to prescribe how user agents expose configuration or selection interfaces.
Any such control, if needed, would belong in the HTML or accessibility API specifications rather than here.

[xfq]

could there be a mechanism for authors (and even users) to specify which kind of result they want (e.g., read only the base text, only the annotations, or both)

I am very skeptical, especially because there are many existing HTML and EPUB publications.

Existing HTML and EPUB files can remain as they are, and new files can use this mechanism (if it exists).

[xfq]

While I understand the motivation, I believe that defining any author- or user-controlled mechanism to select between reading base, annotation, or both would be outside the scope of this document. The purpose of this TR is to identify what information (e.g., ruby base, annotation, morphological analysis, etc.) should inform spoken presentation, not to prescribe how user agents expose configuration or selection interfaces. Any such control, if needed, would belong in the HTML or accessibility API specifications rather than here.

I understand. I meant we need to make the requirements clear in this document. The formal definition and implementation are definitely out of the scope of this document.

[murata2makoto]

@xfq

I will create a pull request to mention the possibility of a future specification for such mechanisms.

[himorin]

2. Add "and to identify the types of information that user agents should consider when generating spoken presentation" at the end of the first paragraph.

I suppose, in addition to write clearly in Purpose (or Scope), we may be better to mention somehow in Abstract also. Of course, describing user requirement should include such kinds of identifications, but considering potential wide-range options and choices we may be better to have short text for complexity at the top...

[murata2makoto]

Thank you very much for the comments.

Today I have been working on improving the scope and drafting a new section. After spending a few hours, I now feel that putting too much detail into the scope is not the right direction. In ISO, we say “Less is more.”

I will submit a pull request that includes a revised scope and another pull request for introducing a new section enumerating the information sources for text-to-speech. My sense of balance may differ from yours, but I would appreciate your patience.

However, for points that may need to be acknowledged, I can add short statements in a new section, where appropriate, for clarification. This way we can recognize the concerns without expanding the scope itself.

Thank you for your understanding.