Digital Publishing Interest Group Teleconference

24 Oct 2016


See also: IRC log


Deborah Kaplan, Ivan Herman, Nick Ruffilo, Heather Flanagan, Avneesh Singh, Ayla Stein, Garth Conboy, Boris Antony, Vladimir Levantovsky, Luc Audrain, Alan Stearns, Chris Maden, Peter Krautzberger, Charles LaPierre, Nick Barreto, George Kerschner, Romain Deltour, Bert Bos, Karen Myers, Benjamin Young
Ben De Meester, Daniel Weck, Michael Miller, Dave Cramer, Tzviya Siegman, Leonard Rosenthol


  1. Reorg UCR document review
  2. EPUB 3.1 & IDPF update

<Garth> [2] https://www.w3.org/2016/10/10-dpub-minutes.html

Garth: "Minutes from last week - any objections?"

<Garth> http://w3c.github.io/dpub-pwp-ucr/
...: "OK - Approved. The agenda Tzviya put together is in Heather's court. We had the re-org effort that heather did and a number of questions that she raised. Link posted above. Best thing would be to turn it over to heather for an overview then questions?"

Reorg UCR document review

Heather: "I moved lots of things around, most use-cases have been removed (commented out) so if you were in love with something, it's still there. The HTML is crazy and needs to get cleaned up. I do have 5 super-high-level questions. I re-read the abstract and made it look like an abstract. I wanted to get a census from the group about taking out the requirement of it being viewable in a browser as that seems a given."

...: "I could use help with online/offline references. I don't think it entirely made sense in every case, so I want to see if anyone thinks things need to be changed. We have 30 requirements. I don't want to repeat what is known from the open web platform. There is a short section on permissions that I wanted group consensus on. All of that was sent out last week."
... "Ivan was able to look at that and provide some additional thoughts. Ivan?"

<ivan> https://lists.w3.org/Archives/Public/public-digipub-ig/2016Oct/0144.html

Ivan: "The only point was that I collected comments, and I sent it just to you instead of the whole group. I sent out the comments again, this time to all. "

<ivan> https://lists.w3.org/Archives/Public/public-digipub-ig/2016Oct/0137.html
...: "Another thing I did was - a while ago, 2 weeks or so, I went through the open issues to see if there were requirements that we should add. There were 4 of them and then we agreed we would come back when the re-org is done. My list is long, 19 points, but some of them are really just stylistic."

Garth: "Being that the email just got to the group 10 minutes ago - do you want to discuss now?"

Heather: "I'm not worried about going through the editorial ones - as they are just a waste of call time, but the items that require discussion we should have a look at."

Ivan: "if I look at the items that require discussion, and I see from the present list, charles and avneesh is around - which is good because i have some issues around accessibility and we should have consensus on that as well. The other thing is what heather raised about security, permissions story - those are the areas we need discussion."
...: "Accessibility - There is a separate section on the accessibility metadata, which is 2.2.6 - on the one hand, I believe that - at the moment - we have 5 use cases there, and we should try to join things up - the first and last are very much the same - so maybe trimming them. Before we go into detail, there is an overlap, toward the end of the document, there is one around the manifest - 4.2 the metadata and the resources. The requirements say that publication should... [just quoting what it says] - and that one lists a number of examples of additional information as what we want as part of the metadata - and it also includes accessibility - so it becomes a duplication - do we need the duplication? Should we have an explicit reference? Is it better not to have a separate section?"

Heather: "I like the idea of merging 2.2.6 and 4.2 - there are several other accessibility 2.1.4 and 2.1.5 - we split them out trying to differentiate between open-web and what was pure-publishing needs - but it's worth discussing."

Deborah: "Things are different - i haven't had much chance to look over again since the accessibility got split into a separate section - so keep in mind i'm speaking with a little ignorance of that change - it makes sense to merge them as long as all of the use-cases that are necessary end up in the correct area. There are a bunch of very-big accessibility things, that we all link up throughout the document - that would be fine, but then we should at least update the accessibility area with the links to this information."

<HeatherF> Good idea on the index of Accessibility. I wonder if any other topic would benefit from that as well?

Ivan: "We would have to - it's sort of a little bit strange. On one hand there are a number of accessiblity use-cases spread through the entire document. It should be, as much as possible, in other areas. We do have a section that doesn't have the requirement - just a link to the information elsewhere. I'm not 100% sure that I like how it stands out. I'm more in favor of having accessibility integrated and part of other lists - as it's part of the web.

Charles: "For accessibility metadata section - you had a question about the last one, we were waiting for the whole re-org. we had a meeting last week to revise these. That might help clarify things. I just wanted to point that out. As far as having accessibility it's own section. If all it's doing is linking to other things - not sure what purpose it has - but I agree with ivan that the use-cases are inline."

<HeatherF> +1 to dkaplan

Deborah: "If there's - there are strong reasons not to and to single out accessibility. There should be an apendix or some way to find all of the accessibility items. While I like the idea that it's integrated, i'm thinking of the reality that people are going to want to see all accessibility items quickly and easily. An easier way than ctrl-F to find these items."

Garth: "Would an appendix B - 'accessibility' resolve that?"

Deborah: "If it gets separated out - an appendix with list of use-cases, or pointing to places that are accessibility related."

Garth: "Does that meet with editorial?"

Heather: "yes"

<clapierre> +1 to a11y in an appendix list is good!

Garth: "Appendix seems like a good idea."

Avneesh: "We observed that some who are not deep in accessibility find it hard to get deep into the details of our accessibility use cases. So we can include use-cases that are easier to understand and spread them out. And then have the more complex use-cases in a separate section related only to accessibility."

Garth: "Lets head in the direction of an appendix and see how we like it."

Ivan: "There was another accessibility thing I listed and we can discuss that. 2.1.1 - the alternate modalities. There is a kind of imbalance of accessibility VS other things. There are 7 use cases, 4 are brail, 1 is other accessibility - so we should be careful not to have too many uses cases slanted towards accessibility without balance for non-accessibility - cook books, but there are a number of use-cases where alternate modality is important. I had the impression looking at the use cases that many are repeating themselves."

...: "Maybe this is one of the sections that got rebalanced, but I haven't had a chance to look at it. Based on the items that are there, I'm wondering if the last case provides anything new. There were 2 use cases, one James, and the other a class of student, both emphasized that the publishers should be allowed to provide a braille modality. The uses cases in these sense overlap - I would like to add examples of the recipe books."

Heather: "Group aside - I like the idea of accessibility appendix, do other topics need to be treated this way?"

Charles: "Ivan, this wasn't one of the sections we updated, but we can looka t it again. it's very heavily braille weighted, but we can change things so that it is more diverse. "

Deborah: "We'll take it on in the accessibility taskforce. I find it fairly important that the accessibility use-cases that they shouldn't be heavily weighted towards braille and blindness, and because that is already the biased assumption for everyone who isn't deep in the weeds, I think we should make sure if we have more-than-one use case in a batch, at least one of them is not blindness.

<clapierre> +1 with Deborah

Ivan: "non-accessibility use-cases. There are a number is section 3 - in my view, they are more general, because they are not necessarily package specific. Some of these sections. Like 3.1 - the idea of single unit is for web publication and not just packaged. I think it should be moved upstairs. There are a number of details. There are some in my comments that are to be moved ahead as they are not necessary only for packaged version. They are all for web publications in general. Then the question heather raised...."

Garth: "That was a potentially controversial statement - is there consensus? I read single-unit there, but reading in detail, i would tend to agree that it's PWP."

Ivan: "If I take 3.1 - user agent must treat PWP as a single-unit and not different resources. This should possibly be the new 2.2.1 - up in section 2 as one of the main things. As I look at the use case on section numbering, user preference, etc. This is just as much necessary for web publications and not just packaged ones."

Nick: "I'm OK"

Ivan: "Permission and Obligation - it's the name of a working group - so we should rethink our wording as not to cause confusion. I have the impression - but my knowledge is low - if i take this as a global section, we could move the security related section into number 4 and call it 'security' I believe 4.2 is metadata and resources is for web publications in general. And then we can have a separate security thing. I must admit that my technical knowledge about security are vague. At first step, i would move them into a "security" group in general. So renaming 'Permissions and obligations' to security and move around 4.1"

<Garth> +1 to Ivan's suggestion re security changes

Ivan: "the rest are small things, and not really controversial - so I think that heather can just take them or we can discuss."

Garth: "Heather, are there other questions you raised initially that we should spend time group-think here?"
... "We discussed removing offline vs online - do we need to discuss, or are we on the same page?"

heather: "It wasn't universal remove offline/online - i just changed it where I thought it should be. I would like folks to go through the document and see if they agree with what I did, and the differentiation of offline and online."

Ivan: "Reading through the text, it didn't jump out at me."

Garth: "People shoul dspend some review time, and provide comments in github or the mailing list (github better)"

Heather: "what we need to do is tease out the current task list. I have some add-moves-changes and we have to make the appendix with accessibility. did I miss anything particular? Do we have a deadline?"

Ivan: "I have one more tweak - one more pending thing was the extra use-cases. For that I also looked at the ... Deadline - no and yes. No specific deadline, but it would be good to have them ASAP. When the use-case document gets to equilibrium point, thats what we want."

Garth: "We had some good momentum at TPAC - and if we get those changes done, a couple weeks from now? that would be very good."

Ivan: "If you want, I can take the next round of review. If you want to remove the comments - we have them in history, so that cleanup is good. From there, I can take on the extra."

Heather: "I can spend some time today but then I'm back on the road again. "

Ivan: "So clean up the text and the comments, and I'll take the rest."

<HeatherF> Buttons fear me. They will do what I tell them.

<ivan> https://lists.w3.org/Archives/Public/public-digipub-ig/2016Oct/0137.html

<HeatherF> +1

<Garth> +1

<laudrain> +1

Ivan: "there are two use cases that are very close to one another - those on security related things - that the user-agent should be able to verify that the document has not been tampered - and that it has been produced by it's signer - to verify the origin. Both are non-trivial. Neither of the two are covered in the current use-case document. They might create problems that cannot be solved. We should add these two to the new security section. "


<ivan> "Any genuine user agent must be able to provide a usable view of a Web Publication albeit, possibly, without the full functionality that a WP provides"

<laudrain> Graceful degradation

Ivan: "Then there was one use case that Garth said was a 'noble goal' which was (pasted above) came from a discussion essentially making it clear that whatever we produce browsers should be able to handle gracefully. It's not really a use-case, but a design principle. An important design princple. If I have the URL of a web publication, it should not return something the browser cannot do

anything with. it's probably not a use-case, so we would close the issue - saying that 'we don't do that' but note that it is a design descision. "

<Garth> +1

<laudrain> +1

<ivan> there is need to send a Web Publication from A to B over different media, not only Web protocols.
...: " The agreement here would lead to closing issues. The last one was a use case on was essentially giving some reasons why we needed packaging. which is covered by 3.2 - but maybe the example I have from dave of tzviya, I personally would prefer to change it again, but I wanted to ask first. The formulation of the requirement itself - that we're transfering a document not only through web protocols. There is probably a clearer way to explain that. "

Garth: "Absolutely - since you have next edit pass, give it a go!"

<Garth> +1

Romain: "Just wanted to note that the requirement from ivans email - it wasn't just about protocols, but more about not being online - but still being able to exchange data somehow. i wrote in the use-case SD card or bluetooth. In bluetooth you could still use web-protocols, so there is a technical detail here. Using 'web protocols' might be too limiting."
... "I'm not sure how I would reformulate, but I would talk more about local connectivity."

Garth: "Any other comments before we head into the next pass by Heather and Ivan?"

<Garth> http://rawgit.com/w3c/aria/master/aria/dpub.html

Garth: "Two more agenda items: DPUB ARIA draft for wide review (link pasted) is that just a request for wide review?"

Ivan: "I believe so."

<Garth> http://idpf.org/news/epub-31-now-proposed-specification

<pkra> Have to leave early, I'm afraid.

EPUB 3.1 & IDPF update

Garth: "The 3.1 specification has gone out of EPUB (link above) and concurrently the IDPF IP review is running now. We encourage folks to review this document. From the future to the now. The other thing in IDPF land, is that they called for a membership vote - toward taking the next steps towards merging the IDFP and W3C. If that happens it will have impact on our efforts here. There have been long discussions - if you have questions or comments we can talk about them here."

George: "I think that's right - something in November - 4th maybe?"

<laudrain> +1

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/10/25 10:20:47 $