• 4. Metadata
  • 4.1. Publication-level
  • 4.2. Resource/fragment-level

One UC ("Discovery of Accessible eBooks") about a publisher providing metadata, the retailer exposing it, consumer searching it, etc.

Evaluation: this should be consolidated, notably to better describe the impact/interaction with the different states of the PWP (offline, packaged, unpackaged).

One UC ("Provenance of Digital Publications"), describing provenance as e.g. a scholarly paper derived from a dataset.

Evaluation: if I understand correclty, the concept of "provenance" here is not specific to PWP. However, we proably want a UC about identifying the "provenance" (canonical location) of a ported/offline PWP.

One UC ("Book semantic / StructSem UC") about structural semantics of headings (IIUC).

Evaluation: not specific to PWP; if not covered by HTML + ARIA-DPUB, then integrate to some other doc?

Latest published version:

Is this really the only instance where this note applies?
"The Interest Group recognizes that the proper definition/implementation of this requirement may lead to major technical complications and therefore may not be fulfilled." --http://w3c.github.io/dpub-pwp-ucr/#r_manifest-comb

It stands out as very unusual in the text.

• 12. DRM

Contains two use cases. Are DRM in scope?

Who defines reasonable use? Do we need a requirement that does more to describe what reasonable use means to a PWP and its publishers?

“Bridget buys (rather than subscribes to) a PWP. She expects to have permanent access to that PWP and to be able to make reasonable use of it.” -- http://w3c.github.io/dpub-pwp-ucr/#r_process

• 1. Styling and Layout
  • 1.1. Lists
  • 1.2. Pagination
  • 1.3. Adaptive Layout
    • 1.3.1. Device Adaption
    • 1.3.2. User Adaption
  • 1.4. Positionning

Markus said these should be de-prioritized. Should some related cases be added eventually or is it left out entirely to the Layout and Styling TF?

Lists

One UC ("Lists") related to hierarchical semantics and counter styling.

This level of semantics is often perceived by publishers as insufficient to distinguish hierarchical outline lists with more complex numbering schemes

I'm not sure I grasp the essence, in particular what's needed that HTML + CSS doesn't provide.

Evaluation: this is a very specific content-related UC, I don't think it needs to be integrated to PWP use cases.

Pagination

One UC ("Tables 1") related to rendering of tables in paginated rendering.

Evaluation: pagination is obviously an important UC. We may want a UC that describes pagination-related issues when displaying content, but it should not be limited to tables. The issue is vast however. If we want a UC in this document, it must be high-level on what makes the problem particular to PWP? Details of pagination reqs for the larger generic web are better off in a specific document IMO.

Adaptive layout

Only one UC ("Tables 1"), the same as the pagination one described above.

Evaluation: to which extent adaptive layout issues are specific to PWP? (I'm not sure they are). Do we need a UC here?

Positioning

One UC ("NakaTobira") related to the Naka Tobira Japanese layout design.

Evaluation: not sure if specific to PWP or better off in a pagination-specific document. See Pagination above.

• 10. Packaging and Distribution

• "Publication with Data" is about declaring remote data source in the package.
  Evaluation: to be consolidated, maybe with the following.
• "Publication with Interactive Data" is about using javascript in PWP (incl. calling remote services, package of libs embedded in package)
  Evaluation:
  • the "package in package" idea is interesting, but maybe out of scope for the first iteration?
  • the "call of remote services" idea s/b consolidated.
• "Publication plus Annotations" is about annotating a packaged PWP.
  Evaluation: see Annotation use cases.
• "Items with Shared Resources" is about PWP sharing common resources (e.g. Images, CSS, Javascript).
  Evaluation the use case is in scope but s/b clarified, notably to specify what "shared resources" mean in packaged/unpackaged, where they are located, etc.
• "Streamlined Access to Disjoint Package Components" is about providing "samples" of a PWP (e.g. abstract, toc).
  Evaluation: probably in scope, but the relation of this "sample view" of a PWP and the original PWP must be clarified (built-in? spin-off using shared resource? totally independent publication?)
• "Manifest Includes Information about New Content" is about updating an existing PWP with new content.
  Evaluation in scope, to be consolidated.
• "Overview of OCF Functionality" is not really a UC but describes some OCF-specific features.
  Evaluation some features may be integrated in use cases, if deemed in scope or important. E.g. magic numbers, encryption, signatures, obfuscation.
• "Access Control and selective encryption" is mostly about DRM.
  Evaluation are DRM in scope? see also #14.
• "Functional Requirements" is not a UC but instead lists some requirements. It will be a useful resource to see if we have good use case coverage.

We must also decide on which features are in scope, e.g.:

• streamability
• package-in-package (packages all the way down!)
• updateability
• sharing/using the same package among multiple users
• ease of packaging/unpackaging with existing tools

We also lack use cases related to the relation between the packaged/unpackaed states (transitioning between each other, link resilience, etc).

New models of economic sustainability, innovative experiences of knowledge and invigorated socio-cultural engagement depend on this.

heh, "invigorated socio-cultural engagement"... it's gets a little hyperbolic. Maybe drop this?

• 3. Identifiers

Currently empty.

Evaluation: If I understood correctly this out of scope for PWP.

Susan uses CSS, images, flexboxes, and

Flexbox is CSS... there are also no such thing as "flexboxes" AFAIK.

Does this make sense as a top-level section? Most other sections do not mention specific technical means (of course we know CSS will be involved). More importantly, I think most of the subsections belong with other headings. CSS customization is an aspect of personalization. Pagination is one of the fundamental requirements, as is navigation across document boundaries.

Should we just move the use cases here, and delete the section?

This might be a question of unclear definitions (PWP states vs PWP instances).
“This does not imply that the same PWP in different states is required to use the same identifier.”
And
“Identifiers need to be persistent across PWP instances.”
--http://w3c.github.io/dpub-pwp-ucr/#r_identifier

This issue is a first attempt to describe what we have and what's missing, to better identify the work areas.

Use cases on the wiki

• Styling and Layout: see issue #3
• Domain-Specific Content Types: see issue #4
• Identifiers: see issue #5
• Metadata: see issue #6
• Content & Markup: see issue #7
• Interaction: see issue #8
• Accessibility and Personalization: see issue #9
• Internationalization: see issue #10
• Social Reading and Annotations: see issue #11
• Packaging and Distribution: see issue #12
• Publishing Workflow Effectiveness: see issue #13
• DRM: see issue #14
• Security: see issue #16
• Pagination/DOM interaction: see issue #15

Other sources

See also:

• EPUB 3.1's Browser Friendly Format (BFF) Use Cases & Requirements
  
• CSV on the Web: UC&R. In our 11 jan 2016 meeting Markus hinted at using the doc as a good example.

Is there a reason to use the term "highlights" instead of "annotations" in the use case Why have this note instead of just calling the example in the use case an annotation? If the terms are in fact identical in meaning, we could remove the note and simplify the document (there are no other notes quite like this).

http://w3c.github.io/dpub-pwp-ucr/#r_locator-state

Having the detailed scenario (use case) titles in the ToC makes it hard to read.

In the division of essential versus non-essential, what should be considered the default if the content is not tagged one way or the other?

As an archiving service provider, I would like to be able to harvest the subset of a PWP's components that have been added or changed since the last archived version so that I can ensure archival completeness and minimize unnecessary storage costs, post-harvest processing, latency in synchronizing published and archived PWP versions, and load on the PWP host's servers.

The terms “online” and “offline” are used in this document, but the borderline between these is not always clear cut.

These are fairly well defined concepts on the Web Platform, particularly as reflected in through the fetch spec and navigator.onLine. I don't think this document should discuss online/offline, particularly as it makes things more confusing.

http://w3c.github.io/dpub-pwp-ucr/#single-package

The use cases listed are not use cases; they are additional requirements.

• 8. Internationalization
  • 8.1. Layout

The only use case is the "Naka Tobira" also discussed in #3 (Styling and Layout).

Do we need more use i18n-related cases? I'm not sure PWP brings specific use cases to the table.

Based on our conversations at Rebus, one requirement that we have which might become an issue for PWP is that, to maximise distribution and reach, we'd like our baseline reader to be browser-based.

As in, our current plans (subject to change, of course) it'd be a progressive web app. Not an app built using browser tech (that might come later if the resources allow).

This generally shouldn't be an issue except when it comes to javascript.

A web app can't allow third party javascript, not without limitations.

(All of these issues also apply to the preview of PWPs in websites that want to add their own chrome/UI to the preview.)

The options as I see them:

1. Sandboxed iframe. Has UX/UI downsides now that 'seamless' has been removed and is resource intensive (it's a whole new browsing context in a box). It's also a bit tricky to implement if you don't want to accidentally leave open security holes. It doesn't protect anything in older browsers or Opera Mini (which actually does support some JS) which means it has to be supplemented by another approach anyway, thereby increasing the cost to implement.
2. Don't allow any javascript. The easiest method to implement.
3. Sandbox the javascript using Caja. Ties you either to Google's servers or to setting up your own implementation. Very resource- and engineering-intensive.
4. Whitelist JS files that are known to be safe using URLs and integrity hashes.

(All of these limitations are in addition to the limitations that need to be put in place to prevent PWPs from being a vector for malware in general. But that's a separate issue.)

The third option, the whitelist, would strike for us the right balance between effort and reward. This would, for example, let us support Google AMP files as if they were portable publications and let the community curate/build a set of open source custom elements that can be used on both regular websites and in portable publications. Given that custom elements are almost certainly going to be big, vetting the most popular ones for security and whitelisting would net you a lot of functionality.

The use cases in http://w3c.github.io/dpub-pwp-ucr/#r_manifest-metadata mostly don't read as use cases; they seem to be additional requirements.

Referring to the platform as "OWP" is not common in the community. Maybe just say "Web Platform" instead?

"Slicendice Publishing publishes many PWPs, some of which are different versions or subsets or combinations of others. Slicendice needs not only to be able to uniquely identify each unique PWP but also to identify each "copy" or "delivery" ("item") of each of those PWPs so that it can track "what" has been sold and "how many" of each one have been sold. (See also "There should be a way to uniquely identify a publication regardless of its state")" http://w3c.github.io/dpub-pwp-ucr/#r_process

seems to contradict
"Simply distributing or sharing a PWP to multiple destinations and devices should not result in multiple versions of the PWP. Those items should not be different versions of the source PWP unless they contain modifications that make them different PWPs." -- http://w3c.github.io/dpub-pwp-ucr/#r_distro

We have to decide on the spec editing tool to use, Respec or Bikeshed.

@dauwhe seems to have a pref for Bikeshed; should we just go ahead and set it up?

http://w3c.github.io/dpub-pwp-ucr/#manifest_links

Do we need to clarify who gets to define what needs to be archived?

"An archival service wants to harvest (spider) a PWP, and expects to find in the manifest what it will need to make sure it gets all the pieces of the PWP that need to be archived, even if on separate servers."

This needs to be turned into one or more use cases:
"Educational materials are increasingly making use of OWP facilities. They include runnable program snippets, interactive testing tools (linked to online evaluation facilities); in many respect, the borderline between these publications and web applications is becoming fuzzy."

adapted from discussion with Baldur Bjarnason and his article https://www.baldurbjarnason.com/notes/some-notes-on-security/

As a systems developer, I am concerned about allowing content that will construct a PWP to pass to my customers via my website (sales portal, server, etc) if it contains scripts from multiple and/or unknown origins.

The behavior of the client in this case is identical to the situation when the publication is genuinely online, although, technically, the publication is clearly offline.

This is not true. Browsers make concessions for developers on localhost: like allowing service workers to be registered without requiring TLS; but it's meant for developers only.

So, connecting to localhost is not equivalent to connecting to a remote origin.

Do we need to consider how, when personalizing a document, a reading system will differentiate between a user-described "necessary" font versus one chosen for aesthetic purposes only?

"A font used for aesthetic purposes only in display of a book may not be essential and an implementation may decide not to embed it for offline use" http://w3c.github.io/dpub-pwp-ucr/#r_essential

There seems to be some very antiquated terminology and assumptions made about the web:

facilities

We commonly call those "features", and more recently "powerful features" (for features that require user permissions).

formidable development of visualization systems

Are you referring to the use of WebGL? It might be better to be more explicit about precisely what technology you are talking about here... otherwise it sounds, um, more "magical" than it actually is.

runnable program snippets,

You mean JavaScript?

• 7. Accessibility and Personalization
  • 7.1. WCAG 2.0 & Education Environment / Educational Publishing
    • 7.1.1. Pre-School through Middle School
  • 7.2. Specialized Subject Areas (e.g. Chemistry, Grammar, Poetry)
  • 7.3. Allowing Versions
  • 7.4. General Accessibility Use Cases (including Math)
  • 7.5. Personalization
  • 7.6. User Descriptions

Markus said these may be lower priority. Most of these may be out of scope because they're not specific to PWP? In the A11y TF note?

WCAG 2.0 & Education Environment

• "Timed Tests and Activities" is about declaring/allowing additional time on timed activities and tests.
  Evaluation: out of scope, not specific to PWP
• "Mirroring Source Materials" is about syncing an alternate accessible version with a lesser accessible source material.
  Evaluation: out of scope, not specific to PWP
• "Still View of Moving Content" is about the ability to stop/pause timed content.
  Evaluation: out of scope, not specific to PWP

There are other bullets but not associated to fully-described use cases.

Specialized Subject Areas

One not-fully-described UC about the possibility for a publisher to provide samples of a larger pub.

Evaluation: this may not be directly in scope of this document, as it's probably more linked to work on metadata and identifiers?

Allowing Versions

• "Allow Different Math Pronunciations" is about configuring different TTS (of various quality levels) depending on preference or reader level.
  Evaluation: out of scope
• "Facilitate Post Production Crowdsourcing of SVG Descriptions" is about bolt-on post-publication image description.
  Evaluation: is it any different from annotation UCs?
• UC about easily deliver a patched version of a buggy publication
  Evaluation: not specific to a11y, the general delivery issue is discussed elsewhere.
• UC about "improving the accessibility of an interactive widget"
  Evaluation: too sketchy, but probably not specific to PWP?
• UC about quickly identify the version of a PWP for tech support
  Evaluation: not specific to a11y. locator/identifier discussed elsewhere.
• UC about "needing clear identification of the source of the content they receive and to be able to allow/disallow content depending on the source"
  Evaluation: I'm not sure I grasp the essence. Out of scope?

General Accessibility Use Cases

About a dozen UCs related to a11y of content, which IMO are out of scope for this document. I suggest the A11y TF review these, and identify which one they want included.

A couple UCs that may be in scope:

• A UC about publishers and content remixers who want to keep image descriptions and alternatives in the package
  Evaluation: relevant packaging UC, but maybe nothing specific compared to other packaging UCs?
• A couple UC about a11y feature metadata for discoverability
  Evaluation: relevant metadata UC, see also the EPUB 3.1 approach
• A UC about synchronized word-level highlighting and TTS, like EPUB media overlays
  Evaluation: is "media overlays for PWP" in scope for this doc?

Personalization

• "Adjustable Fonts" is about customizing font size+family.
  Evaluation: in scope? also discussed in the Styling UCs.
• "Adjustable Line Height and Length"
  Evaluation: same as above.
• "Adjustable Text Alignment"
  Evaluation: same as above.
• "Adjustable Background and Contrast"
  Evaluation: same as above.
• "Zoom Control" is empty...
• "Rendition Control" is about multiple renditions (e.g. fixed layout + reflowable) of a publication.
  Evaluation: are multiple renditions in scope for PWP?
• "Initial Collection of Existing Efforts" describes existing efforts and is about synchronization with other initiatives.
  Evaluation: Not a UC. A11y TF to decide if/how this must be reflected in this doc.

User Descriptions

"ReadingDisorder", "Dyslexia", and "CerebralPalsy" are UC describing personas, spawning various a11y requirements.
Evaluation: the scenarios are good, but the specific relation to PWP is not clear IMO (how does it differ from the generic Web?). The a11y TF should review these and decide if/how to consolidate.

• 11. Publishing Workflow Effectiveness

Only 1 use case ("Tansclusion 01") about PWPs using shared components at runtime.

Evaluation: Is it in scope?

If this requirement is "essential" should it be moved into the Fundamentals section?
"A unique identification of a specific publication, regardless of whether it is online or offline, or whether it is part of a web site or a single (packaged) file is essential. This unique identification should be mapped onto the “real” location of the publication smoothly, without requiring the author’s interaction. " -- http://w3c.github.io/dpub-pwp-ucr/#r_uniq-id-state

This model inherited very little from an existing, powerful and much older page-based media: book

Håkon Wium Lie's PhD thesis, which underpins CSS, strongly contradicts the above - particularly from a historical perspective. There was significant influence from print media, and books in particular, in the design of the web and particularly as it relates to layout.

• 14. Pagination/DOM interaction

• "Page representation in the DOM", about providing an API to the page model.
• "Showing a specific page of content", about providing an API to display a specifc page
• "Showing more than one page of content", about rendering multiple pages simultaneously
• "Determine what page a particular element appears on", also applies to text offsets.
• "Specify how pages are referenced" is about how page progress is rendered, how pages impact bookmarks.
• "Define events to notify when a page is ready/visible"
• "Functional Requirements for Pagination"

Evaluation: are these in scope for the PWP use case doc? or better off in a dedicated document?

• 2. Domain-Specific Content Types
  • 2.1. STEM
  • 2.2. Assessments
  • 2.3. Infographics
  • 2.4. Comics/Manga

Only the first bullet contains use cases ("MathML", "Chemistry UC", "Diagrams and Graphing", "Tables_1", "Lists").
These basically say "a publisher wants to provide math/chemistry/diagram content. It must be accessible, scripatable, etc."

Evaluation: doesn't sound specific to PWP, I don't think content-specific UC are in scope for this document. If some aspects of content representation are not covered by the Web Platform, better off in a separate IG doc?

“The same content of the PWP should be accessible offline, if circumstances so dictate, without the necessity for the reader to take any particular, technical actions.” -- http://w3c.github.io/dpub-pwp-ucr/#r_onloffl
Vs.
“This way, when changing the state of a PWP from, e.g., online to offline, an implementation knows which PWP resources are essential for the display of the content, and therefore must be included in the offline version, or which may be skipped” -- http://w3c.github.io/dpub-pwp-ucr/#r_essential

This suggests the content may vary depending on whether the resource is online or offline, and later suggests that the reader may exercise control on whether or not to download and so make available components of the PWP offline (a technical action).

The wiki has no use cases on security. We must identify what is specific to PWP.

• 5. Content & Markup
  • 5.1. Structural Semantics
  • 5.2. Other

Structural semantics

4 UCs ("Index1/Behavioral UC1", "Index2/Behavioral UC2", "Index3/Behavioral UC3", "Notes1/Behavioral UC4")

Evaluation:

• structural semantics are covered by DPUB-ARIA, not specific to PWP.
• intra-publication linking requires a UC, although identification of range is probably out of scope for PWP.
• about the behavior (e.g. rendering a footnote in a popup): it can be 1. browser native, 2. provided by a RS (layer "on top" of the browser), 3. provided by JS "polyfills" in the pub. I think we need a behavioral UC here.

Another UC ("User added dictionary") about using a PWP as a dictionary.

Evaluation: probably out of scope for the first iteration of PWP?

Other

• "MediaSpecificMarkup" is about identifying markup relevant to a specific media (e.g. print pages).
  Evaluation: out of scope
• "ScrollDirection" is about declaring a preferred scrolling direction.
  Evaluation: out of scope for PWP? not sure.
• "ContinuousSound" is about having a background soundtrack.
  Evaluation: out of scope, it's a generic web thing.
• "Tables_1" is already discussed in other issues #3 and #4.
• "User directed styling modifications (font family)" is about customizing the font used by RS/UA.
  Evaluation: consolidate to describe the mecanics of browser/RS/publisher CSS?

Configurability of important resources

Chef Bob writes a cookbook with a lot of embedded videos to explain certain techniques.
Bob finds it very important that his videos remain available even offline, and configures this in his cookbook.
Reader Annie starts reading Bob's cookbook online.
When Annie gets disconnected, the fonts of the cookbook fall back to the system fonts, but the videos remain available.

Typographer Charlie writes a book on typography, and configures differently: he finds fonts a very important aspect of his book,
whilst the embedded videos may fall back to a still.
Annie can read Charlie's book without err, online or offline. The fonts remain availabe, but the videos fall back to stills when offline.

Author David does not configure anything to his novel, but still,
Annie can read David's book without problems whether she is online or not.

Cross-references

Writer Annie writes a dissertation. She references to her Master's thesis, published
on the university website.
Her college Bob already read her Master's thesis before. When he clicks the reference
in Annie's dissertation, he gets redirected to his local copy of Annie's Master's thesis.
Her friend, Charlie, hasn't read her Master's thesis before. Charlie needs to be online when clicking
the reference, to read Annie's Master's thesis.

Distribution

Publisher Corp.Inc. publishes a new PWP, and sends this PWP to ACME and many more retailers.
Retailer ACME makes this PWP book available to its customers.
This PWP is downloaded to devices, or synced across several devices, or made available to a customer-specific cloud.
Customers can access this file from different retailers, through different applications, either directly or downloaded from private cloud.
Thus, the PWP is duplicated many, many, many, many, many times, resulting in a huge number of items.
There is one source manifestation, one isbn identifier, and lots of items spread across devices and buyers.

Annie buys a book and dowloads it offline. She bookmarks a certain chapter (i.e., creates a locator for that chapter).
She sends that bookmark to Bob.
Bob is able to use that locator on any item of the same PWP, and gets redirected to the correct chapter.

Q1: Is it the packaged state that goes to the retailer?
Q2: Is it up to the retailer to maintain portability?

Offline publications

Corp.Inc. creates an internal manual for its employees as a PWP.
This PWP is not published online, but is sent around to all its employees.
Employee Anna has some questions about figure 2b, and sends an email to co-worker Bob with a locator to that figure.
Bob clicks on that locator, and his company-branded PWP reader opens Bob's personal copy of the manul, and redirects immediatly to that figure.

Updating PWP's

Corp.Inc. creates a PWP with dynamically updatable stock exchange information on chapter 4.
Anna sends the locator for chapter 4 to Bob on April 1st.
When Bob reads the PWP offline, chapter 4 is filled with some default content.
However, when Bob gets online and clicks on the locator for chapter 4, he gets the updated stock exchange information,
which might be different than the stock exchange information that Anna saw when she created the bookmark.

Minimal requirements

Anna is a self-publishing author.
Anna creates a PWP, both packed and unpacked.
Anna uses some cloud storage system such as DropBox to publish her PWP online.
Her friend Bob is able to read Anna's PWP online and offline, either packed or unpacked, as Bob sees fit.

Is this use case about privacy, or is it about smooth transitions? (Note this was heavily modified in the revised text, but the question remains.)
OLD:
Many publications—especially long form fiction and non-fiction—that users engage with for many hours. During this time, the user may shift states in many ways—starting consumption on an internet enabled PC, moving to an internet enabled portable device, going into offline-mode on that device, and then back to the PC. Ensuring a smooth transition also means that bookmarks, current reading position, etc, are stored, without the need of a central server that may lead to privacy concerns.

REVISED:
Klaas is reading an in-depth biography of Catherine the Great. As this is a lengthy document, it takes Klaas several weeks to finish reading the material. During this time, Klaas frequently alternates between reading on his portable device, which may or may not have been online, and reading on his desktop. Ensuring a smooth transition also means that bookmarks, current reading position, personal notes, and more, are stored without the need of a central server that may lead to privacy concerns.

-- http://w3c.github.io/dpub-pwp-ucr/#r_statetrans

1 Bob is reading in PWPRead-soft, and makes private annotations. These annotations can be - via Bob's PWPMark profile - synced across devices.
2 Bob makes a couple of his annotations public. Chris also has a PWPMark profile, and choses to show all public annotations whilst reading using PWPRead-plugin. Chris sees Bob's annotations whilst reading the same document.

• this could be extended to more 'fine-grained' user access, e.g., two lawyers annotating the same contract as a PWP on their own computer. These annotations are shared only in specific groups, depending on what the PWPMark software allows.

We need to create EPUB or remove link

It would be helpful if we had a clear definition of the following terms. They are sometimes (but not always) used interchangeably within the doc. If we can consolidate, and then add definitions to the terminology section to be clear, that would improve the doc.

Publication
Resource
Instance (see Identifiers)
Component (see Archiving)
Rendition
Version

state-wise, I currently assume the following:

• a PWP can be unpacked or packed
• a PWP can be online (http), offline (cache), or downloaded (file). Other variations like accessing via FTP etc. are not excluded.

1. Writer Annie has her book published on her own web space as a PWP [http/unpacked]. Reader Bob reads it online, and selects a nice quote to bookmark via its browser PWP bookmarking plugin: PWPMark-plugin.
2. Writer Annie has her book published on her own web space as a PWP [http/unpacked]. Reader Bob caches the PWP [cache/unpacked], reads it offline, and selects a nice quote to bookmark using PWPMark-plugin.
   • When Bob re-opens the offline PWP, the booksmarks are shown via PWPMark-plugin
   • When Bob re-visits the original PWP, PWPMark-plugin can also show Bob's bookmarks in the online version.
3. Writer Annie has her book published on her own web space as a PWP [http/packed]. Reader Bob opens it online using the PWP reading plugin PWPRead-plugin, and selects a nice quote to bookmark via PWPMark-plugin.
4. Writer Annie has her book published on her own web space as a PWP [http/packed]. Reader Bob caches it using a plugin [cache/packed], and selects a nice quote to bookmark via PWPMark-plugin.
5. Writer Annie has her book published on her own web space as a PWP, both packed [http/packed] as unpacked [http/unpacked]. Reader Bob reads [http/unpacked] online and selects a nice quote to bookmark via PWPMark-plugin. Then, Bob downloads [http/packed] to his local filesystem [file/packed] to open in his reading system of choice, namely, PWPRead-soft.
   • PWPRead-soft synchronizes with Bob's PWPMark profile, and can show Bob's bookmarks when he continues reading [file/packed]

• 9. Social Reading and Annotations
  • 9.1. Use Cases Targeting Full Publication
  • 9.2. Use Cases Targeting Specific Segments
  • 9.3. Advanced Use Cases
  • 9.4. Annotation Packages
  • 9.5. Annotation Publication
  • 9.6. Other Use Cases

Dozens of UCs. Are they in scope? I suppose most UC fall under the responsibility of the Web Annotation WG.

The PWP specific issues are:

• publication identifiers – which are likely out of scope
• URLs to publications or fragment therein
• portability of the annotations with the PWP
• PWP made of annotations

Depending on what is in scope for this document, we can consolidate a couple key use cases.

Educational materials are increasingly making use of OWP facilities. They include runnable program snippets, interactive testing tools (linked to online evaluation facilities); in many respect, the borderline between these publications and web applications is becoming fuzzy.

this seems really odd and has some strange underlying assumptions: if the "educational material" is already on the Web, it's already part of the Web (there is no "borderline" that this was once a different publication type).

Does this requirement:
“User agents must treat a PWP, regardless of the number of components, as a single unit as opposed to individual documents.” -- http://w3c.github.io/dpub-pwp-ucr/#r_single

contradict this requirement:
“A PWP will likely be composed of multiple web documents. A more complicated PWP may have many more components, meaning that extracting in advance all the references to other constituent resources may be prohibitive. It is therefore necessary for the reading system to have an easy access to the list of constituent resources, and some of their characteristics like their media types or sizes.” http://w3c.github.io/dpub-pwp-ucr/#r_con-res

and this one:
"In order to make serial publications lighter and speed up processing, a PWP should support the injection of external resources." -- http://w3c.github.io/dpub-pwp-ucr/#r_extreshttp://w3c.github.io/dpub-pwp-ucr/#r_extres

The interpretation seems to be "treat a PWP as a single unit, except when you don't because some might material might be optional, or be external resources."

• 6. Interaction

Contains only 2 UCs ("MathML 2", "MathML 3") about scripting MathML, inputing content, interacting with servers, also discussed in #4

Evaluation: The MathML-specific part is not PWP-specific, but describing the possibilities of scripting & communicating with a remote server is in scope IMO. To be consolidated.

Do we need more use cases here?