Publishing Working Group Telco — Minutes

Date: 2018-10-15

See also the Agenda and the IRC Log

Attendees

Present: Wolfgang Schindler, Nick Ruffilo, Ivan Herman, Dave Cramer, Jun Gamou, Tzviya Siegman, George Kerscher, Jeff Buehler, Romain Deltour, Wendy Reid, Rachel Comerford, Matt Garrish, Gregorio Pellegrino, Tim Cole, Luc Audrain, Deborah Kaplan, Avneesh Singh, Franco Alvarado, Chris Maden, Ben Schroeter, Ric Wright, EvanOwens, Lillian Sullam, Marisa DeMeglio, Derek Jackson, Mustapha Lazrek, Caitlin Gebhard, Garth Conboy, Joshua Pyle, Bill Kasdorf, Brady Duga, Benjamin Young, Karen Myers

Regrets: Hadrien Gardeur, Vladimir Levantovsky, Juan Corona, Laurent Le Meur

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo

Content:

Tzviya Siegman: First item - review the minutes. Comments?

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-10-08-pwg.html

Dave Cramer: They are a work of art

Tzviya Siegman: Minutes approved

Resolution #1: last week’s minutes accepted

1. use cases and affordances

Tzviya Siegman: Franco and Josh are up to talk about use-cases.

Franco Alvarado: We discussed the use-cases - and overview of what needs to be done. We’re splitting up the work of identifying use cases that need to be discussed and documentation that doesn’t have a use case. we’re targeting to have it done before Lyon

Tzviya Siegman: I know Josh did a bunch of work, but no merges…

Joshua Pyle: I haven’t done any work yet on what Franco just discussed - the Gap analysis, but the other work I did on the UCR was somewhat off topic and I wouldn’t recommend introducing it into the spec…
… I feel like I got a little off topic, but I think it will be a distraction if I submit those particular changes.

Tzviya Siegman: So you expect to have the gap analysis a week from today - which is before TPAC?

Joshua Pyle: we set that goal, and I plan on setting a few hours aside before Friday

Tzviya Siegman: We have a session around this at TPAC - we need to know if you’re going to have things ready - will you have things ready? Will you be able to call in?

Joshua Pyle: 2:30am is my JAM - Im here

Tzviya Siegman: We need to make sure we have the user agent affordances

Joshua Pyle: I think we have that. The UCR - the use case that are in there are pretty good. They are 2 years old, but unless we plan on expanding them, they explain what needs to happen. I get the sense you’re expecting seems on new written prose and use cases.

Tzviya Siegman: https://w3c.github.io/dpub-pwp-ucr/

Joshua Pyle: there’s not a lot of missing use cases from the document…

Tzviya Siegman: Josh, you are more familiar, but we thought this part would take up the bulk of the meeting…

Tzviya Siegman: we keep coming back to “we don’t know what affordances are” Do you think if someone was creating a User Agent - do you think a UA knows what they need to know to create that. Does the UCR explain that?

Joshua Pyle: Without distraction, I would say that - for our current vision of a web publication, which is a way of binding web pages into publications, I think what we have suffices. I don’t think if I was the accessibility expert, I may not be particularly happy. If I was the marketing person, I wouldn’t be excited, but if I was a straight coder, I think it’s in there, but I’ll look.

Joshua Pyle: I’ll provide that analysis as an implementer.

Tzviya Siegman: One more question - so we can come in informed, is there something that the rest of the group should do? Let us know if there is something the rest of the group can do

Joshua Pyle: anyone who thinks they would participate in the discussion, a read through would be great. I know Ivan, you, and I have looked at it and discussed but others should re-read it if you want to make the most of the session.

Ivan Herman: Close to what nick said - but put differently - if I am the reader of the current draft of the spec, I would like to have “these are the main things that a user agent SHOULD do or MAY do with pointers to the use case” The way the use case document is written is about people doing things. But in the other document there needs to be a list of features and what it means for the user. That’s the bridge I’m looking for, and that we don’t have.

Deborah Kaplan: I wanted to add to the ‘how would I feel about accessibility’ we made a choice with the first UCR when it came to accessibility. We merged the accessibility use cases into the main document. Every piece of feedback from accessibility people is negative. It’s absolutely true that the people who have seen this draft who are accessibility people freak out - they just see the note in the accessability section. That is a think we need to address. We don’t need to write more use cases, but make the accessibility ones more to find and surface

Tzviya Siegman: I think, in general, that’s what we need to do - identify and classify the use-cases better

Wendy Reid: I’m creating a bunch of audio-book specific use-cases.

Joshua Pyle: I’d love for you to create a branch and merge them in, or you can send me a google doc and I’ll put them in. I think we decided that we should add audio book use cases to the main document.

Wendy Reid: there are some use cases that just need a line, and there are some that need a use-case.

Tzviya Siegman: Some things I’ve learned from use cases in other groups and with labeling; in verifiable claims WG, they have sorted each of their use cases by the area it touches - health care, finance, etc… They have other use cases that reflect the technical work.
… it sorts through the tech aspects of the spec, in our case - multiple ways of navigating through XYZ, Audiobooks, etc. We might want to demonstrate that it is a business AND technical document.
… I spent lots of time on “focal use cases” which are just 3 use cases that demonstrate difficult use cases that we’re trying to solve and how it is that the technical solution that this spec is offering solves that problem. It is much longer than the 1-paragraph use cases. We might want to consider that. If you’re writing, it’s a really good exercise.

Tzviya Siegman: Any other use-case comments?

Ivan Herman: I have a very administrative thing we have to do about use cases. When we voted on automatic publishing, I don’t think we did that about use cases as it wasn’t part of the document, so - Josh, at some point, with the help of Matt, we’ll have to set it up to automatically publish … but when you’re ready

Tzviya Siegman: Josh and Franco - if you think you’re going to miss the deadline, please let the chairs know ASAP
… Updated document for UCR and the gap analysis

2. WP rendering in non WP aware browsers (issue 271)

Tzviya Siegman: https://github.com/w3c/wpub/issues/271

Tzviya Siegman: Issue 271 - which we put off until we understood better what it means to be WP-aware as a user agent. Last week we decided to give us a week to wrap our heads around it

Avneesh Singh: I proposed the concept only - but the consensus was that we should - we want a minimum viable WP that works on a non-WP aware user agent, and some additional functionality for a WP-aware user agent.
… So we would need to make use cases that would be split into two buckets - WP-aware and non-WP-aware

Ivan Herman: I’m not sure I fully understand the issue. If we have a non-WP-aware, then you see the landing page for the document, which will link to other important documents and parts of the document - and the user agent can do something with it. What else do we expect? Is it best-practices - to make the primary landing page to make sense to the browser (so having a table of contents)?
… But from a browser side, i’m not sure what you expect

Avneesh Singh: In a way, when we put TOC of page-list on the entry page, we are bypassing the manifest so things can be displayed. But - what is the functionality we want to work in the browser or reading system. For example, offlining or bookmarking - they could be added as a plugin. Or do we want more things in the minimum viable document.

Ivan Herman: From my memory, the only thing still pending - and it’s a long discussion - is the fate of the title element, which is something that can be used to bypass the manifest and the manifest can make use of it if it’s WP-aware.
… The page list, the TOC, and manifest are the things that could be picked up. Can we be more specific? I don’t know what the design principle is, but these are the only specific entries that I remember.

Tzviya Siegman: I think this will come up in the discussion about boundaries - we have a 1-hour session to talk about boundaries, but we could probably talk all day

Dave Cramer: We need to think about web publications as a progressive enhancements to web pages - we need to structure them so that all content is still available to a vanilla non-WP-aware browser.

Luc Audrain: +1

Ivan Herman: I understand, but I’m not sure what it means specifically as far as a spec goes - this is generic and general.

Jeff Buehler: +1 Daves comment

Matt Garrish: I wanted to +1 to Ivan. From an editing perspective and spec perspective, what are we hoping to achieve? This is authoring guidelines, not necessarily spec. What would happen if the user didn’t do these things? I don’t understand what we can spec out in this space. This seems best practices.

Nick Ruffilo: +1

Avneesh Singh: Ivan’s question is the main objective - we want to identify what we want to work in the reading system - for example, if we talk about page list, early the TOC was/were in the manifest, then we pushed it to the entry page, especially for accessibility reasons - you shouldn’t need a reading system…

Benjamin Young: +1 to Avneesh

Avneesh Singh: So are there more uses cases and features like this that need to also be non-WP-aware. Or things that are complex and need to move to the WP-aware section - and thats the objective.

Brady Duga: I’m not sure how we solve this with best practices. Such as how do I make something display best in both WP-aware and non-WP-aware. So for non-WP-aware, I put a link to the next chapter, but I don’t want it installed in the WP-aware… That is the type of thing we can address in the spec, that I don’t think is addressed in best practices.
… Thats one case where we would want different features/functionality in WP-aware and non-WP-aware.

Dave Cramer: We can say things in the spec that give us some foundation - such as the TOC must appear in the main document, and the user can see the core of the publication despite the nature or core of the user agent. That sounds like a minimum standard. I want more time to think about brady’s proposal…

Deborah Kaplan: I wanted to 100% agree with Brady, it is a place for the spec and not best practices - as soon as the chairs think we have the prerequisites for being a WP-aware browser, as soon as we have that, then coming up with what it does is solvable, but we have to put it in spec or we will have lots of aspirations and less results…

Ivan Herman: 2 things - Administratively - I have the impression that having a design principle that we agree on, that would be good to have recorded as ourselves, but the specific issue should be close because that it doesn’t lead to something specific. For every feature we should look at it if it makes sense to determine if it should be interpreted by a non-WP-aware features…

Ivan Herman: One thing Dave said is not true today. At the moment, the TOC is not required that it MUST be in the primary page. It can be - and may be advised to be, but it can be in any place, or a different file, or only linked from the manifest. This is one example where if we say MUST, we create a restriction. I am neutral but I don’t think this will get consensus.
… lets not forget that the WP is the basis for EPUB4 in which this whole issue doesn’t come up. So this kind of restriction is unnecessary. We need to make sure we draw a line as to what is required and what is not.

Tzviya Siegman: This is an important discussion, but is not the best time to have it.

Ivan Herman: We do have a spec, and with the example of the TOC - we have to be careful that if we run in one direction, we have to back-pedal, which is never good.

Tzviya Siegman: I just sent a message to Romain, to see if he proposed design principles in the past.

Romain Deltour: https://github.com/w3c/wpub/wiki/General-Design-Principles

Romain Deltour: (although I don’t think I was at the origin of that :-)

Avneesh Singh: The original proposal is like a design principles about what goes into WP - if it’s important or useful, then it comes to the question of must/can. There is a possibility that we want flexibility about the TOC being in the manifest or entry page. This is why the proposal also mentions profiles, we may keep the flexibility of WP and create a profile that provides guidance for creating a WP that can be read in non-WP aware browser.

Benjamin Young: I feel like there are two bugs in our approach that if we solve it will help. If we determine what user-agent web publications are for. With Web in the name, I assume browsers. 2) if we remove EPUB4 from the lineage, and say “we don’t know what EPUB4 looks like” then WP doesn’t need to pre-design itself as EPUB4
… and ultimately EPUB4 would get addressed when it does, but for reading systems and likely also browsers. Having them backed up against each other is causing confusion.

Ivan Herman: I think that’s exactly the problem why we need the discussion with the business group at TPAC. If we separate WPUB from EPUB4 - in some sense - then the questions from me - the purely technical guy - is whether this is something that makes sense for publishing. I am afraid the answer will not be positive. For me, WPUB is potentially the content for an EPUB4…
… That my view of what can be implemented solves for the publishing industry. I do like the idea of profiling - which is a bit more formal way and more specific than the general best practices approach. If my profile is EPUB4, or “I don’t care about packaged” then we can make these distinctions about must/may
… but I think we should keep both in mind. That way they both represent the industry

Luc Audrain: The real issue is what you mean by separate. More precisely, what would make a difference that could not be reconcilable in a profile. EPUB4 is a profile of a web publication. In my feeling EPUB4 will be based on everything from the web publication but with constraints. We should be very careful about identifying something that would make a web publication not profileable

Garth Conboy: I largely agree with Luc and Ivan. We had WP, PWP and EPUB4 and we dropped PWP out of the mix as EPUB4 would be the packaged version. I would come at this opposite from Ben in that I think the odds are that if we define EPUB4 sooner rather than later, it’s likely to get traction before WP unpackaged…

Tzviya Siegman: https://docs.google.com/document/d/1Mt9PTcOdmrCwIsgfxbGMGjwHlUsySU01I0D4oBkSbcA/edit?usp=sharing

Bill Kasdorf: +1 to Luc

Tzviya Siegman: We have this as a discussion for TPAC. EPUB4 cannot come only a few months after EPUB 3.2 - even within a year, so we need to discuss who is likely to adapt and when. Lets take a look at the design principles and make sure those are what we’re applying
… we need to figure out what that means - there’s lots of JSONLD, but in case of conflict, always consider the users, and we haven’t necessarily taking that into account.

Bill Kasdorf: scholarly book publishers are doing EPUB

Benjamin Young: I think Garth and I agree more than we disagree. If the major concern is EPUB, then WP as a name specifically would be best served in a community group of people who are not primarily using EPUB, and it be explored there for a lineage it doesn’t fit into.
… I think we can overlap or merge, but lets not entangle WP and EPUB4…

Bill Kasdorf: We need to be careful not to think of WP and EPUB as two distinct and separate things. As Luc said, EPUB 4 is a WP with constraints. It IS a WP, but a special kind of WP.

3. TPAC

Ivan Herman: tpac schedule: https://docs.google.com/document/d/1Mt9PTcOdmrCwIsgfxbGMGjwHlUsySU01I0D4oBkSbcA/edit?usp=sharing

George Kerscher: Moving on to the TPAC agenda - I got the link and bookmarked. Are there links in the agenda to the various things we should be reviewing?

Tzviya Siegman: A great deal of detail was added to the agenda. If theres anything you think we’re missing, let us know. There are a few sessions we may have flexibility with. We have a joint session with internationalization. Tuesday is lots of time with the business group and be informed by the business needs of the industry.
… We have 30+ people joining for dinner - links at the end of the document to tips and tricks for Lyon. I won’t be much help as I know little about Lyon. We look forward to seeing you.

4. Resolutions