i18n related thoughts

[r12a]

I am not sure i18n, from the charter point of view, is a real problem,
because the work rely on HTML+CSS that do the heavy lifting.

I don't share that confidence. Any time i hear someone say that i18n probably isn't a problem it sets off alarm bells, because it usually is if you don't incorporate it into your requirements and plans. What about book bindings and page directions for Arabic/Hebrew, etc? Is that covered? What about the items highlighted as lacking implementation or specification in CSS (esp. for paged media) in the recent member submission about Japanese feature support in CSS and ePub? Don't forget to include language and text direction metadata at all appropriate levels.

Would you consider the xLREQ document series as input for requirements? Perhaps the technology work here is too far removed from the content level? Hard for me to tell from the charter.

Some additional suggestions:

[1]

We believe there is great value in combining this older tradition—of portable, bounded publications—with the pervasive accessibility, addressability, and interconnectedness of the Open Web Platform.

->

"We believe there is great value in combining this older tradition—of portable, bounded publications—with the pervasive accessibility, internationalization, addressability, and interconnectedness of the Open Web Platform."

[2]

Invitation for review must be issued during each major standards-track document transition, including FPWD and CR, and should be issued when major changes occur in a specification.

->

"Invitation for review must be issued during each major standards-track document transition, including FPWD and at least 3 months before CR, and should be issued when major changes occur in a specification. "

That's a very important change!

[3]
It takes the whole of the Goals section to get to some text that explains what the group intends to do, involving a certain amount of eye-glazing and frustration. For me, this is an approach more tied to the reading of novels and such. I'd prefer to see a succinct first sentence in that section that says "The goal of the Publishing Working Group to produce X", to get right to the point but also give me a framework in which to read the following text that builds to the end of the section.

[4]

This group primarily conducts its technical work: on the public mailing list public-dpub-wg@w3.org (archive) and on GitHub issues.

fwiw, in my material i tend to reverse the order of github and email these days, since github brings so many benefits to the table for technical discussions

[5]

Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general WCAG and WAI requirements of the W3C;

->

Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general WCAG and WAI requirements of the W3C as well as requirements for international readers using different scripts and document formats;

hope that helps a little

[iherman]

I am not sure i18n, from the charter point of view, is a real problem,
because the work rely on HTML+CSS that do the heavy lifting.

I don't share that confidence. Any time i hear someone say that i18n probably isn't a problem it sets off alarm bells, because it usually is if you don't incorporate it into your requirements and plans. What about book bindings and page directions for Arabic/Hebrew, etc? Is that covered? What about the items highlighted as lacking implementation or specification in CSS (esp. for paged media) in the recent member submission about Japanese feature support in CSS and ePub? Don't forget to include language and text direction metadata at all appropriate levels.

Would you consider the xLREQ document series as input for requirements? Perhaps the technology work here is too far removed from the content level? Hard for me to tell from the charter.

As you say, the work here is removed from the content level. A Web Publication is a collection of Web Resources; the work indeeds concentrates on the collection (what it means, how it is organized, etc.) and does not intend to standardize anything on the content. These are left to existing standards, like HTML, SVG or others. What do you think should be added in the charter?

That being said, some of your suggestions below do refer to be ready for any unexpected issue popping up which, I believe, are very much part of a charter. Thanks for those, and see my comments below.

(Note that 'added' at this point means that it will be added to a separate Pull Request.)

Some additional suggestions:

[1]

We believe there is great value in combining this older tradition—of portable, bounded publications—with the pervasive accessibility, addressability, and interconnectedness of the Open Web Platform.

->

"We believe there is great value in combining this older tradition—of portable, bounded publications—with the pervasive accessibility, internationalization, addressability, and interconnectedness of the Open Web Platform."

Agreed. Added.

[2]

Invitation for review must be issued during each major standards-track document transition, including FPWD and CR, and should be issued when major changes occur in a specification.

->

"Invitation for review must be issued during each major standards-track document transition, including FPWD and at least 3 months before CR, and should be issued when major changes occur in a specification. "

That's a very important change!

Agreed. Added.

[3]
It takes the whole of the Goals section to get to some text that explains what the group intends to do, involving a certain amount of eye-glazing and frustration. For me, this is an approach more tied to the reading of novels and such. I'd prefer to see a succinct first sentence in that section that says "The goal of the Publishing Working Group to produce X", to get right to the point but also give me a framework in which to read the following text that builds to the end of the section.

Two comments on this:

• There are two open issues (Confusing terminology: "publication", "web publication" #24 and Offline reading is not a property of a document #25), and corresponding assignments in the PBG, to review that part and propose editorial changes.
• As also discussed in issue Mission statement still boilerplate text #35, the "mission" part is still a TBD.

If you do not mind, I would prefer to close this issue (if all other things are settled) and come back to the overall style once those issues are handled.

[4]

This group primarily conducts its technical work: on the public mailing list public-dpub-wg@w3.org (archive) and on GitHub issues.

fwiw, in my material i tend to reverse the order of github and email these days, since github brings so many benefits to the table for technical discussions

I would leave that to the group; I would keep to the charter template for now.

[5]

Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general WCAG and WAI requirements of the W3C;

->

Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general WCAG and WAI requirements of the W3C as well as requirements for international readers using different scripts and document formats;

Agreed. Added.

[r12a]

If you do not mind, I would prefer to close this issue (if all other things are settled) and come back to the overall style once those issues are handled.

Ok.

Thanks for the changes you made.

[murata2makoto]

Package documents in EPUB 3/3.0.1/3.1 have mechanisms for page layout. For example. rendition:layout="flow-scrolled-continuous" in a package document specifies the intended behavior of reading systems. The scroll direction is an I18N issue. Neither CSS nor HTML will cover this mechanism. See "4.3 Package Rendering Metadata" for all rendering metadata in package documents.

I thus believe that it is not a good idea to rely on CSS and HTML for all I18N issues.

[iherman]

@murata0204,

The charter draft currently contains the following statement

Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes [...] requirements for international readers using different scripts and document formats. Additional extended requirements will be identified as conformance requirements in the Working Group’s normative specifications.

(I have cut out the similar references to accessibility.)

What this essentially means: although we do have a strong relations to CSS and I18N (as listed in the liaison section) there may issues coming up during the work that needs additional work in this WG. If that happens, we will have to deal with it.

I do not think that we can say anything more in the charter. It sets the expectations and we will have to set up, during the practical setup of the group, a way of looking out for these types of issues.

I believe this is also a (partial) answer to your question in #42.

[murata2makoto]

I rather think that we are obliged to find a way to represent all backhanded layout properties of EPUB3 in an OWP. The statement you referenced is too general, but we have specific, real problems right now.

[iherman]

@murata0204 I do not think we disagree on the fact that there are some EPUB features that we will have to, somehow, represent EPUB 3 features in PWP, or a profile thereof. The issue at hand right now how much details we want to put into the charter beyond what is there

Let me also refer to the additional statement related to EPUB4 vs. EPUB3:

This specification defines a functional profile of the general idea of Packaged Web Publications that may deliver a higher degree of comprehensive accessibility capabilities and reliability. This specification should generally be a functional superset of EPUB 3.1, with functionally round-tripping to/from EPUB 3.1 considered highly desirable.

[iherman]

The conversation goes into (valuable) details that are more relevant for the WG than for the charter. I would prefer to (re-)close this issue.