Digital Publishing Interest Group Teleconference

30 Mar 2015


See also: IRC log


Charles LaPierre (clapierre), Tzviya Siegman (Tzviya), Karen Myers (Karen_Myers), Nick Ruffilo (NickRuffilo), Ivan Herman (Ivan), Paul Belfanti (pbelfanti), Thierry Michel (tmichel), Dave Cramer (dauwhe), Brady Duga (duga), Phil Madans (philm), Ayla Stein (Ayla_Stein), Michael Miller (AH_Miller), Peter Krautzberger (pkra), Matt Garrish (mgarrish), Rego Casasnovas (rego).

Tim Cole,  Julie Morris, Liza Daly, Alan Stearns, Ben De Meester, Vlad Levantovsky, Markus Gylling (Markus).
Tzviya Siegman
Nick Ruffilo


<trackbot> Date: 30 March 2015

<ivan> Scribe: Nick

i am here, will scribe/call in 5 minutes, finishing up something

<tzviya> minutes http://www.w3.org/2015/03/23-dpub-minutes.html

Tzviya: "Minutes from last week: please comment/review"
... "Minutes approved"


<tzviya> https://rawgit.com/w3c/aria/master/aria/dpub.html

Tzviya: "Matt Garish - please walk through the not-yet-working draft of ARIA dpub module"

Matt: "The big change is that we've gone through and been tightening up some of the definitions and making them more broad. They were book-centric, but take for granted that people had a book/publishing background, so we cleaned that up."
...: "Make things more broadly understood and for a web audience. Revisited a meaning of the different definitions. Made some minor adjustments to names to remove hyphens, as those may be used for prefixes/namespaces"
... "We also started dropping very domain-specific roles. Assessments terms in the original submission are now removed - they will be handled in another group in the future. Likewise it was noted that without those in there, we'll look to take out others that are too domain specific. Removal doesn't mean they aren't in future plans, but we want to approach the vocab in more holistic terms."

...: "There are a number of terms that are 'gone' for this original draft, but they aren't forgotten."
... "General structures that are useful in broad ways. Landmarks from epub-now was a roadmap into the document - glossary or index. Aria itself has landmarks which are major structures. Allows users to jump to different sections. Rather than doing something fast-and-simple we've decided to just remove it so that we can figure out what is the best way to solve the issue of landmarks without conflict/confusion with ARIA."

...: "Still a few issues in the ARIA module, glossterm? possibly not necessary as it's covered elsewhere. Some generic naming issue with things like 'help' or 'part' might mean many things to many people, so we're looking for a better term."
... "Subtitle/title we're still looking for a way to help people and use those best. Referrer is the link back from the content/footnote. Referrer isn't exactly the best thing to call it, so we're changing the name to locator. These things are still up for discussion/debate. Ultimately if you can go through the terms/definitions, but if you want to be thorough, please go through the role descriptions and characteristics. Take a look at the super-class roles."

...: "There's another: Required Owned Elements, and Required Context Roles - used in Bibliographies and glossaries. The semantics noted have to occur. Required context role means that an item must have a parent. Glossary must always have a term, but a term may not be part of a glossary...""
... "Final to look at is the 'Name from' field. Author or content. Means that the author has created a label. You're creating it yourself through an ARIA role. if it's content then it's actually picking up the text-node of the element. A link can use the text of the link, but by-and-large you don't want the entire contents to be picked up - for example, an entire chapter."

Tzviya: "first draft mid-april. if you have comments, reach out. Issues are meant to be commented on and the issues need to be resolved."
...: "Feedback VERY welcomed. Looking at the spec might be confusing if you are not familiar with the ARIA docs. if you have questions, please reach out."

Bill: "Part issue - You want to get rid of that work. People think a part is a subset of something, but for books, part is a container. So there is a definition conflict."

Matt: "Correct - that's what we're working on."

Bill: "I think we should not use part. We should have a less-ambiguous term that is a 'group' of chapters"

Matt: "Is there a generic ARIA concept for a wrapper?"

Tzviya: "We can achieve that through HTML."

Bill: "You have to worry about the semantics of the sections. For example units in textbooks"

Ivan: "Many readers of the documents will be people who don't know the details of ARIA or what it stands for ( should go to publishers who may not know). Explanations or examples to make clear what the usage of the various of the aria- attributes : why are they there, would be very important."

<clapierre> +1 for examples for Publishers
...: "It's more a presentation issue. At the moment the document is very abstract and I miss this gentle introduction for those who are not familiar to accessibility or ARIA"
... "Human readable documentation would improve things alot."
... "Second question: if I look at the end/appendix. it talks about XHTML+ARIA DTD and open HTML. HTML 4.1... What happens with HTML5? "

Tzviya: "Some of this is written by us, some is generated by PF-Magic. It was generally agreed upon that the PF-magic stuff needs to be worked on. "

Ivan: "Until that is properly fix, something in the document should be added about HTML5 - such as 'HTML5 is coming' if you look at this now, you'll get a huge rejection of people who are against XHTML, etc."

Matt: "It was picked up from ARIA 1.1, so it needs to be brought up with them, so we don't fall out of line."

<tzviya> https://github.com/w3c/aria/blob/master/aria/dpub.html

Ivan: "To have something that puts ARIA clearly into the domain of HTML5 - that is a great thing. We also need to ensure all our documents are adapted to HTML5

Tzviya: "There was an update and there was an announcement that they want to release ARIA into HTML5"

karen: "Wanted to build on Ivan's comments - we don't want to educate EVERYONE about accessibility, but if there were a couple of points - from different perspectives on the importance of accessibility. Being able to point out some business cases/value proposition that show support for accessibility. Put in the Kudos there for everyone who is committed to this."

Tzviya: "Charles - this overlaps with some of the other work we're doing in other groups. I'll send an e-mail and copy Matt."

Karen: "i'm happy to talk with charles further about that."

Ivan: "Another editorial/presentation issue: Something in this document should be said about how these things relate to the current epub-column-type usage, in longterm and the work done in edupub. To relate this to existing work that is going on. Don't want people to be completely worried about what's going on here."

<tzviya> http://www.w3.org/TR/role-attribute/

Bill: "Is the role attribute confined by what is being defined by ARIA, or if a publication can use arbitrary terms within the role attribute. Obviously if we unplug epub type to the role attribute."

Tzviya: "ARIA roles are not the only allowed value for roles."

Matt: "Semantics in roles, if they aren't understood, it will default to its' base."

Bill: "I don't think i'm the only one with that question. Pearson and O'Reilly debated where to put this information. They ended up putting things in 'class' when they could have done it in 'role'."

Matt: "You'd want to make sure that you prefix things so that they don't get picked up or confused."

Bill: "So, even if you're using role, you'd want to prefix it."

Packaging use cases

<tzviya> http://www.w3.org/dpub/IG/wiki/UseCase_Directory#Packaging_and_Distribution

Tzviya: "Started to put together some use cases for packaging. All the cases don't address the basics but they are packaging requirements required to workflow. Requirements of publishing a journal with a dataset; annotations (which borders on having an annotations requirement) and how peer-review will factor into the publication itself. Share resources - such as CSS files - the publication should be able to tap into those shared-resources and make the streamed download process. If a package contains 12 abstracts, the user should be able to access just the abstracts. In downloading a package, it would be great if the user/agent would recognize what is new content VS existing content, which makes offline reading possible."

...: "I think Matt is planning on adding more basic use-cases for packaging. If you can add additional packaging use-cases, we'll be happy to review them."

Ivan: "What is the roadmap with these use-cases? I think the idea would be that we have to see whether these use-cases make it into the use-case collection that Yves was talking about a few weeks ago on packaging."

Tzviya: "When we have more use-cases we'll share them with Yves and go from there."

Ivan: "So we should share these use-cases on the list and have discussion."

<tzviya> nickRuffilo: is a DRM use case allowed?

<tzviya> tzviya: i think it would be OK to explain that allowing a hook for encryption is a good use case

Bill: "I'm on a campaign to discuss Rights Metadata within the package. Publishers need to be able to denote rights to specific items within a package. So the big question - how do we associate rights with different components of the package, and how do we get publishers to specify that information."
... "For example - photo metadata could be provided in different items within

Charles: "A couple things - under accessibility use cases (which is great) what about discoverability using metadata? Then a few questions on personalization."

Tzviya: "Accessibility use-cases have been up for a while, but you're welcome to update/add at any time."

Ivan: "The technology that shall not be named/mentioned - it is a use-case that we need to think about and compare with what the technology is. That said, and my impression is - if I look at the current packaging specification, or if I look at this; it is not an issue in the sense that it is a technical problem. Adding a part that is the right metadata is a key description of the encryption of the content. All of these things are fairly trivially doable within the packaging. They are use-cases that can possibly be fulfilled by the current packaging. I don't think the goal is to encrypt the package itself, just parts of it. The current spec allows you to do that, as you can add any binary data in any format or any media type"

bill: "Sounds like I was conflating two issue - Rights & access information. The other is the actual encryption. we already have font-obfuscation."

Tzviya: "Fonts are a big issue that we may have to look at"

<tzviya> http://www.idpf.org/epub/previews/

NYC f2f reminder

tzviya: "Reminder - NYC Face-to-face, please add if you are going

<tzviya> http://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_Details
...: "If there are any specific topics that you'd like to discuss, please let us know and comment there so we can prepare."

Tzviya: "next week is a European holiday, so no meeting. We will resume on April 13

April 13th, 2015 to be verbose

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/03/31 07:44:40 $