Markus: "The agenda - scribe is done, next
up - lets approve last week's minutes"
...: "Comments/questions? - Approved."
<HeatherF> Why didn't I ever get president's day off???
<dkaplan3> +1
...: "Next up - next monday is 'presidents day' in the US. Which means
most people don't work. The suggestion is that we cancel next weeks
meeting. We'll reconvene again on the 22nd - at which point I may not
make it as I'll be in Baltimore."
... "We had 2 major topics for today - go back into the fray of
use-cases and consolidation - and see if we can identify any hot areas
we can focus on, then an update on what's going on with epub 3.1"
Markus: "Romain, Heather or Dave, can you give a summary?"
Romain: "so far, the document hasn't changed - no edits or new use cases, but I created issues in the GitHub tracker to review the existing use cases. I received a few comments on this first pass of review. Then we have to take decisions on which use cases to keep or discard. That will close the review phase and we can consolidate all the things we say we should keep - then create/merge new use cases that make most sense."
<rdeltour> https://github.com/w3c/dpub-pwp-ucr/issues
Romain: "Do you want to go through the issues in the tracker? Can I give a summary for each issue?"
Markus: "Yes, maybe we can do that. What do you mean by discarding? What is the reasoning?"
Romain: "Generally when I say discarding - it was because it was either not specific to PWP or if it was something too big for the PWP use-case document and would require it's own document/note."
Markus: "Lets see if Deborah has notes first."
Deborah: "I wanted to let Romain and the others doing the use-cases that the accessibility briefly talked about the use-cases. And we noted that some weren't actually use-cases - and when we're done with our current task, we'd like to discuss in more detail the use-cases around accessibility"
Romain: "I created one issue for each
top-level section we had on the wiki page - not saying it's the eventual
structure of the document but how it was created."
...: "Issue #3 - styling and layout. There I
think there were use-cases related unspecific to PWP which could be
discarded - such as how to represent tables, outlines. These are not PWP
specific but general HTML/CSS use-cases, so I don't think we should
cover these types of cases."
Markus: "what we hear from time to time is that certain things like decimal alignment"
Ivan: "What I don't know is - we have to give a scope to these documents and we have to be careful not to put everything in. I think that the discussion around having these use cases is that we're fighting with a number of architectural issues - locators, etc - for all of those cases we need use-cases, so that is important. On the other hand, the CSS kinds of problems is taken care of by a separate task force and a separate document, which is championed by Dave. I dont' think that merging everything into one major use-case document is very helpful for us. In this sense is that I agree with Romain that this is something that the separate Latin-req and CSS-use-case collection work we are working on already covers. In the final note it's probably worth making clear that there are issues like the CSS thing, but accessibility issues may also fall under the same heading that Deborah and Charles are editing. We should regard that as a family of documents."
<rdeltour> +1 on the need to scope the UC&R doc.
NickRuffilo: the table or stuff is a
requirement from the industry
... so we should encourage people to reach out
... to appropriate groups like CSSWG
... to include that as part of PWP seems out-of-scope.
mgylling: do you think it's out of scope to make pwp dependent on typography features?
NickRuffilo: yes
... PWP would say that CSS is our solution for display
... but changing CSS is a separate task
Deborah: "I want to disagree slightly with Nick and Ivan in terms of .... I agree that these things shouldn't be part of PWP - but I don't think the answer is push back on publishers. PWP depends on CSS/WCAG, but we very strongly agree with the sentiments in the accessibility task force... Or we very strongly back a request for CSS. I think we need to make it clear ... The PWP spec is not about the publishing industry. There was an issue - adjustable timing for assessments. I don't think PWP needs to depend on adjustable timings, but if PWP is what we want the publishing industry to use - and they desperately need it resolved - so it's important for the group to back these items. We point to this note."
<astearns> it makes sense to me to bound the scope of PWP, but DPUB scope shouldn't be limited to PWP
Romain: "I think I agree with all the comments - and I'm sure there is a bit of a contradiction on some of this - so we need to figure out where these use cases go. We need to note what digital publishing needs, as well as what is relevant for PWP. So basically the PWP document shouldn't contain all of the use cases relevant for Digital Publishing."
Bill: "We need to not confuse dPub IG with PWP"
Ivan: "We already have documents edited by accessibility and Dave Cramer's task force, and then people working on the archive. So we should scope these documents really on PWP specific items."
NickRuffilo: we've settled most of this. We
have recommendations relevant to making PWP relevant
... and ones for PWP as a format
Romain: "Yes, we just need to identify the scope we're talking about when it comes to PWP."
Heather: "We'll bring the confusing cases back here - don't worry."
Romain: "Pagination - do we need to include this or not? The automatically paginate a reading system should conform with tables. More generally - is pagination in the scope of this document, and to which extent? Pagination is a complex and intricate problem that will require it's own document. The use-cases for pagination that would be in scope is related more behaviorally which part of the reading system. Is it the browser? A reading system? These are more the use-cases that we need."
Dave: "Pagination is, in some ways different from what we talked about earlier. Much of the complexity is the relationship between files. Things like decimal points and tables affect different files, but if we have pagination we need to do transitions between different files - which brings us closer to what we need to solve for PWP. I know Daniel Glassman has brought up issues for transitions between files."
Markus: "So, you're saying Dave - that the rudimentary nature of pagination should be here, not necessarily the machinery."
Dave: "I think it's something that's going to influence lots of different pieces of this - including how users interact with items. It's one of the elephants in the room. Even the simplest thing - such as I'm reading and 'what's the next file'. How do I get from chapter 1 to chapter 2? I think we need to think about that while keeping in mind that Pagination is highly desirable as a user experience."
Ivan: "In addition, pagination may also touch on the discussion about locators or fragment identifiers. Sometimes we know there is a habit of referring to 'page 5' whatever that means - which is one more reason why this is important."
Romain: "One concern that I had when talking about these kinds of use-cases is that we need to identify actors - so we have the user, the publisher, but I'm not sure about the reading system as it is a fuzzy thing. Sometimes it's a browser, some times it's a reading system based on the browser. For pagination, it's important as the system that will paginate is not identified. Is it the reading system? The browser? A Javascript Polyfill? "
markus: "I hope we can pretend that there won't be things built on top of browsers. One of the core goals is native in-browser render - that there is just one client-actor. If we run into problems, then that is good information as we've run into something new."
Romain: " That could work."
Nick Baretto: "The one thing that strikes me with pagination is also on how it's sort of flagged to the browser. If the user turns the page and hits the end of the document - turning the page takes to the next document. The page-turn needs to be a recognizable. So there is now a page-turn event - which seems both out of scope and crucial for this."
Ivan: "Why do you say out of scope?"
Nick B: "It seems like it is a very large thing, and implementation-specific. We don't know how a user is necessarily turning the page. Is it right-arrow? Space? Tap on screen? All of those interactions fundamentally boil down to the same thing?"
Nick B: "If we're talking about the browser being the only client? "
Markus: "In general - before we queue - the purpose of use-cases is two fold. In the end, it's to reality check your spec to see what is solved, but in the short term it's to create functional requirements. If we go down this route with this project, then the whole can of worms of new events that are needed for a pagination engine, then it would have to be in scope. maybe it's too big of scope, but we need to get to that level for a use-case. Otherwise it's too shallow for things to work."
<rdeltour> that's why I was recommending having a dedicated UC&R doc for pagination, or pagination API
Dave: "The interest group has done some work along these lines. Brady's group has wrote up changes to the DOM - although I'm not sure where they are."
markus: "There's a dedicated wiki page for Brady's work"
<dauwhe> https://www.w3.org/dpub/IG/wiki/Functional_Requirements_for_Pagination
Ivan: "An answer to Nick B - it is difficult and I'm not sure we'll be able to solve it in the future. Which is a good argument why we should be discussing it and having it as a use-case. We should be very clear about what we would like to see. In some sense it binds to another issue - Whether any work on APIs is in the scope of this group. Any work that is a bit like the POM discussion we had in Sapporo. "
<dauwhe> NickRuffilo: do service workers live outside of the page?
<dauwhe> ivan: the issue is when and how to move to new pages
<dauwhe> NickRuffilo: then this is in scope
Markus: " Romain - pagination in scope?"
Romain: "I think we should focus on the PWP focus for pagination - but leave the rest of the things out of scope. So the things like merging several files/documents and reading them as one, but things like triggering an event when the user turns the page is out of scope."
Markus: "One of the issues is that we have
messy and incomplete documentation of our needs/wants - and the whole
idea of this effort is to have things be central and complete in a
certain area.
...: "In a way - when we say 'lets do another document' we're stepping
away from that goal of coming to an end point. The scope you just
suggested is a good starting point."
Romain: "I'll try to document clearly whenever we discount something. That's it for the first issue. But we covered the most tricky things. The second is domain-specific content types (#4) there most of the issues can be discarded as they are about requirements, about the contents - about math/chemistry/etc these types of things are related to Digital Publishing not PWP.
I'm moving to the next one #5 - identifiers. We already said that was out of scope of the Digital Publishing Interest group to solve this issue - but we can nonetheless mention it, just out of scope for us to solve."
...: "Metadata - need to
consolidate use-cases. Describing that a PWP derived from a dataset. not
sure we need this kind of detailed use-cases in the document. Did
introduce providence, which is important - so we keep that sort of ID. "
... "Issue #7 - content and markup. I had the same
question about how to consider browser/reading system/polyfill, but we
answered that. There was a use-case about using a PWP as a dictionary in
a reading system to be used with other PWPs. I estimated that it was
probably out-of-scope for the first iteration, but then Ivan said it was
a use-case and could be kept. Not sure how to deal with that."
Ivan: "I said that?"
Markus: "I think we should keep it - because this is just one example of how structure - the role attribute - is a good thing. We get questions again and again and again - why do you need more semantics? It's partly for accessibility and partly for advanced functionality within the document. Having them consolidated and put in a note with a URL we can memorize... At least for the structural semantics part, we should keep it in."
Romain: "OK - I agree. As long as we stay pretty high-level in the phrasing, I think we're OK."
Markus: "You had 'other' in content and markup"
Romain: "Most were out of scope... One was about identifying markup - "
Markus: "What do Charles and Deborah say?"
Romain: "This use-case wasn't about pre-page markup, it was about identifying elements that we know can be used ... "
Markus: "So CSS media-at rules more? Lets not go into detail now..."
Romain: "Scroll direction - is it in scope for PWP or more general thing?"
Markus: "I don't know... I'd like to hear from our CJK friends. If this is something that occurs in ebooks but is not heard of in the web, then yes, it'd be out of scope."
Dave: "I think this is handled in CSS"
Markus: "What surprises me is that it's publisher over-rides. I'd make sense as user-overrides..."
Dave: " This use-case seems Odd... But the browsers are focusing efforts on crazy scrolling effects, so I think we're OK."
Ivan: " Those of you who use macs, At some mountain or animal, the default way scroll works was changed - then it became a user settable preference (the way I liked for 20 years, or the new way). The question is whether it is a serious use-case when I read a book. That's the only technology that came to my mind right now."
DavE: "I don't think this is publication specific."
Romain: "We have 10 minutes - should we discuss ePub 3.1?"
Markus: "We can do that next meeting -
would prefer we finish this discussion."
...: "One of the more interesting questions I have is - have you so far
detected areas that are scattered collections of stuff or are
extraordinarily weak?"
Romain: "Not really, but the use-cases are not very detailed. Especially on the places that are very specific for PWP. I'm thinking of transitioning the states between online and offline. We have things but in the earlier use-case they were not very well covered. With the recent discussions in the locators task-force we have more. About missing things - we have one missing thing about DRMs and security. maybe it's not the same thing, but it's related. "
...: "We have almost no use-cases about that. Or to what extent we have use-cases there. Do we want to enable DRM solutions or further refine that? Those are the types of things we haven't discussed."
Markus: " There are many publishers who argue that it needs to be had - it's a can of worms - but it's still a deal breaker in certain industries
<laudrain> +1
Markus: "Speaking of portability - do we have the basics in why portability is important?"
Romain: "We did not have a lot of use cases in the original wiki - but we've talked about it in the locators task force. We agree on what we're talking about."
Ivan: "I am almost sure that when we started the exercise of use-cases, the whole offline vs. online was not among the use-cases. It wasn't in my mind. It was later that it became more clear. On the other hand, Romain - the first half of the PWP document - what used to be the white paper - actually has a bunch of use-cases. They may not be detailed, but it might be the fastest to take them out of there and rework them and add more detail. It would give a start. They emphasize the starting point of the white paper."
Markus: " When it
comes to the archival task force - to feed the findings in there of
course. Lets not forget that the user actor is one we need to emphasize
as well when making these use cases. Archival may not have the user as
their primary actor."
... "You mention security as well as DRM"
Romain: "Yes, it was in the wiki, but empty. I'm not sure what's specific to PWP on that."
Ivan: "I think Daniel is on the call - the work that was done at Readium - Lightweight Content Protection - their might be use-cases there that are defined on a relatively high level for necessary content protection - that we are happy to put into this document, without taking the side of the DRM."
<dauwhe> NickRuffilo: if PWP is opened in browser, and that browsers can have extensions
<dauwhe> ... if we make the RS as a first-class citizen that is accessible, than DRM scheme can create browser extension
<dauwhe> ... don't make content protection part of the spec
<rdeltour> (For the record: note also that security isn't just DRMs: e.g. deliverability over HTTPS, CORS, signing, etc. We'll have to figure what's in scope.)
<DanielWeck> EME https://www.w3.org/TR/encrypted-media/
Daniel: "L doesn't stand for "lightweight" anymore. I wasn't involved in writing it - so I can't speak for the specification. There may be a list of use-cases. Reach out to Hadrien Gradeur. From a readium perspective, when it comes to looking out for use-cases that might not get in the way of DRM - the most fundamental baseline is that you have encrypted content streams that you need to feed the reading system with. Encrypted content streams can be done in a service worker - so I think that's all that we need to discuss when it comes to PWP.
Markus: "That's exactly what epub has done
- just a few very anonymous hooks where you can put stuff, but silent on
whether or how you actually do it. Epub uses a w3c spec for encryption
XML"
... "Romain made a great IRC comment about security and CORES - when you
have an origin-based security model - what do you do when the document
doesn't live at it's origin. Signing and CORS are important cases."
<DanielWeck> Also: HTTP REFERER, WebFonts CDN, etc.
<ivan> Romain++, Heather++, Dave++
Romain: "Would be good to have focused sessions like this once every 2 weeks."
<ivan> NickRuffilo++ (I shouldn't forget that)Markus: "Meeting canceled next week - we'll be back the 22nd"