Publishing Working Group Telco — Minutes

– DRAFT Minutes –

Date: 2018-02-12

See also the Agenda and the IRC Log

Attendees

Present: Teenya Franklin, EvanOwens, Tzviya Siegman, Ivan Herman, Zheng Xu, Dave Cramer, Wolfgang Schindler, George Kerscher, Chris Maden, Luc Audrain, Gregorio Pellegrino, Toshiaki Koike, Mateus Teixeira, Deborah Kaplan, Ric Wright, Lillian Sullam, Benjamin Young, Ben Walters, Rachel Comerford, Jeff Buehler, Vladimir Levantovsky, Romain Deltour, Bill Kasdorf, Garth Conboy, Mustapha Lazrek, Ben Schroeter, Laurent Le Meur, Hadrien Gardeur, Brady Duga, Marisa DeMeglio, Heather Flanagan, Greg Davis, Tim Cole, Nick Ruffilo

Regrets: Joshua Pyle, Avneesh Singh, Baldur Bjarnason, Peter Krautzberger

Guests:

Chair: Tzviya Siegman, Garth Conboy

Scribe(s): Dave Cramer

Content:


Tzviya Siegman: anyone who’s new to the meeting?

1. minutes from last week

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-02-05-minutes

Dave Cramer: (the usual silence)

Tzviya Siegman: it was a meeting of ideas :)
… minutes approved

Resolution #1: last week’s minutes approved

Dave Cramer: (submarine noises)

2. short WAM overview

Tzviya Siegman: we have a last-minute addition to the agenda
… Romain will give us a tech overview of WAM (Web App Manifest)

Tzviya Siegman: https://www.w3.org/TR/appmanifest/

Tzviya Siegman: WAM use cases https://w3c-webmob.github.io/installable-webapps/

Romain Deltour: the Web app manifest is a JSON document
… that can be linked from an HTML web page
… when a user agent (browser) sees that link
… it can detect that the web page is a web application, and then process the manifest
… to consider the web app as a native application
… that’s the original use case
… define the minimal set of information that a user agent has to know to install a web application to a home screen
… this spec, defined at W3C, defines a JSON format and object
… it also defines this document can be obtained and processed/parsed
… and applied to an application
… that’s the simple thing that the WAM does
… it can potentially be useful for our use cases
… we want to identify that a piece of web content is a publication
… and then hand it off to a library/reading system
… there are synergies between detecting a web app and detecting a publication
… you can open both in a special user interface (UI)

Ivan Herman: I spent some time today going through the document again
… there was one thing that we already discussed on github
… what bothers me is that, process wise, the content of the WAM is read by the user agent
… but the result of that processing is unavailable to any script
… if we add our own terms to the WAM, whatever information we put there we have to duplicate what’s in the spec in terms of getting hold of that data
… in an ideal world, there’s no need because a browser would handle that (or a reading system)
… but it worries me

Romain Deltour: I agree with your point of view
… in order to confirm your concerns, first we have to define what is “we”, and who is going to use the data
… right now we haven’t defined these pieces
… the involved parties are simple–a user agent
… like the web browser
… in our case, because we are defining web publications
… we were defining as if we had a web browser in mind as the user agent
… and native reading systems have similar controls to browsers
… a UA for WP is another web application itself, which makes the situation more complex
… due to cross-origin resources, etc
… before we define what the involved parties are, and what affordances we provide to the users, I think it’s too soon to dive into details

Ivan Herman: if we were in an ideal world, I’d agree with you
… but we are not in an ideal world
… in the short term we need to have a strategy to get there
… making some sort of proof that this is useful, and that browsers might be interested in implementing
… for that purpose, we have to have a strategy of how we would implement these things where a browser doesn’t do the job
… that’s where I see a practical problem

Tzviya Siegman: I don’t want to go down the same rabbit hole as last week
… let’s decide what to spec

Ivan Herman: I’m worried that we will make it impossible

Romain Deltour: my point was not that we should do an idealist spec
… when you talk about a practical spec
… and have proof that it’s useful
… there are lots of ways we could implement this thing
… the environment can be a browser, it can be a browser+extension, it can be a web app…
… it can be a native reading system
… we haven’t decided what the targeted use cases are

Tzviya Siegman: I agree with Romain, we might be talking in circles
… we say this won’t work, but we don’t say what this is
… maybe we should move on to the next agenda item, and maybe revisit this later

Brady Duga: naive question
… is there a JS API for manipulating the manifest?

Ivan Herman: No

Garth Conboy: for the time being, a reading system or browser with extension, maybe that mitigates the need for script

Brady Duga: you can do this by extension, but you need the JS

Tzviya Siegman: so brady will do that work :)

3. Latest changes in the WP draft

3.1. Lifecycles

Tzviya Siegman: https://w3c.github.io/wpub/#wp-lifecycle

Hadrien Gardeur: there are 3 components to the PR (now new version of the draft)
… 1. adding WebIDL to appendix
… I’ve added a dictionary
… and a bunch of members
… this is not tied to any particular serialization
… so we’re somewhere between RWPM and WAM
… I think that’s pretty stable
… 2. the second part is more of a draft
… it’s the lifecycle itself
… there are three parts. A. discovering, B, processing the manifest, C. default order
… the discovering part is weird in our draft
… were doing almost the same thing, but with a different @rel value
… so we almost have to monkey-patch
… this part would disappear if we use WAM
… the second part, processing manifest, is straightforward
… it’s mostly converting JSON into the WebIDL dictionary
… the third part is the most complex part
… processing the default reading order
… with our current infoset this is complex
… because we allow the reading order in HTML
… it doubles the complexity of the lifecycle
… I think it adds too much complexity

3.2. Affordances

Hadrien Gardeur: the final part of the pull request is about affordances
… we’ve talked about reading enhancements
… I’ve added a number of affordances
… I’ve added one for switching to publication mode

Tzviya Siegman: https://w3c.github.io/wpub/#wp-affordances

Hadrien Gardeur: there are two affordances related to that use case
… one is about switching to a mode with enhancements
… the second is called “add to publication list”, like a bookshelf
… this is not just something that we find in ebook world
… it’s similar with bookmarks in browsers
… I’ve reorganized the previous affordances
… under presentation and navigation
… under the former I’ve added user settings
… in the latter I’ve added progression
… hard to allow user customization plus author control
… for progression, the UA needs to remember where the reader is
… when you discover a WP, you might not discover it from its first resource
… . you might discover from the middle

Ivan Herman: small additions
… it’s not a PR anymore as it’s been merged
… on the second step, not only can the first part can be removed if we use WAM
… but the second part too–processing elements, creating internal representation
… and WAM has extension points
… they can be put there
… the last thing is that there is a PR
… with some sort of diagram of the processing steps, influenced by Rachel
… we can merge that if you want

Rachel Comerford: +1 to the diagrams. I’ve been reviewing them and finding them helpful

Tzviya Siegman: that was a lot of information
… feel free to ask for more information
… don’t hesitate to say “i didn’t understand”

Garth Conboy: +1 on diagrams too

Luc Audrain: +1 on diagrams

Tzviya Siegman: lots of this will fall away if we go with WAM
… almost all of the algorithmic section
… for those interested in the business side of things, section 7, affordances, might be what you should look at
… I need to go through this in more detail

Garth Conboy: the WAM simplifies the algorithm
… that seems to be the case for 6.1 and 6.2 but not 6.3?
… would Hadrien and rdeltour agree?

Tzviya Siegman: 6.3 being reading order

Hadrien Gardeur: 6.3–we must keep it

Tzviya Siegman: we should go back and look at the infoset. there’s a lot of duplication. But not today.

Luc Audrain: thanks Hadrien

Hadrien Gardeur: we need to keep discussing affordances
… having a single issue for all affordances is probably not a good idea
… we need to discuss one by one
… this is where we should focus

Wolfgang Schindler: +1 to Hadrien

Romain Deltour: +1

Tzviya Siegman: some people we need to be specific about the implementation of affordances
… like search across publications
… we do have lots of use cases documented already
… yes, let’s put these in as issues

Benjamin Young: https://github.com/w3c/wpub/issues/52

3.3. Spec organization

Romain Deltour: we spend too much time on spec, not enough on use cases
… first, I’m not the one editing the spec
… second, the reason is that there are several parts in the current spec that we might remove
… but I don’t know if affordances need to be specified in W3C rec track
… same with infoset
… knowing this is useful, but that may not be defined in a spec
… finally, even the concept of a single spec may end up being true
… we might have one for a collection API, one for a WAM extension, etc
… we still don’t have a clear idea of how this will end up
… I agree we need public working drafts
… but for now it’s mostly notes, and work on defining the vision
… and functional things

Tzviya Siegman: I agree

Luc Audrain: Hadrien, the use case of Japanese books with progression from last page to first page
… is it covered by paginated layouts, or is it covered by progression

Hadrien Gardeur: I raised an issue. it’s not covered, needs to be in infoset
… and we also need covers

Ivan Herman: I agree with the general line
… I’m not sure I agree with all the details about doing not-yet-standard work
… the first step that we have to make
… is what exactly we would put in a spec about affordances
… whether we do a detailed API, or whether we stay on a higher level
… if I compare the CSS spec and HTML spec
… the HTML spec is more and more algorithmic API level spec
… where CSS is more on the level on this is how it should be presented
… because the underlying work is different
… I don’t know how to define the affordances
… and how much detail we want to leave to the user agents
… on the practical level, having one github issue for the affordances is not good
… we can clean that up
… cutting the doc into several parts that Romain proposed–we can do this at any time
… we can do the CSS way, lots of modules, or the HTML way, with one spec
… we can decide later

Hadrien Gardeur: I agree that infoset will go away
… it will be replaced by syntax or WebIDL

Ivan Herman: +1 to Hadrien

Hadrien Gardeur: I don’t think lifecycle will go away
… I don’t think WebIDL part will go away
… on syntax replacing the infoset, it depends on serialization
… in addition to affordances, we should go to WAM repo and post issues there

Tzviya Siegman: +1 to posting issues to WAM

Hadrien Gardeur: . we need to ask questions about localized strings, for example, or other display members

Romain Deltour: chiming in on what ivan said
… when you said that splitting the spec is an editorial issue
… I think it’s more than that
… there’s a tendency to put all our issues in one bucket
… but maybe we can use an API for one thing, a CSS Media Query for another thing
… having everything in one spec may limit our vision

Tzviya Siegman: sounds like next steps are cleaning up Github re affordances
… also logging issues on WAM

Romain Deltour: +1

Tzviya Siegman: can you log issues on WAM

Ivan Herman: yes, we can log issues, but before we do that
… we already had discussion with WAM folks
… but we didn’t have a good feeling then of how we’d do things
… now we have a much better view
… and Hadrien had made a collection of things we should try to get done
… maybe having a meeting first?
… to see what’s the best way of moving forward
… maybe we should have someone in that group

Tzviya Siegman: maybe we can work out the details later

Garth Conboy: there seems to be openness to the extension points

4. Testing

Tzviya Siegman: cmaden2 Maden has volunteered to take over testing
… he’s reached out to some people
… anyone want to help out

Chris Maden: I’m already talking with Tim Cole, who did annotation testing

George Kerscher: The Reading System testing group can help, but it depends on what stage.

Chris Maden: but we have some good models to build on
… but I need volunteers
… in the short term to identify the testable assertions
… and in the long term to find resources in groups to test your implementations
… so we can demonstrate implementations

George Kerscher: we’ve developed a methodology
… we have a title with numbered tests
… we’ll be happy to help

Tzviya Siegman: thank you
… anyone who wants to work with Chris on identifying testable statements

Chris Maden: george, when you say “we” do you mean DAISY or WCAG?

George Kerscher: DAISY is running epubtest.org
… our test books are there

Tim Cole: the challenge is to have things… features… written in the spec in such a way that you can objectively confirm that two people have implemented
… if there’s no way to objectively know something has been implemented, you have to remove from the spec
… that’s why you want to make sure you have testable statements early

Chris Maden: Folks can e-mail me at crism@illinois.edu

Ivan Herman: to add to what Tim said
… in a way, when we are talking about testing
… we are talking about two different things
… one is, we have to test the spec itself
… 1. each feature can be implemented in an interoperable way
… there’s a requirement at the end of the process that we have at least two independent implementations for each features
… if not, it has to be removed from spec
… at the same time, 2. the tests have a usage like in epubcheck
… a test for contents and for implementations
… they are not independent
… from w3c point of view, the requirement is the first one

5. Miscellaneous

Garth Conboy: wanted to run through 3 agenda items
… feedback on FPWDs
… circle back to Ivan’s principles in a week or two
… we should skip next week as it’s a US holiday, next meeting on Feb 26
… and a quick call out for Synchronized Multimedia COMMUNITY Group
… and do look at reference number six, on the F2F in Toronto
… and folks at Kobo to reach out to with questions

Tzviya Siegman: https://www.w3.org/community/sync-media-pub/

Tzviya Siegman: and wendy needed info for F2F

George Kerscher: people interested in audiobooks should look at the new CG


6. Resolutions