Changed the RS section on i18n

[iherman]

This comes from the discussion around testing the i18n features, see w3c/epub-tests#150. Based on that discussion thread, the PR removes the normative statements regarding the handling of the dir and lang attributes in XHTML and SVG; listing these as normative statements is superfluous and makes it unclear what and how should be formally tested. The proposed section includes normative statements on EPUB specific files and features only

See:

• For EPUB 3.3 Reading Systems:
  • Preview
  • Diff

[mattgarrish]

I think we're still too underspecified. It's not clear what it means to process the values.

IMO, it'd be helpful to expand the processing requirement(s) more like:

To determine the language or direction of an element, a reading system MUST find the nearest specification of an xml:lang or dir attribute, starting from the element and working back through its ancestors. When a language or direction attribute is not specified, no information is available for the element (i.e., language and direction are not inferred from other sources).
Reading systems SHOULD expose the direction and language of an element when rendering its content (e.g., to improve text-to-speech playback in a bookshelf).

[OriIdan]

I would say: To determine the language or direction of an element, a reading system MUST use the last specification of an xml:lang or dir before the current element. This in my opinion is easier to implement and actually does the same thing.. When you say "Reading systems SHOULD expose the direction and language..." I think it is not clear enough how it should be exposed?

…

-- Ori Idan CEO Helicon Books http://www.heliconbooks.com

On Thu, Jun 9, 2022 at 2:39 PM Matt Garrish ***@***.***> wrote: I think we're still too underspecified. It's not clear what it means to process the values. IMO, it'd be helpful to expand the processing requirement(s) more like: To determine the language or direction of an element, a reading system MUST find the nearest specification of an xml:lang or dir attribute, starting from the element and working back through its ancestors. When a language or direction attribute is not specified, no information is available for the element (i.e., language and direction are not inferred from other sources). Reading systems SHOULD expose the direction and language of an element when rendering its content (e.g., to improve text-to-speech playback in a bookshelf). — Reply to this email directly, view it on GitHub <#2330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB43QEEZY66DRJSHAAYXWTVOHJVPANCNFSM5YJKQLHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mattgarrish]

before the current element.

What is "before" in xml processing, though? Does that mean you can get it from a sibling element before the current one?

The HTML spec has similar wording:

To determine the language of a node, user agents must look at the nearest ancestor element (including the element itself if the node is an element) ...

I think it is not clear enough how it should be exposed?

That's why it can only be a "should". I don't expect we can definitively say how to expose the information, or that it can be in all cases, but if the use allows for the information to be retained then it should be.

[iherman]

I think we're still too underspecified. It's not clear what it means to process the values.

IMO, it'd be helpful to expand the processing requirement(s) more like:

To determine the language or direction of an element, a reading system MUST find the nearest specification of an xml:lang or dir attribute, starting from the element and working back through its ancestors. When a language or direction attribute is not specified, no information is available for the element (i.e., language and direction are not inferred from other sources).
Reading systems SHOULD expose the direction and language of an element when rendering its content (e.g., to improve text-to-speech playback in a bookshelf).

We are only talking about xml:lang and not lang: the latter is defined in XHTML, and we do not define it in EPUB. As for xml:lang, that is defined in §2.12; I do not think we should redefine it on our own, we can just refer to the xml spec. (We can, of course, informally describe what is happening, but we should not look as if we defined it normatively ourselves.)

This isn't true for the dir attribute of the package document, of course. Maybe we can refer back to xml:lang with some wording whereby we say that the processing approach is similar...

[mattgarrish]

As for xml:lang, that is defined in §2.12; I do not think we should redefine it on our own, we can just refer to the xml spec.

Sure, I was just trying to express it in a single way for both. But this is what also makes the current wording ambiguous. If the XML spec defines the processing we want, then what other processing is the MUST requiring?

[iherman]

Sure, I was just trying to express it in a single way for both. But this is what also makes the current wording ambiguous. If the XML spec defines the processing we want, then what other processing is the MUST requiring?

You are right. xml:lang falls under the same category as XHTML in this respect. (We do say that processing the package document must follow the XML rules, right?). I missed that one.

In other words, the only one that we define is the dir attribute for the package document. All others have been defined elsewhere...

(I have to run to handle some private stuff for the rest of the day, if you want to edit the text directly...)

[iherman]

@mattgarrish I have re-edited the paragraph, removing xml:lang from the normative part. I have also added a short text on exactly how the processing for dir goes; I have simply taken over a sentence from the XML spec .

[iherman]

The issue was discussed in a meeting on 2022-06-17

List of resolutions:

• Resolution No. 3: Merge PR 2330, review remainder of specification for similar issues.

View the transcript

4. Changed the RS section on i18n.

See github pull request epub-specs#2330.

Ivan Herman: this is a general problem. In the RS spec, we have a general statement of the sort 'RS MUST treat HTML or CSS etc. as conforming to those other specs'.
… and we decided that all our testing concentrates on those things that epub spec adds.
… but there are some statements in i18n section (e.g. xml-lang, dir) where we are creating tests for features specified in HTML.
… the PR changes i18n section so that only the additional features are subject to normative statements.
… similarly, there is another issue. Daniel, who is now running our tests on Thorium, says that we should not put the acid test in the test suite since it will fail all the time.
… there we make a general statement that RS should implement CSS, but then later we say that RS MUST implement CSS in such and such a way.
… these latter normative statements are really superseded by other specs.
… I would propose to allow merging this PR about the changes to i18n now, and then review the rest of the spec to see how pervasive this sort of issue is in other sections.

Proposed resolution: Merge PR 2330, review remainder of specification for similar issues. (Wendy Reid)

Dave Cramer: +1.

Wendy Reid: +1.

Toshiaki Koike: +1.

Matt Garrish: +1.

Charles LaPierre: +1.

Matthew Chan: +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Zheng Xu (徐征): +1.

Ivan Herman: +1.

Resolution #3: Merge PR 2330, review remainder of specification for similar issues.

Ivan Herman: if we find additional similar things, then we should come up with a PR with all those changes. e.g. Including the one about the acid test.