DPUB IG Virtual F2F meeting

<tzviya> paged view: http://w3c.github.io/dpub-pwp-ucr/
<tzviya> GitHub Repo: https://github.com/w3c/dpub-pwp-ucr
<ivan> Scratchpad: https://docs.google.com/document/d/1qbyE5AncXKb77fufax8cXjtZsFmpEjI_C_-nAuym6bA/edit#heading=h.b11s5c58fxp9

(chatter about repos and google docs)

tzviya: focusing on section 2 of the use cases
... we've tried to build some model use cases
... some are based on the web annotations use cases
... we hope to have a final version of the use cases for TPAC
... and there's the usual summer slowness
... feel free to add use cases on your own!
... let's go to the google doc
... let's start with 2.1.1.
... (reads from use case)

Avneesh: how should we structure it?
... from tech POV or user POV?
... we do the user POV, and then the technical issue

tzviya: we're using the structure that web annotations used
... putting the requirement before the use case
... because we feel the annotations use cases are very readable, in our opinion
... we have a requirement and then examples

Avneesh: tech requirements first, then user POV?

tzviya: yes
... we're focusing on section 2, which is why PWP needs to exist

<HeatherF> It might be clearer to see the structure in the actual HTML than the Google doc: http://w3c.github.io/dpub-pwp-ucr/

tzviya: anything else that is missing from section two?
... some say everything you can do in books can already be done in browsers?

ivan: section two as it stands is incomplete
... there are a number of requirements that I added to the list
... that I think are fundamental
... but I did not find the time to fill it
... like 2.1.6
... this is something publishers would need as it's part of their business model
... but needs to be described
... 2.1.8 needs to be filled in
... 2.2.3 and 2.2.4, we should fill those in
... to complete those would be a good start
... do we need any more of these fundamental things?
... how do we convince someone who works for a browser and things everything is already perfect

NickRuffilo: does this answer why we need PWP?
... there's a duality here
... publishers need things to get to the web
... and there are things that need a package
... mathml can exist inside or outside package
... should we separate these things?

ivan: I would prefer to have all the requirements listed
... once we have essential requirements, we can prioritize/filter
... for the time being I want a laundry list
... there are different communities now--when I re-edited section 2, I made subsections
... some are for readers, some are implementation requirements
... maybe it's worth separating later
... let's complete the list, and only then think about reconfiguring

tzviya: we should focus on the uniquely portable, or the uniquely publishing-centric
... let's focus on the ones that Ivan highlighted
... 2.1.6

<HeatherF> There's that scary "package" word!

tzviya: (reads title)
... this is related to distribution, archiving... it's the business model of publishing. Any suggestions for wording?

<tzviya> https://docs.google.com/document/d/1qbyE5AncXKb77fufax8cXjtZsFmpEjI_C_-nAuym6bA/edit?usp=sharing

HeatherF: the word "package" causes some people to focus on file formats... is there another word?

tzviya: maybe

ivan: I think you're right... everyone would think of zip, or non-zip
... "...the publication as a unit"

dauwhe: is this word so toxic that we need to expend effort to avoid it?

NickRuffilo: can we use the word archive?

tzviya: archive has its own meaning

ivan: it has its own use cases
... we need to talk about the single unit
... what does it mean to be a single unit?

NickRuffilo: are we defining the technical solution?

ivan: we shouldn't think about the tech solution. What do we mean when we say a publication is a single unit?

tzviya: a pwp, no matter how many pieces it consists of ,must be distributable as a single unit so that readers can purchase/share/consume/acquire
... then we talk about libraries, stores...

ivan: the current business model of publishers relies on the ability to sell or distribute a single unit over various channels

tzviya: we have the consumer and reader perspectives, now we need a publisher perspective

<bigbluehat> fwiw, Web Packaging used the word "Parts" for the "single unit" text https://www.w3.org/TR/web-packaging/#parts

(the topic which cannot be named was briefly named)

tzviya: do we want to mention archiving in this section?
... we already have a section on archiving

<tzviya> https://docs.google.com/document/d/1qbyE5AncXKb77fufax8cXjtZsFmpEjI_C_-nAuym6bA/edit?usp=sharing

luc: (asking for link to google doc)

ivan: I am wondering...
... if I'm a user and I want to copy a publication from one place to another to back it up or give it to somebody
... it is usually easier to do that if it's a single file rather than 200 files in a directory

tzviya: that's true
... that's a simple use case

george: is that similar to saying a user wants to create their own private collection or library?

tzviya: can you clarify?

george: in print world, people fill their houses with bookshelves, now you just need a USB drive
... they collect and purchase books they want access to, and it's not always available on the web
... they want access always

dauwhe: I'd add that they want to keep the book if the publisher/distributer goes out of business

tzviya: users want to cultivate private collections

ivan: which is available regardless of online/offline status

NickRuffilo: this might not be relevant
... what if content is taken down?

ivan: this is why you need archiving
... this is an archival use cases

<tzviya> see http://w3c.github.io/dpub-pwp-ucr/#use-cases---archival-interest

tzviya: going back to 2.1.6

laudrain: could we mention that the user wants ownership of the product?
... everlasting ownership

tzviya: I would prefer not to get into sales models
... it's more a business issue than a technical issue

<bigbluehat> "ever lasting ownership" is likely done through archival also...or really awesome offline features :)

tzviya: if we start talking about who owns a publication, then nobody wants to touch this stuff
... going back to 2.1.6, if people want to review this
... have we left anything out?

clapierre: what about customizable PWPs?

tzviya: is that related to the single unit use case?

clapierre: I was just thinking about physical books, bookplates, personalization

ivan: this is not related to single unit

HeatherF: we have the glint of a use case in section 10, a11y

bjdmeest: what about verifyability?
... is the publication you recieved the same as the one the publisher distributed

ivan: I could could checksum each resource in a directory, and document that

<laudrain> or completeness

ivan: so it's not dependent on having a single object
... it's probably more efficient to do as single unit

tzviya: arguments for efficieny make sense

NickRuffilo: but what do you checksum?

HeatherF: it's interesting to have checksumming as an option, but I'm not sure it should be a requirement
... we have shared references, etc.
... and we also have use cases around people actually altering documents

NickRuffilo: checksumming is usually used in application distribution

tzviya: we're getting way into the weeds

clapierre: my point was that you'd want to do it to the whole file

ivan: I did add one item to the use cases, with some conditionals

tzviya: that looks good
... anything to add to the section? perhaps time to move on to 2.1.8
... reads 2.1.8

george: in time-based media, time controls everything
... I need to be able to navigate through time-based material, based on semantics
... like headings
... I need to navigate forward and backwards in time
... hopefully in a meaningful way, like fast forward, fast backward
... you hear little snippets
... this is something daisy players do
... one requirement is ability to move quickly backward and forward in time
... also need to do flexibly, increasing speed as you move
... just like with a TIVO
... we already have text and syncronization here
... it would be good to vary the amount of text that's highlighted
... variable granularity

(missed some minuting due to Jehovah's Witnesses at the door)

Avneesh: need to navigate while offline
... so the media needs to be downloaded already
... need pause and resume
... needs to resume playback on a different device at the correct time
... the pwp should be able to provide sync media experience without need to connect online

(use case writing happening in document)

tzviya: let's flesh out these use cases
... user needs to navigate through semantically-tagged headings
... and navigating through timed text

george: the essence is that the text-based structure of the document is used in the multimedia setting
... must be able to navigate the media using the text
... an example:
... act/scene or chapter/section
... like a screenplay behind a movie, you can navigate via the screen play to get to parts of the movie

tzviya: you mentioned fast forward/fast backward

george: it's called scrubbing
... you hear the squeaking of voices as it's moving forward, comes from the time tapes were dragged quickly past the head

NickRuffilo: you could say "think playing a tape on fast forward"

ivan: are we done here?
... I'm looking at the doc from a higher level
... I was wondering whether this use case is in the right place
... [ expletive deleted ]
... we are collecting use cases/features that are fundamental to the pwp
... and the reasons why we need this work
... if we only had web pages, and that's all we needed
... then this use case could fit into this picture
... we haven't really discussed the structure of the rest of the document

tzviya: maybe we move this one to the a11y section

george: this is an audio book requirement
... whether they have text or not, should be able to live here

ivan: we have a more general use case that should be listed here
... the notion of publication we are working with must include or enable audio books or audio publications

tzviya: that's a good point

ivan: it's not in the text yet

tzviya: let's create a section about audio books

<bigbluehat> picture books?

ivan: we'll have to have a separate section
... (typed something)
... now we need a description and some use cases

tzviya: and there was vook (video book)

<HeatherF> I like the new text in 2.1.9, but what should happen now to 2.1.8? A whole new section? Move to Accessibility? Other?

Avneesh: it's a huge market

george: this is a good use case for portability
... I want to be able to hear my book

Avneesh: you download audio book via high-speed connection at home, then use in low-connection-speed environments

George: in 2.8, even though we're thinking of audio book as complete, there will be items in books where there are chunks of video or audio
... that are dispersed through the document
... you have videos or animations that are time-based that need to be supported

<HeatherF> I'm scribing in the HTML

ivan: should keep 2.1.8 where it is

Avneesh: alternate media should also been always available

Ivan adds notes to section 2.1.9

Tziya: lot of details in 2.1.8

Avneesh: A11Y can be used as a strong arguement for PWP

Tzviya: 2.1.9 seems to be complete

<bigbluehat> multi-modal reading :)

<bigbluehat> eyes-free reading?

Tzviya: time to 1 o’clock

Move to section 2.2.3

Tzviya: from a RS perspective

Tzviya duplicate from 2.2.1? no brek to duplicate : delete

<scribe> New 2.2.3

Ivan: notes on implementation optimization

Notes on essential and non essential resources

Tzviya: also on extended descriptions

Ivan: datasets for scholarly publications
... do we have the whole thing in section 2?
... shower idea : unique id for the collection, but the web doesn’t have this.

See 2.1.6

Tzviya: are there locator usecases in this doc

Heather: in distribution, offline pub, in requirements sections

Tzviya: the TF had several specific use cases. Where are they?
... anything missing?
... short break, 15 mn

<HeatherF> UCR doc on github has been updated with this morning's edits: see http://w3c.github.io/dpub-pwp-ucr/

<HeatherF> Where is the list?

<NickRuffilo> scribenick: nickruffilo

Tzviya: "Github has been updated - so we can review the actual repository. We have a use-case there about identifiers..."

<tzviya> http://w3c.github.io/dpub-pwp-ucr/#fundamental-features-of-a-pwp

<ivan> https://docs.google.com/document/d/1qbyE5AncXKb77fufax8cXjtZsFmpEjI_C_-nAuym6bA/edit#

Tzviya: "Above are links to the github and google doc which we are dicsussing the use-cases."
...: "Section 2 - fundamental features of PWP. "

heather: "Earlier dave posted a list of use-cases from epub. Since I don't understand all the things that are here, did we miss anything that are essential?"

Dave: "We talked about personalization as an accessibility issue, but it's a usability issue for everyone - changing font size for example. Browsers typically make this harder. Browsers do not have an easy way to change font, which is a universal ebook experience. It's about personal preference. There's the whole remembering where you are thing. If I've scrolled halfway down a web page, if

I open it later, I don't return to where I left off - unless someone has done a huge amount of work. It's expected in long-form reading."

Ivan: "The first one is listed later - I think I agree that this should be moved up to the fundamental features. It's in 10.1 ""
...: "The second one may not be part of the document, so it's a new item. The problem, Dave, is that no good deed goes unpunished. We have the GoogleDoc - so we should try to put both of them in so that later heather can put it into the main document. "

Dave: "I'll try to put in something about remembering where you are in the google doc."

George: "The last place to read seems to be a particular type of bookmark."

tzviya: "the bookmark seems to be added by a reader. Whereas the last-place-read is automatic and done by the browser"

GeorgE: "Do we want to talk about educational requirements - analytics - such as time spent read?"

Nick: "I think the mechanisms we have will allow someone to write the stats on top of it - but having it inherant in the document seems a bit much."

Tzviya: "If we start getting into things like analytics, we start getting into an area that is controversial. Controversy can be OK but doesn't seem necessary here."

<bigbluehat> bookmarks and reading state can be stored as annotations fwiw

Dave: "We might have to touch things from the other side - W3C sections are now required to ahve sections on security and privacy - so we may need some privacy statement somewhere. It is probably a fairly fundamental use-case for a reader - to be able to read online without someone knowing what the user is doing."

Ivan: "I'm not sure that's part of the fundamental thing, as it's part of the web in general. Tzviya, I think we are again, thinking the same thing. The next item I wrote..."
... "Where is what Dave did?"

Dave: "I'm going to try to type in my text editor - then paste in."

Tzviya: "We have a use-case of a dyslexic student who wants to customize the experience. A user who is reading in sunlight and wants to invert the colors - and a user who is reading a programming book and wants fixed-width."

Nick: "Needing night-mode is good."

Luc: "The special rendering could be prepared by the PWP producer - in that they could embed specific stylesheets or functions for different rendering strategies that could be distributed with the content. The use case would be load a specific stylesheet for specific people/use cases."

George: "Are these themes? A collection of stylesheet that adjust the presentation?"

Ivan: "I wrote that it should be either a list of options, or user defined properties."
... "An interactive dialogue."

Luc: "If the author of the PWP has created things so the syllabic colors are different - but the question becomes - how do we make the user aware."

Tzviya: "Anything else on the overview for section 2 - for the fundamental features of PWP."

Ivan: "Lets still wait for Dave's input, but we need to go through section 3."

George: "Do we have the concept of multiple renditions here?"
...: "One version that uses math as an image VS Math as MathML?"

Ivan: "We're getting into the weeds here. Eventually we'll have to face that, but... I don't know."

Tzviya: "If you look at the google doc, I pasted section 13 in. We need to go through this and see what we've already covered. "
...: "I think the first part is covered under the essential part."

Ivan: "Kill it with the delete button"

Heather: "AHAHHAHA"

Tzviya: "Differentiation between a format independent and format dependent locator."

Ivan: "These both are - on the whole - locator mechanisms. Those are the use-cases coming from them. We'll have to have a section on that, but not fundamental."

Tzviya: "I'm going to skip the ones on identifiers."
... "Possibility to follow the provenance chain for archiving."

<bigbluehat> http://pav-ontology.github.io/pav/

Nick: "So this is like a changelog - but a list of authors/creators who have touched the document and possibly some notes - stored in metadata."

Tzviya: " Locators, locators, locators for all!"
... "People would want to be able to update a publication when online or offline. Such as a publisher issuing a version - or an annotation. "

Heather: "Would this also be a publication with static or updated information?"

Tzviya: "Could be an accessibility provider adding an accessibility layer on it. "

George: "Could be that you travel to a resource that no longer exists in a newer version."

Tzviya: "I'm not sure who came up with this - but if it is just taht updating information is necessary - and it needs to go to both online and offline editions. Then that is a fundamental use-case. "

<baldurbjarnason> I can scribe

Luc: “You could for example let the reader know that a phone number for a specific restaurant has changed.”
... “Factual data could be updated dynamically.”

Tzviya: “This is a differentiation between versioning and revision. Major versus minor updates.”
... “Nick was probably alluding to the possibility that the user might not want updates. Avoiding situations like in the past where users have been forced to accept updates."

Ivan: “Can we mark up those we should put in section 2”

Tzviya: Refers to the write control requirement
... Is the write control requirement DRM?
... Is this a part of the fundamental nature of PWP?

?: PWP can’t rely on internet connection and server side programming to control read/write.

Avneesh: You log into web pages, you don’t log into your book

Tzviya: Refers to requirement on query-able manifest
... Refers to requirement on javascript and processing engines.

Ivan: we may remove this in the future.

Tzviya: References to outside resources.

Ivan: points out that this is already a part of the “has to support web platform features”

Tzviya: packaging for javascript?
... Content in package should be fully annotatable.

Ivan: We already have some references to annotation.
... A lot of these are just use cases for the first requirement (must support Open Web Platform).

<bigbluehat> they could be a resource that's contained within the PWP package, or one that you get separately as perhaps an "add-on"

Call-in User_3: This may be a part of a separate PWP product.

<bigbluehat> Alice in Wonderland + "The Annotated [Alice]"

Tzviya: This is covered by the annotation spec.
... We get annotation for free if we fully support the open web platform.

George: Big for accessibility if we want to add additional information.

Tzviya: What we actually need to say is that the package is annotatable and that annotations can be a part of the package.

George: And be discoverable.

Tzviya: There needs to be metadata on package components.

Ivan: Leave it there for now but not a fundamental thing.

Tzviya: We have covered manifest with metadata.
... Updating requirement.

Ivan: Points out that we’re in the weeds.

Tzviya: Refers to the intact and complete collection requirement.

Nobody knows who wrote that req

Heather: thinks that we have something about that already

Tzviya: Delete?

Ivan: Yes.

Tzviya: Deletes req on data that affects content
... Uncertainty on the context of the next req
... Delete?

Ivan: Also delete the long form content storage req.

Tzviya: Aggregation and disaggregation req a repeat
... Every resource in the publication has its own rights.

Dave: There’s substance to the granularity of rights.
... Need a mechanism for that so this is a valid req.

Tzviya: Is this fundamental or something we need to work on at some other point.

Dave: A law but not one of the ten commandments.

Tzviya: Refers to the treating the collection of resources as a single unit for search, etc.
... Should be a part of the single unit requirement.

Ivan: That one we covered.

Tzviya: Need to be able to search across the entire publication.

George: Should be able to apply that to series?

Dave: the reading system should be able to define the scope of your search.

George: Akin to a book search versus a bookshelf search.

Avneesh: Isn’t this an operating system function?

Tzviya: We’ll come back to this.
... Time-based media req is already covered.

Heather: Give me a moment and she’ll update the HTML document so you can see what has been moved.

Ivan and Heather discuss the logistics of updating the HTML document with the changes.

Tzviya: 10 minute break!

<HeatherF> Github updated. Use cases that we agreed were fundamental out of section 13 have been (for the moment) to section 2.2.4-2.2.9

<HeatherF> http://w3c.github.io/dpub-pwp-ucr/

<HeatherF> excuse me: 2.2.5 to 2.2.9

<HeatherF> (I think I caught them all; we'll of course sanity check when we're back to our regularly scheduled programming)

<HeatherF> And 2.2.5-2.2.9 have been copied to Google Docs

<HeatherF> those chickens are highly entertaining as background

Tzviya: Heather updated the github repo
... , Use-case 225
... , There should be the capability for dynamic updating of information based on online/offline status and time of publication. (version control/revisioning )

Dave: we can not dynamically update off-line

Tzviya: you should be able to update and it affects the online and offline

Heather: it affects the offline version once it connects online.

Dave: version control / versioning and not mention online/offline which is already a requirement.

Ivan: there is another aspect which is: versioning or re-visioning of the whole publication as a unit.
... , have versioning and revisioning as a whole not just the 5th chapter.

Luc: updating a whole publication as a new version, but the same version I thought the phrase was to update some small information.

Tzviya: updating part or all of the publication. Or 2 use cases?

Ivan: mixing up two different use cases here.

Tzviya: I agree. Updating a sentence is what Luc is referring to.

…, how is that updating for a whole chapter?

<HeatherF> If updating was a Venn diagram - if you update any part of a PWP, you've updated the PWP

<bigbluehat> should republish the main PWP "manifest"/package/thing whenever any part of it changes?

Ivan: if I change a chapter isn't that updating the whole PWP?

Tzviya: there might not be a new version if I make a change. (ie. new copyright page) the may push out a new release
... , I think

<bigbluehat> or can included resources have their own versioned/life-cycles?

Ivan: we are getting into the weeds. On the PWP level. Important: should be a way to keep the offline/online synchronized. whatever granularity and should be in sync. what changes mean, its a detail and not fundamental to PWP and just different use-cases.

Tzviya: agreed
... , do not get into distribution models.
... , reworded requirement in google doc.
... , some users may not want them to be in sync. (noted in doc)

Ivan: I put in a use case description in the doc.

Tzviya: from doc: • The publisher may have pushed a new version of a publication while Alice was accessing the offline version; when getting back on line, the offline copy of Alice’s publication should be automatically synchronized with the update.
... , more changes to this use-case in doc
... , in section 2.2.5 There should be a way to control versioning and revisioning

Ivan: we are in implementation requirements. I propose that Heather put it into the right section. this whole section is a user requirement.

Tzviya: 2.2.6 Access control and write protections
... , A PWP must allow for access control and write protections as part of the resource.

Ivan: this is dangerous waters… ie we do not want to mention DRM

George: Library is a great use case.

Tzviya: a Library will want to loan out a book for a defined period of time.
... , making edits to doc.

George: classic textbook available for the duration of the class

Baldur: you are still talking about DRM, even if you don't mention the word.

Heather: it needs to be possible.

Baldur: not sure if we even need that.
... , possibility of DRM is the interoperability of EPUB.

Tzviya: we are not having this debate today.

Ivan: we cannot deny that these use cases exist. So these requirements exist. Whether or not a WG takes this on is not our concern. To not include it would be considered ignorance.

Baldur: maybe we should just say "Should" and not a must in this case.

Ivan: added 2 use cases library and university. we should stop there.

Tzviya: ok

Ivan: 2.2.7 package pointers
... , If I look at 2.1.7 a PWP large # of web resources, and would add to doc…

George: are we calling these external?

Ivan: No they are part of the package.

Tzviya: one case is that they don't have to be in the package, but we have already mentioned this.

Ivan: these are two separate things. 2.1.7 A publication may consist of a collection of Resources

A Portable Web Publications would, usually, consists of a (possibly large) number of Web Resources, like HTML, SVG, or CSS, and it may also contain data files, or executable resources like Javascript, iPython scripts, or Java. This reflects the current practice on the Web, emphasizing the need of memory requirement on small devices, cacheability, or independent development

 We don't have to have them as separate.
... , George was just mentioning that some resources/services are remote. Maybe 2.1.1 include access to external services on the web.

Tzviya: yeah, do we need to spell that out?

Ivan: made changes to doc. 2.1.1

Tzviya: one more to write today 2.2.9 (previously)
... , collection as a unit.
... , this new use case talks more about system
... , reading system must treat (style sheets, etc..) as a single unit.

George: you are searching a single publication which contains a number of things.
... , searching a single bounded publication which contains a number of things.

Tzviya: collection of documents not just talking about searching.

Ivan: are we talking about external Search from Google or internal searching within the system.
... , but these are different.

Nick: how are they different?

Ivan: if I have a search or continuous page counting a piece of software which uses the information within that. Today Google does not search EPUB, and treats it as a single entity not the individual peices.

Dave: we want to be able to search the scope of the PWP and not have Google ads etc..

Ivan: that is true but we also want Google to find content within the document

George: this is like the HathiTrust.

Tzviya: must treat a PWP as a single unit as apposed to individual documents.
... , examples added to Doc.
... , 2.2.7 Spanning the Publication
... , User Agents must treat a PWP as a single unit as opposed to individual documents.  for: Searching, values of counters (page counters, section numbering, footnotes), and user stylesheets (users must be able to adjust display, e.g., font selection, font-size adjustment, background color)
... , we are not listing search requirements. I will ask Brady since this was his use case.
... , George you seem concerned about search req.

George: no just trying to help.

Tzviya: need help with how to discuss style sheets

Dave: if the user adjusts something that gets reflected throughout the PWP.

George: this applies to other things follows user preferences and presentation.

Tzviya: three examples CSS/Personalization and Search
... , any other examples?

Ivan: No.

Avneesh: use case with student in a university. reference from a book copy section or part of book all of the resources are copied so they have the complete reference to that section of the book.

Tzviya: user to access a portion of the PWP

George: would it be reasonable to create (ie bookmark) ie bookmark for offline study?

Avneesh: it can be used with bookmarks but a large book not just a small section.

Tzviya: there is a similar use case only to access the abstract in journals. So Section 8.1 right now you can add to that or something to look at on Monday.

Heather: next thing to discuss is document structure. Should I update github?

Tzviya: yes document structure and next steps with these use-cases.

Heather: done.

Ivan: in the new numbering 2.2.5 / 2.2.4 should go to authors and readers requirements maybe?
... , access control is not an implementation req.
... , and 2.2.4 is borderline.

Tzviya: agree
... , move 2.2.4 and 2.2.5 to section 2.1

Ivan: section 2 looks really good now!

Tzviya: rest of document. lot of sections with just 1 use-case
... , we have a lot of 1 sentense use cases.

Ivan: section 6 has only one use case.

Heather: will delete that section.

Tzviya: we need a manifest and metadata section.

Ivan: 4.2 in annotations and having something separate makes sense.

Tzviya: 4.2/3 does anyone want to take this on?

Ivan: I think they just need to be restructured with new pattern by Heather.

Heather: Yes I will restructure that.

Tzviya: on Monday we will be assigning tasks.
... , I need to discuss with Ben the section on locators.
... , section 5, I think we did 5.1 today?

Ivan: Yes 5.1 and 2

Heather: so remove them both?

Ivan: I think from the use case security stuff 6.1 is worth keeping as it is and put in relevant requirement. its about researchers etc.

Heather: I will put that back in.

Tzviya: we need section on web security.

Ivan: web and EPUB differences is EPUB is a lot more worried about security

Baldur: I might be able to write up something but not before the end of July

Tzviya: thank you, that would be wonderful. Just email me a doc or use github whatever you wish.
... , sharing external resources.

<HeatherF> github has been updated with changes to section 2, removal of security section and the use case moved to 2.1.13, removal of section 5 on creating a PWP

Tzviya: , this first one we covered 7.1
... , first we covered the 2nd someone wants to share a book and its annotations.
... , or with bookmarks. (2nd paragraph in 7.1)

Ivan: I am not sure I understand 7.1

Tzviya: I think Dave wrote this since it refers to ACME.
... , publisher distribution model.

Ivan: and I believe we don't want to define this here

George: with the updating of documents that world health organization where they publish documents and update the zika document and replace it with newer information.

Tzviya: and the first part of 7.1 where publishers use it now and we dont' want to get into this… I am not sure.

Ivan: maybe when you talk to web people they need to understand the process.

Nick: this has moved to Section 5.

Heather: the Annie buys a book can be deleted.

Tzviya: here is a section in here called "Retail"

Ivan: I think without going into detail, this whole section reformatted etc… we should keep them and they refer to publishing practices and should be kept.

Nick: I don't think 5.2 is needed.

Tzviya: we are not covering conversion to other formats.
... websites become unavailable we can add that to the off-line requirement.

Nick: limited connectivity is also req.

Tzviya: I would say the one example is purchased content.
... , thoughts should this section should go? Remove the website going away for sure.

<laudrain> +1

Tzviya: , Heather can you mark retail with a question mark
... we are not getting through everything today.
... , are we comfortable with the overall structure?

<dauwhe> Maisy: Woof

Heather: action items, someone to help me get Locators use - cases (Tzviya)

Tzviya: Monday we will do manifests.

Heather: can someone get me a better title for section 3.

Ivan: section 3 is a hodgepodge. we will have a manifest thing but its unclear at this point. maybe Monday

Tzviya: there are two sections on manifest, if on Monday someone can bring a use-case
... , I will email Heather in advance for the agenda

Heather: its a pretty flat heading structure.

Avneesh: having issues with a11y with the document.
... : there is a section on fundamental / implementation

Heather: i have been rendered version, I can adjust this. Raw HTML everything is H2 regardless where it lies in a section.

Ivan: I though Re-spec changes that.
... , feedback for Shane actually. since it should have been handled by respec. (wait this is prior to re-spec)

Heather: I will fix this.

<HeatherF> :-)