Publishing Working Group Telco — Minutes

Date: 2018-01-22

See also the Agenda and the IRC Log


Present: Mateus Teixeira, Baldur Bjarnason, Bill McCoy, Tzviya Siegman, Chris Maden, Evan Yamanishi, Avneesh Singh, Wolfgang Schindler, Luc Audrain, Deborah Kaplan, Joshua Pyle, EvanOwens, Laura Brady, Ben Dugas, Ric Wright, Matt Garrish, Lillian Sullam, Heather Flanagan, Toshiaki Koike, Rachel Comerford, Ivan Herman, Jasmine Mulliken, Vladimir Levantovsky, Charles LaPierre, Tim Cole, Dave Cramer, Hadrien Gardeur, Marisa DeMeglio, Garth Conboy, Bill Kasdorf, Ben Schroeter, Laurent Le Meur, Benjamin Young, Teenya Franklin, Nick Ruffilo, Romain Deltour

Regrets: George Kerscher, Brady Duga, Peter Krautzberger


Chair: Tzviya Siegman

Scribe(s): Mateus Teixeira, Dave Cramer


Tzviya Siegman: let’s get started

Tzviya Siegman:

Tzviya Siegman: minutes from last meeting…
… any comments?

Resolution #1: Minutes approved.

1. DPUB-ARIA 2.0

Tzviya Siegman: part of our charter is moving on from DPUB-ARIA 1.0
… matt and I spoke with Garth and Ivan about this
… some of the issues are to provide more background

Tzviya Siegman:

Tzviya Siegman: DPUB-ARIA 1.0 took EPUB SSV terms, winnowed them down, and put the most useful in the ARIA vocab
… we bit off more than we expected to chew
… DPUB-ARIA 1.0 is a Rec (recommendation)
… complete with AAM
… they map to assistive technology APIs
… so they can really help
… or really hurt if you use them wrong
… some role=”doc-epigraph” has meaning in HTML
… are there missing terms? what else do we need?
… do we need a 2.0? a 1.1? is what exists today good enough?

Wolfgang Schindler: as a dictionary and glossary publisher, we need those sorts of terms
… headwords, phrases, translations
… perhaps as a module

Tzviya Siegman: those were never finalized in EPUB
… and we need to consider the effect on accessibility
… I’m not sure ARIA is the best home for those terms

Bill Kasdorf: fyi EPUB Indexing looks final:

Luc Audrain: we had with @epub-type several higher-level semantic types, like bodymatter, frontmatter, backmatter
… how can I help the reading system to know where bodymatter starting, the true content?
… in recent EPUB 3 files, we have made high-level epub:types mandatory
… we gain some way of saying that there is a document that is body matter and chapter
… and we can say frontmatter + cover, frontmatter+ title page
… today I find in aria @role that there are significant roles like chapter, but I can’t build the hierarchy
… I cannot say where is the front matter, where is the body matter, where is the back matter?
… I think it would be more complete if we had these in 1.1

Tzviya Siegman: thanks Luc

Deborah Kaplan: we can always perfect it, always add more semantics
… but there’s a lot of work in that
… and I care about the practical value of this to people with disabilities
… so first, we should work on the things for necessary for AT providers to pick up on what we’ve already done

Charles LaPierre: +1 to Debora’s comments.

Deborah Kaplan: fine-tuning a spec that’s not used yet is not the best use of our resources

Baldur Bjarnason: +1 to Debora

Matt Garrish: the other thing is, we need to separate accessibility functionality that ARIA provides, the semantic model; can’t just be overloading things because we want them there for data modeling

Avneesh Singh: +1 to Matt. ARIA is mainly for accessibility.

Matt Garrish: there needs to be a clear a11y reason for the semantics we are adding
… there’s a host of problems with getting these validated and accepted
… some parts are probably beyond the scope of this group, should probably be built into the HTML platform itself
… can’t just be putting in things that sound good but have no practical applications

Bill Kasdorf: i’m in alignment with dkaplan3
… the answer will probably come out of the A11y Task Force
… we should ask them what they need

Lillian Sullam: I don’t disagree, but on the publishing level we have been incorporating epub:type and role in books
… very specifically, there’s value in “title page” and “copyright” which seem not to be part of the spec now

Luc Audrain: +1

Avneesh Singh: just to clarify on what the others said
… when ARIA roles work was going on, the general idea is that epub:type will become ARIA
… but ARIA is specific to a11y, not necessarily focused in publishing
… this is not useful if we don’t have a11y tech supporting it
… this WG can’t take responsibility over it all

Tzviya Siegman: this is very important; there was significant pushback from ARIA WG to add some publishing terms
… although there is value within publishing, the a11y community might not want to add it to spec that applies to all a11y tech
… you could use data-* attributes to add vocabulary specific to your toolchain

Charles LaPierre: just a couple things; i agree with what others said
… adding vocabulary to allow reading systems to jump to different locations–like copyright–could be useful
… Benetech is doing a certification program that looks into these things, and that promotes these issues to publishers
… definitely something we’re willing to push, as well as to ATs and reading systems

Ivan Herman: not disagreeing, but I do see one problem
… we don’t really have a standard place for the semantic information
… we’re not chartered to do so, so I can push against it
… but we have a problem because the data attributes aren’t for that
… RDFa is heavy and not necessarily the right solution
… as an industry, we have a problem of not having these possibilities offered
… need to think about it; maybe in a community group
… but we should not just forget about the semantic aspect, even if it’s not closely related to a11y

Joshua Pyle: Scholarly HTML?

Wolfgang Schindler: +1 to Ivan

Deborah Kaplan: happy to move towards that idea
… but it’s important, in an ideal world, to come up with publishing semantics … that provide interactions between industry-specific semantics and the a11y tree
… right now, the problem is the only way to encode semantics is in ARIA, but that’s not the place for semantics that won’t be used by AT
… if there’s a CG, a question could be… can we have a pipeline between the publishing ideas and the a11y community?
… doesn’t mean that we should put the semantics in DPUB-ARIA

Tzviya Siegman: our immediate issue is we need to figure out how to deal with this item in our charter
… there don’t seem to be a lot of items people see as compelling to add to ARIA
… let’s thing about it over the next week
… anything that’s in the existing EPUB Structural Semantics that belong in ARIA?
… one thing that’s come up in the past is “learning objective”, for example
… we need to think about aspects that are relevant to the whole community
… do we have a list? if we have more than, say, five, we will need to think harder about it
… are there things in the EPUB Structural Semantics that make sense in ARIA?

Tzviya Siegman:

Matt Garrish: where do we record that?

Tzviya Siegman: email works, or github repo

Ivan Herman: there is already a dpub aria repository!

Ivan Herman:

Tzviya Siegman: there is already a dpub-aria-2.0 repo

Ivan Herman: yep, I set it up!
… we should use that one
… what’s misleading is that the current document there is the old ARIA draft
… mattg should replace it with an empty page

Matt Garrish: i thought we did that…
… but i’ll take a look

Luc Audrain: main role is for a single document, there is no main role for the publication that would say the same as body-matter !

Tzviya Siegman: but the main message is: add an issue or comment on the repo if you think there are items in the EPUB vocabulary that should be in ARIA

Luc Audrain: was just going to say that the main role relates to the main tag in HTML… to describe that in a single HTML document, it identifies where the main content starts
… but we need to encompass several documents, and to differentiate between front and back matter
… there is probably no relationship to current a11y technologies

Tzviya Siegman:

Tzviya Siegman: makes sense, let’s start making issues in the repo

Dave Cramer: we need to be careful; this sounds great, encoding semantics in the document
… but we need to show that UAs will do something useful with this info
… i don’t expect that my reading system will do something magical with these semantics that it’s not already doing
… this sounds kind of cool, but we can’t add them gratuitously

Deborah Kaplan: TEI exists. And TEI is a problem for a reason, and the reason is that is does everything and thus is no standardizable

2. Implementation update, lifecycle description

Hadrien Gardeur: as a followup to the last call, where I explained the experiments on Reading app manifest and web app manifest…
… a number of people posted updates in the issue tracker
… we have a good set of examples in Readium and others, including epub.js and NYPL’s platform
… not all examples have offline support; some rely on service workers, others on appcache
… in the same issue, we discussed manifest lifecycle with ivan; i created a draft of the lifecycle if we rely on Readium web app manifest if we rely on it as the ideal
… I’d like more feedback on these two items
… we also raised questions for who would be willing to help, and a number of Readium people are interestd
… if there are any others, comment on the issues

Ivan Herman: : lifecycle related issue

Tzviya Siegman: any comments on issues 119, 121, 122?

Ivan Herman: this is great; i would like to request that all those who have other types of implementations, in the web or RSs, to look at the lifecycle described by Hadrien, and try to see if it is in line with what they do
… the point is, many of the lifecycle entries he described are in fact not strongly related to the specific syntax Readium uses
… for example, if garth could contribute what Google Play does, that would be very useful

Dave Cramer: this is my weekly reminder that many of these implementations are creating internal information for use of the RSs, and not for authoring needs; we need to think of that too

Benjamin Young: just ++ on the value of the lifecycle; the use of JSON is great and it’s cool seeing people doing interesting things with it
… but the process of interpreting and describing this is where the rubber meets the road, and will be a challenge

Hadrien Gardeur: just pointing out that the draft I created so far is inspired by the WAM, but it’s interesting that the result is very different from WAM
… there’s very little from WAM that ends up being relevant for us
… the infoset in in the FPWD is different from that of the WAM
… and this has an influence in the lifecycle; it continues to show that we’re dealing with very different info from that of the web app manifest

Tzviya Siegman: one comment on the lifecycle – the default order duplicates information that becomes irrelevant and annoying to create/interpret

Hadrien Gardeur: it takes a lot of additional processing to create a second document with default ordering
… also, if we have them separate, it’s not a matter of serialization, but keeping them in separate documents doesn’t feel good from an efficiency and design point of view
… it’s better to keep all key info in one place. this is regardless of HTML vs JSON

Ivan Herman: what we have to look at is, which of the approaches is best for possible authors
… that was one of the driving efforts at the start
… the original thing is that people need to have an HTML TOC because this has to be displayed, and we don’t want the author to repeat that info in a JSON file
… i think that was the origin of this difficulty

Benjamin Young: this was something I wanted to get to in the browsing context issue (104?)… it comes down to who’s using it and when
… it’s something we’re exploring in the lifecycle document
… there’s probably more than one actor here, accessing this info, but there are bigger things we need to deal with

Dave Cramer: since we talked a bit about the difference between Readium manifest and WAM… one of those differences is that WAM, if you access a component of the app, the manifest will apply and open in context in a browser
… how does this work for publications, if i access an arbitrary chapter on the web?
… we should avoid a world where publications look different depending on how they were discovered

Ivan Herman: the one issue, re Hadrien and WAM, at some point in time we need a separate note or wiki page to give clear arguments and facts on why we don’t use the WAM
… we’re not supposed to add new things to the web if we can avoid it
… if we say we cannot avoid it, we need a good argument
… A different thing, re Dave, I am not absolutely sure this is a solvable issue
… first of all, it may happen that a webpage is part of two different publications, so yes, depending on how you accessed the page, it may look different, as it may be accessed as part of a different publication
… i’m not sure we should prescribe how this should be handled
… there is also a link consistency problem
… i’m worried about getting into that same problem

Hadrien Gardeur: dauwhe is right that we don’t have anything in the draft about how these resources are fetched… brings up these questions about browsing context and reading orders
… that said, the WAM also doesn’t solve the problem of a chapter and its browsing context
… you’re not forced to have a link to the manifest in every chapter
… and this is true in WAM as well
… we do need something to describe how resources are fetched, but the problem, as described by dauwhe, is not solved

Benjamin Young: they’re not related at all; the WAM does not describe a web app, it just creates an icon and channel for access to the web app
… you can build the web app without a manifest at all, but it does need to provision the entire experience
… publishers would ultimately have to provide a reading experience if we were to just extend WAM
… we can iterate on WAM and provide new things, if browsers are on board with supporting collections, reading order, etc…
… WAM doesn’t solve this

Dave Cramer: WAM does describe deep linking, so if you navigate to within a scope within a web app, the manifest will apply

Dave Cramer:

Hadrien Gardeur: yeah but that’s not discovery

Tzviya Siegman: we should avoid repeating old meetings
… we do have a few other items on the agenda
… garth, ok to leave packaging for next week?

Garth Conboy: Yes

3. FPWD outreach

Tzviya Siegman: we started asking for feedback on FPWD, but we need more input
… dauwhe has friends in the CSS community
… I’ll be in contact with TAG and Web Platforms
… would be good to reach out to others, like Kindle, etc. Kobo…

Ivan Herman: it’s a little bit more than feedback; it would be very important to have people from, say, the Edge team, coming in and looking at, e.g., Hadrien’s draft, and joining the working group and collaborating on it
… please bring in any contacts you may have
… they’re probably already W3C members

Ben Dugas: I’d be happy to pull someone in here at Kobo to share some feedback - can someone send me an email with some bullets specifically with what sort of feedback were looking for?

Garth Conboy: yes, I will reach out to Edge folks

Ivan Herman: it would be good to have a contact at Apple

Ben Dugas: thanks!

4. AOB

Hadrien Gardeur: I know we pushed packaging, but something that’s also relevant… the Google AMP team published a blog post on their future use of web packages on Chrome…
… we used to think it was far off in the future, but it looks like the Chrome team will use it soon
… this is unexpected, and is moving quicker than I thought

Garth Conboy: Intent to implement:!topic/blink-dev/n7cZXSTwBTY

Hadrien Gardeur: there’s a conference coming up, but there might be additional info presented there

Tzviya Siegman: garth, any news on that?

Baldur Bjarnason: AMP’s announcement

Garth Conboy: no, but I just posted the intent to implement from Google

Tzviya Siegman: any news anyone has on this would be useful, in case any of us are attending meetings pertaining to this
… also need outreach to Chrome team, maybe duga can do that?

Garth Conboy: yes, probably, and maybe we can discuss that on Wednesday

Dave Cramer: “WebPackaging opens up various compelling use cases, including offline peer-to-peer webapp sharing, web publications, and integrity-preserving distribution of content from non-authoritative server. “

Tzviya Siegman: anyone else have any other contacts?

Hadrien Gardeur: there’s also the news that Apple is implementing support for service workers in Safari

Ivan Herman: yes, I think it’s already on Safari dev branch

Tzviya Siegman: just a reminder that we have a newbies call on Tuesday next week
… but I need to double check

Laura Brady: Invitation says January 30th at 2pm

Mateus Teixeira: (invite was sent for Wednesday)

Tzviya Siegman: Tuesday, Jan 30th, at 2pm Eastern is the actual time

Mateus Teixeira: thanks all!

5. Resolutions