I find the Goals and Scope sections to be very hard to follow, in part because of the attempt to co-opt very common terms for the very specialized immediate purpose.

I see "publication" used in four different ways, none of which match the ordinary language meaning of the word. Similarly "web publication" is a common phrase and it seems to have little to do with what you're talking about.

Ordinary-language "publication" does not imply either "page-based" or "bounded", and ordinary-language "web publication" does not imply packaged or bundled with metadata.

I suggest you simply follow the practice that is common in most technical specifications. Coin a phrase that has not been previously used, so that it has no current connotations or associations. Then, imbue it with whatever meaning you like. Make an acronym if the phrase is too long.

For example, you could come up with an adjectival pharse A that is true of the artifacts you want to design but not true of ebooks in general, and then call these things A-ebooks, abbreviated AEB. (You can always change the name later on in the process; this is just a charter.)

A less attractive choice, used by FRBR with some success, is to choose a common word (like "expression") but to use it in contexts so far removed from its natural habitat that there is little chance of confusion. "Publication" and "web publication" definitely do not satisfy this condition, however.

Trying to redefine "publication" and "web publication" is fighting the tide, and provincial. It is bound to hurt your cause, not help it.

At the moment these point at the editors' draft; it is better to refer to a stable documents, ie, the /TR versions

The scope section for the most part says that the project is merely to define a new document type (in the sense of MIME type), although I suppose it does not commit to that. This is a much more straightforward and conventional idea than the rhetoric found in the goals section seems to say, so I think both sections should be rewritten to make this clear. However, one requirement makes no sense in this interpretation:

"A Web Publication must be available and functional while the user is offline. A user should, as much as possible, have a seamless experience of interacting with a Web Publication regardless of their network connection. We make no distinction between online and offline when defining Web Publications."

There is absolutely nothing a publication, document, or "Web Publication" can do to make itself available and functional. The "must" has to apply to agents such as readers and distribution networks. The wording is a kind of passive voice, or agentless construction, that is likely to be confusing both to readers of the charter and to WG members down the road. I recommend rewriting this requirement (and perhaps the entire section) to make it clear what sorts of things are going to be constrained by the proposed specification: documents of the new type, readers, generators, distribution networks, etc.

In other words: any specification specifies that a something X should (must) have property P. (And if the specification is to be actionable, P has to be testable somehow.) Be very clear on what X is.

The scope of proposed WG charter focuses solely on Web Publications and is based on "Web Publications" supporting documents (use cases & requirements and vision). It is anticipated that the new W3C Publishing Business Group will take on the responsibility for being a conduit between publishing industry and other W3C WGs that is presently part of the scope of the Digital Publishing Interest Group. Therefore it might be cleaner to name the new WG the "Web Publications Working Group". This might help make it more clear to prospective participants what is being worked on in the WG, as well as help make the new WG more attractive to participants who don't necessarily come from traditional publishing industry or think of themselves in working in "digital publishing" per se since that term has come to mean, for some, eBooks.

Or perhaps there is a better name. I am just raising the issue that we shouldn't just presume the name is optimal but think it through.

The charter is incorrect to say that

the “Web Publications Use Cases and Requirements” document, published by the Digital Publishing Interest Group, lists a number of use cases and requirements that are not yet covered by the current environments based on the Open Web Platform.

For example:

1. https://www.w3.org/TR/pwp-ucr/#unique-identifier is provided by URLs.
2. https://www.w3.org/TR/pwp-ucr/#onloffl is now provided by service workers.
3. https://www.w3.org/TR/pwp-ucr/#reading-order is provided by .
4. https://www.w3.org/TR/pwp-ucr/#escalating_trust is provided by permission requests.
5. etc.

I'd be unhappy if the scope included re-inventing these bits of the web just because they appear in the requirements document. Would it be possible to put the full list of unsolved requirements in the scope document, and be clear that the "Use Cases and Requirements" doc is just informative?

Issue raised on behalf of Chris Lilley (@svgeesus) on the mailing list

I strongly suggest changing to the W3C Software and Document license. This is the same as the document license (for the actual document text) and the same as the software license for examples, code snippets etc which is important as the Document License forbids copying or modifying examples. And we want people to be able to do that.

Where it says "have already been documented elsewhere, the most" the hyperlink under "documented elsewhere" has a typo in it

At the March 13 meeting of the Publishing BG, I agreed to review the WG charter and suggest editorial changes. That's what this note covers.

Amend the first sentence to read "The mission of the Publishing Working Group is to provide the technical specifications that will make publications first-class entities on the Web." [this is drawn from subsequent document text]

In the section on meeting schedule, upper-case 'W' to start the sentence ('We')

Section 1 Goals
first para, last sentence, add a hyphen: 'page-based media'
second para, first sentence, and 'and': 'manga, notebooks, and albums...'
fourth para, first sentence, add a hyphen: 'should become first-class entities ...'

Section 2 Scope
first para, first sentence, lower-case a: 'For the purpose of this document, a web publication...'
first para, second sentence: delete the dash and add a period, so that it reads: 'A Web Publication is not just a collection of links. The act of publishing involves ...'
first para, current third sentence, add a comma after 'Thus' and delete the one after WP: 'Thus, the publisher provides an origin for the WP and a URL...'
first para, last sentence, add a hyphen to 'high-level' and delete the semi-colon after 'characteristics'

first bulleted item, add 'it may': 'A Web Publication may be portable, and it may be hosted ...'
second bulleted item, break up the second sentence to read: 'The package must include the unique identifier of the manifestation. A Web Publication's origin is essential information if it is to become portable.
fourth bulleted item, second sentence: 'Users should, as much as possible...'
sixth bulleted item, add a hyphen: 'a range of meta-information including...'
sixth bulleted item, first sub-bullet: 'table of contents'
sixth bulleted item, third sub-bullet: 'metadata such as author(s), title, and unique identification.'

Section 2.1 Input Documents
Bulleted item that starts with "EPUB 3.1". Change the first sentence to read 'The Member Submission of EPUB 3 will be an important input into Web Publications, ...'

Question: Subsequent section 3.1 mentions 'EPUB 3 Structural Semantics Vocabulary' as a resource. Should it be added to this section with a more detailed explanation?

Section 2.2 Out of Scope
First bulleted item: '(however, the Working Group should not make any design decisions that ...'

Section 2.3 Success Criteria
Third para, change first sentence to read: 'Each specification should contain a section describing: known impacts on accessibility for users with disabilities; ways the specification features address those impacts; and recommendations for minimizing accessibility problems in implementation.'

Section 3.1 Deliverables
Section on EPUB 4, change last sentence to read: 'This specification should generally be a functional superset of EPUB 3.1. Functionally round-tripping to/from EPUB 3.1 is considered highly desirable.'

Section on DPUB-ARIA Module 2.0, first sentence, add a hyphen: '... coverage of publication-related terms.'

Section 3.2 Other Deliverables
Last sentence, add a hyphen: 'inclusion of publication-specific features'

Section 3.3 Milestones
First bulleted item: Date not included; amend to just June 2017.
Subsequent bulleted items: Suggest explaining the acronyms used (FPWD, CR, REC), as the charter will be circulated to the publishing community, some of whom will not know the terms (I am one of those people).

Section 4 Coordination
First paragraph, spell out 'Technical Architecture Group' at the initial mention. Suggest doing the same with FPWD and CR, if not explained in section 3.3

Section 4.1 W3C Groups
Web Platform Working Group, first bullet, amend to read: 'Web App Manifests may be the basis for specifying (table of contents, metadata, etc.) provided by a Web Publication.'
Web Platform Working Group, second bullet, amend to read: 'Service Workers may become the fundamental building block for the implementation and testing of Web Applications.'
Web Platform Working Group, third bullet, amend to read: 'Packaging on the Web (jointly developed with the TAG) may provide a way of packaging for the purpose of Packaged Web Publications.'

CSS Working Group, change last sentence to read: 'The group will designate liaisons to work with the CSS WG on issues as needed. Liaisons will ideally be part of both groups.'

EPUB 3 Community Group, change first sentence to read: 'While working on EPUB 3-related projects, the EPUB 3 Community Group may surface technical concerns, requirements, and issues that are also relevant to the work of the Publishing Working Group.'

Publishing Business Group, second sentence, make 'requirements' plural.

Section 4.2 External Organizations
For the Book Industry Study Group, change the description to read: 'This group currently maintains the EPUB 3 Support Grid, which provides information n reading-system support for EPUB 3. This tool may be extended to track support for WP in general and EPUB 4 in particular.

Section 5 Participation
No changes proposed.

Section 6 Communication
First para, second sentence, add language: '...on a public repository, and the drafts may permit direct public contribution requests.'
Third para, change to read: 'Most Publishing Working Group teleconferences will focus on discussion of particular specifications. The calls will be conducted on a weekly basis.'
Fourth para, delete the colon after 'technical work'

Section 7 Decision Policy
First para, second sentence, add a period after 'other reviewers.' Delete 'and' and Capitalize 'Consensus'
Second para, change the end to read '... may call for a group vote, recording a decision along with any objections.'
Third para, add 'obtained': '... the resolution will be considered to have obtained consensus as a resolution of the Working Group.'
Fifth para, add a period after 'Votes)': (Section 3.4 Votes). It includes no voting procedures beyond ...'

Remaining sections (8, 9 and 10)
No changes proposed.

(Just a reminder issue) a proper reference to the BFF work of the IDPF EPUB WG is still missing.

Cc: @dauwhe

The charter template has been changed, and there is now a required reference to testing. This should be updated

Since per-copy unique identifiers would raise privacy concerns, please clarify the use of "uniquely identifiable".

It would be best to link to EPUB 3 Umbrella spec at http://www.idpf.org/epub/31/spec/epub-spec.html instead of overview. This document links to all specs in the 3.1 family, including Accessibility 1.0.

Just noting: we will have to get an internal horizontal review of the charter within the staff before going to the AC.

https://w3c.github.io/dpubwg-charter/#scope says,

A Web Publication may be portable, and it may be hosted at some other origin. However, it must preserve information about its original origin and identity, so that references to a portable copy can be reconciled with the original publication, and so that the other origin can make informed choices about how much trust to grant to the publication.

If a publication is hosted at another origin, and you want trust decisions to be based on the original origin, we'd need a proof that the publication actually came from the original origin, which is non-trivial. We're trying to solve this as part of https://github.com/dimich-g/webpackage, and hopefully you'll just be able to take advantage of that, but if you want to include it in this scope too, you should also explicitly call out that you'll need to work with the Web Application Security WG or maybe the Web Security IG to make sure it's right.

Otherwise, might be straightforward to just treat copied publications as new content in their new origin with an attribution that isn't trusted by the UA.

The organization which will maintain EPUBCheck has still not be defined. It may be either the Readium Foundation or EDRLab. I hope that this will be soon defined, but maybe not before the end of March.

I therefore propose the following rephrasing:
"EDRLab, acting as the European headquarter of the Readium Foundation, is actively working on the ReadiumJS, Readium SDK and Readium-2 projects. The latter is especially interesting as a future reference implementation of PWP and EPUB 4."

The liaison to AG WG is unclear to me, it's a lot of words that don't really translate into a coherent meaning that I can parse. I'm not quite sure what you're aiming at, but based on previous conversations I suggest something like "Address digital publishing use cases in accessibility guidelines, and develop techniques to implement accessibility features in e-books." (Or whatever the current politically correct synonym is for "e-books", I seem to keep mis-remembering which one is in vogue and don't mean to use the wrong term there.)

(Filing this on behalf of Judy Brewer)

I note this phrase: "This includes general WCAG and WAI requirements of the W3C" and suggest that given the subject matter you might want to replace it with: "This includes W3C WCAG 2.0 or later, and ATAG 2.0 requirements."

...about other input that may be incorporated. It's not just about merging in the EPUB doc and that's it

The mission statement ("The mission of the Publishing Working Group is to [do something cool and specific on the Web]." currently has a boilerplate text.

Should that stand for a link to a separate document or is it just a placeholder for text to be written?

Section 1 Goals nicely describes the intended convergence of traditional (electronic) publishing and the Web. Should this introduction thus be a kind of abstract of Section 1?

https://w3c.github.io/dpubwg-charter/#timeline has:

• WP and PWP:
  • First Public Working Draft (FPWD): Q4 2017.
  • …
• PWP:
  • First Public Working Draft (FPWD): Q4 2017.
  • …

It should probably only list PWP once.

In Web Application Security, "origin" is a defined term with specific meaning for security boundaries (the same-origin policy, see https://tools.ietf.org/html/rfc6454

If that's not the sense meant here in the scope section, could you use a different term?

Issue raised on behalf of Chris Lilley (@svgeesus) on the mailing list

The current text "A number of features described in the Web Publication UCR document (e.g., personalization) may require new CSS functionalities " is true, but says nothing about coordination. Is the expectation that new capabilities are developed in the DPubWG? Developed jointly? Developed by providing UC&R and asking CSS WG to develop them? Something else?
Also, could DPubWG help CSS WG in the development and testing of existing and new capabilities that are needed by Digital Publishing.

A couple of small fixes to polish this:

2. Scope
   2nd bullet, 3rd sentence: "... if it is to become/-s-/ portable."
   6th bullet: "... to a range /+of+/ meta-information ..."

3. Deliverables, EPUB 4: "... to/from EPUB 3.1 /+is+/ considered ..."

2.3 Success Criteria,
4. Coordination,
6. Communication,
7. Decision Policy
Several Process Document links in these sections are to an out-of-date dated version; please change them to use the Latest operative version URI.

Title says it all.

It has been observed that the draft charter focuses on the motivation for Web Publicaitons and doesn't explicitly motivate why we need an EPUB 4 now (with "now" being understood in the context of the expected timeline of developing W3C Recommendations to mean "within the next several years"). This motivation should be added along with, perhaps, suitable fuzziness about whether there are going to be three things specified (Web Publications, Portable Web Publications that are packaged, and EPUB4 that is also packaged but has a more specific and EPUB3-compatible profile) or just 2 things (Web Publications and a packaged instantiation we call EPUB 4) or maybe only 1 thing (Web Publications) - TBD after the WG kicks off.

Re-reading this draft top-to-bottom with (marginally) fresh eyes, it occurs to me that new readers may not realize the full import of the words in 1. Goals ".. to provide the necessary technologies on the Open Web Platform to ...".

Specifically, as clarified later in section 4, this Working Group must work with other W3C Working Groups to collectively provide the necessary technologies; i.e. this WG augments already-chartered work on the Open Web Platform.

I suggest augmenting the first sentence in the second paragraph of Goals to read "... to provide, in concert with other W3C Groups as outlined in Section 4.1, the necessary technologies to ..."

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 [email protected] (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

Under the EPUB 3 CG section there are two instances of "EPUB&3".

The current statement is (an incorrect) definition of a WP rather than a description of what the specification is trying to accomplish.

The proposed charter for a Digital Publishing WG references a number of input documents, one of which is the EPUB 3.1 member submission. One of the six documents in this submission is EPUB Open Container Format (OCF) 3.1, which contains a section on Digital Rights Management (DRM).

While the W3C has another area of work, Encrypted Media Extensions (EME), that covers DRM, the DRM proposed here has substantially broader implications since it is a DRM that covers the core Web technologies (HTML, CSS, Javascript, etc.). It is different from EME because:

1. Video DRM was already a major use case for plugins (Silverlight and Flash), and the lack of video DRM in the Web platform was an obstacle to the retirement of the NPAPI and ActiveX plugin APIs, which has historically been a bigger obstacle to the portability of the Web across devices, and the security and stability of the Web for its users, than EME has.

2. Video decoding is quite isolated from the implementation of other Web technologies, and even without DRM is often done in a separate external component; application of DRM to core Web technologies could affect entire browser engines.

DRM should be out of scope in this charter, so that the W3C does not standardize DRM that applies to its own core Web technologies.

It would provide more clarity if the references to some of the more recent specs included very short summaries of what aspects of the specs are relevant.

Web App Manifests could easily be confused with the now-deprecated Cache Manifests and perhaps this should be called out.

Service Workers are still not widely understood as a vehicle for creating offline apps, so it's worth saying this.

this is based on some older text - let's get it up to date

Without prejudice concerning whether DRM should be in scope, the draft currently puts it in scope, lightly, with the comment "the Working Group shouldn’t make any design decision that would make such features impossible" (belying the section's title).

If there is language like that for DRM, then there should also be parallel language regarding legal use of content, such as reproduction of public domain or open access works, and exercise of fair use and related rights. That is, something like: "the Working Group shouldn’t make any design decision that would make legal reproduction or exercise of fair use rights impossible".

This is more of an administrative step: I have accepted pull request #47 to allow others to comment on a version of the charter that is as final as possible. There was one minor issue on that text, reproduced in this comment.

(This is just a reminder) As agreed on the IG call of 2017-03-20 latinreq will also be listed as a possible WG Note published by this WG.

Cc: @dauwhe

In 3.2, the third bullet reads:

Primers or Best Practice documents to support web developers when designing applications.

Isn't it possible that we'll develop the same for content authoring? Accessibility best practices being one area we might consider as we coordinate for inclusion in AG, for example.

In any case, it might be helpful to be more flexible here with wording like: "Primers or Best Practice documents to support content authors and application developers."

I am strongly objecting against section 3.1 of the proposed Charter that reads:

EPUB4: This specification defines a profile of Packaged Web Publications that delivers a higher degree of comprehensive accessibility capabilities and reliability. This specification should be as close as possible to a strict functional superset of EPUB 3.1, with incompatibilities minimized.

This is a way of locking innovation/disruption and pushes the future WG on a path that is not even discussed with its future membership. Furthermore, EPUB 3.1 and its proprietary XML formats is not Web-compatible and one of the main goals of this WG is to bridge the gap between Web and Ebooks.

https://w3c.github.io/dpubwg-charter/#scope has:

A Web Publication may be portable, and it may be hosted at some other origin. However, it must preserve information about its original origin and identity, so that references to a portable copy can be reconciled with the original publication, and so that the other origin can make informed choices about how much trust to grant to the publication.

What does it mean for the "other origin" to make choices about how much trust to grant? I suspect you meant that the browser or user loading content from origin 2 needs to be able to make informed choices about whether to trust the content as if it came from origin 1.

In 4.1 W3C Groups
The Web Content Accessibility Guidelines Working Group NAME has been changed by the W3C to the Accessibility Guidelines Working Group.

Fix typo (shold to should):
"That Working Group is responsible for the development of WCAG; the Digital Publishing Working Group shold work together with that Working Group to ensure the inclusion of publication specific features. "

This sentence trails both the EPUB 3 CG and Publishing Business Group sections, but its meaning is opaque:

The two groups will set up a strong cooperation pattern to ensure ...

I'd suggest either being more specific about what is meant, or simplify the wording so it doesn't sound so weasely (e.g., "The two groups will formally cooperate to ensure").

Remove or rewrite "Compatibility with EPUB 3 will be a consideration in development of all three specifications"

This whole section should be discussed on whether we would go down that path at all.

Let's determine what to do and either remove it (my preference) or not.

I just stumbled over "EPUB&3.1" which is used twice in Section 3.1, EPUB 4. Is this a typo that should correctly be written as "EPUB 3.1" or does it have a special meaning I don't know yet?

As per #6 , we should the latest text