W3C

Digital Publishing Interest Group Teleconference

30 Jan 2017

Agenda

See also: IRC log

Attendees

Present
Ivan Herman, Avneesh Singh, Chris Maden, Daniel Weck, Garth Conboy, Laurent Le Meur, Dave Cramer (dauwhe), Luc Audrain (laudrain(, Karen Myers, Charles LaPierre (clapierre), Deborah Kaplan, Peter Krautzberger, Hadrien Gandeur, Nick Ruffilo, Leonard Rosenthol, Bill Kasdorff, Heather Flanagan, Rick Johson, Bert Bos, Dave Stroup, Benjamin Young, Liam Quin
Regrets
Vlad, Alan
Chair
Garth
Scribe
nickruffilo

Contents

  1. IDPF/W3C combination news
  2. PWP Issues - Definition of a (P)WP
  3. PWP Issues - Relationship to accessibility

<ivan> Agenda call 2017-01-30: http://www.w3.org/mid/CADExNBP44PO-2nuq0+LCEjZibWFn7e4DvZjJ2P-OWBtpz3ktwQ@mail.gmail.com


Garth: "Minutes approval?"
... "Ok, minutes approved."

IDPF/W3C combination news

Garth: "Update on IDPF merger - same as last week. Should be signed/PR very shortly. All the wheels turning in the right direction. Official news hopefully this week."

Karen: "I would like to encourage everyone those companies - particularly the members, who would like provide testimonials. We would like to add those to the testimonials, that would be great. We would like to put them in our testimonials. It will be translated into multiple langauges, so you can get quotes in whatever language works for you."

<Karen> http://www.w3.org/2004/12/testimonial_pr-guidelines.html

Garth: "We need testimonials from others - especially those outside of the main group."

PWP Issues - Definition of a (P)WP

<garth> http://w3c.github.io/dpub-pwp/
...: "As far as agenda, the only thing I had of substance is that I took the email that Leonard sent and tried to pull the issues/trace through the thread for discussion. There were two musts that could be turned into shoulds. I'll paste the link into IRC. "
... "Most recent update is pasted in the link. Leonard, feel free to chime in, as I've paraphrased your email to get it to agenda size. The first is the definition of a web publication. The current text is a 'bounded collection...' The issue raised in email, is that we do we really want this? Combining existing documents? Annotations - is that created as a whole."
... "What a 'bounded collection' is - so what is a bounded. My response is that it was gathered by a manifest. So there was a note about if we needed or liked bounded. Leonard, did I summarize that?"

Leonard: "Well said. Thanks."

Garth: "In the email thread, there was an alternate - or slight change proposed. It was added that the bounding was about having envisioned as a whole."

Ivan: "I was the one with the alternative. I have the impression that the problem that Leonard had was related to the fact that the individual resources that you put into the collection, they may or may not be envisaged. So you can have a collection in the general sense, which is perfectly fine. I have a feeling the original sentence itself was misunderstood that, as a whole, the curation part referred to the collection and not the individual resources. And that was his problem, which I agree with. That's why I proposed a slight modification, which made that point clearer."

<HeatherF> +1

Leonard: "Someone else, in the thread, pointed out that there is a 2nd definition in the terminology section, which means we have two separate definitions of the same thing. So we should probably use one and repeat it later. I support that idea."

Dave: "As the author of the problematic statement, the intent is that - the constiuent collection may come about from alternate sources. The ultimate goal is to distinguish it from 'the web as a whole.' Is gmail a publication? No. Is the NY Times website a publication? No.... We need to draw a line so we need to get buy-in from the web community. The closer we come to saying: 'this is just web stuff' the motivations seem to evaporate."

Nick: "What if we go from specific and then make more general..."

Garth: "The 1.3 for terminology. A collection of 1 or more constituent resources... Presented using standard open-web technology."

Leonard: "I prefer the one in terminology - it's the one we all agreed upon in Lisbon. it's better and much more general. On the topic of what Dave and Nick had - it gave more latitude. I don't agree with the direction - the choice of if something is a publication is up to the author - and whether the author wishes to make it a publication."

Luc: "I would like to emphasis what Ivan said a few minutes ago. In this definition, things that are created as a whole. The publication means that we have something as we share as an author. The resources might be created as part of that vision, or an old document. What is really whole? What is really meant with a publication is the collection. The fact means that there is a time to publication - there is a moment where the collection is complete and answers the vision of the author. What is missing in this definition is that the resources are created and visioned at home."

Garth: "In the terminology section, does the definition work for you?"

Luc: "I've seen that too, and it works."

<garth> 1.3: A Web Publication (WP) is a collection of one or more constituent resources, organized together in a uniquely identifiable grouping, and presented using standard Open Web Platform technologies.

Nick: " The full definition has been pasted above - lets discuss it and break it into the master definition."

<Bill_Kasdorf> +1

<laudrain> constituent ?

Leonard: "constituent resources are the resources that make it up."

Ivan: "The difference between related and constituent - the fact of constituent is that it refers back to the collection. The resources that make up the collection."

Dave: "Constituents are parts of a whole."

<Bill_Kasdorf> Ivan's right about "constituent" vs. "related." There can be related resources that aren't constituent.

Dave: "My concern is that if we don't have all the technology needed - really the constituent items are all web technologies, but we may need additional work for the publication as a whole."

+1

<Hadrien> and we don't need the resources to be related directly to one another

<garth> How about: 1.3: A Web Publication (WP) is a collection of one or more constituent resources, organized together in a uniquely identifiable grouping, and may be presented using standard Open Web Platform technologies.

<ivan> +1 to leonard

<laudrain> +1

Leonard: "The reason we phrased the piece at the end was to make it clear that the content is made visible to the user through the use of standard open web technologies. The implication here is that you're not going to render it as a PDF, or a TIFF. That's not the open web. OK - It's HTML, CSS, SVG, and that's how the content is going to be presented. It's not the user-agent. We didn't want to say the resources were open web, is that it could allow the author to add proprietary content - such as XML, CSV, or some binary format, that gets translated for presentation using the open web. It didn't matter the resource but how it was presented."

Garth: "I agree. I posted a 'may be' in there. "

Luc: "I see the last of the phrase something that 'will rely on standard' I understand the difference between what you're saying. If I follow Leonard, i understand that there may be a proprietary format within a publication, and it might be presented using open web. Is that what you had in mind?"

Leonard: "XML was a bad example, but a 3D-formated (3JS) items, I might want to have the original binary, but I'll present it using 3JS."

Garth: "Even a simpler version is a dataset, that isn't necessarily formatted in an open web platform technology."

Luc: "What if I massively proprietary resources, and am using proprietary techniques to bring it to a user-agent. Do we open here something that could allow completely closed systems?"

Leondard: "I may be a dissenting opinion - but if someone wants to use the technology to put together a closed workflow - where it's their workflow start to finish, but it is technically a web publication, i don't care. If they're still using web publication, that's a win."

Garth: "When we finally have a proposal, at least the root of the publication must be an HTML file..."

<Bill_Kasdorf> Let's not forget accessibility

Leonard: "It doesn't matter what the root it - it matters how it is presented. What you start with doesn't matter, which is why I like that. Your resources can be whatever you want, but the user agent is presenting standard web content in a standard wya."

<garth> 1.3: A Web Publication (WP) is a collection of one or more constituent resources, organized together in a uniquely identifiable grouping, and may be presented using standard Open Web Platform technologies.

<ivan> +1

<dauwhe> +1

<leonardr> no MAY

<laudrain> +1

Leonard: "The reason we need to define web- publication is that we need to define packaged web publication. So we need to define the thing before we define the packaged.

Garth: "The reason I like the may in there, is that if the web publication is never rendered - it can still be a web publication. And that's the reason for my 'may'."

<leonardr> isn't consensus by definition everyone being equally unhappy?? :)

Deborah: "I am happy with the definition in the text, but we've gone round-and-round about definition publication, oh wait, we can't... We should do our best to define publication, but it is impossible to define web publication. We need to make a definition that is as inclusive as possible - but lets stop worrying about it. it's possible, so we just need to do the best we can and acknowledge some things might do too much."

<clapierre1> +1 on the definition.

<Zakim> ivan, you wanted to not really agree with leonard

Ivan: "To give more argument to what's there. I don't fully agree with Leonard - that the only reason for the definition is so we can define what it means to package it. There is an important concept there to speak about this collection as an entity that has it's own identifier, which has it's own X-Y- and Zed. It has a bunch of webpages and a collection of technology. I think there is more than that there and I want to come back to what dave said at the beginnning. we have to justify why we are doing this, and that we're talking about is special. Deborah is rigth - it won't be perfect, but we have to start somewhere. Lets start with this, and put this into the document/charter and see how people react."

Garth: "Lets keep/use this new definition. Lets declare victory on this topic."
... "Ivan, do it and accept it!"

dave: "I'll do it!"

PWP Issues - Relationship to accessibility

Garth: "Ok, that was the first. The second... The question of a must or a may about mandating accessibility. Can we mandate it on a per-publication basis."

<Bill_Kasdorf> +1 to Ivan

<leonardr> @liam - yes, **ability* to be accessible, absolutely. But the question here is whether the publication itself **must** be accessible

Ivan: "It's not a strong oppinion, but a general feeling - when we are talking about web pages, and things we do on the web, accessibility is a very... strong should, but it's not a must for a webpage. Now, the point is that we have to be very careful not to put ourselves in a corner, that we are very different from the web - that we require something as a must, where everything is a should. I'm looking ahead where we - in general - talk about web publications, we included epub4 as one profile. We can say that - if we take the profile. What is only a should, becomes a must. I just want to be very careful about all this."

Nick: "How do we require a validator to yell about these things?"

Charles: "The IDPF just released the accessibility requirements. the epub is a 'should' for the accessibility, which has a whole bunch of musts. This is sort-of where something like epub verification. If we do something similar here, which doesn't preclude accessibility, but we make a huge case 'this is what should be done/must be done' It's a move to make sure accessibility is always in the forefront. Preventing having to fix something after-the-fact"

Luc: "We also have to figure out that there are some laws coming in place - the European accessibility act, it will be enforced in the future, but it will take several years. The enforcement of accessibility is about websites and ebooks. If our books, if we think about ebooks in the future, if we don't encourage or check that accessibility is present, there will be a measure of quality. These groups can create some constraints. And things that are conforming to this european regulations."

Dave: "Access to information is a fundamental right. We need to do everything we can. Have a must as much as possible. "

<clapierre1> +1 to Dave's comments!!!

<david_stroup> +1

<clapierre1> also important to note here that the 508 Refresh includes electronic documentation.

Deborah: "I think one of the problems is that we are talking about accessibility as if requiring - there is A, AA, AAA. Some things can't be required. We can't say: "you have to have meaningful alt-text" but that has to be done by a human - meaningful, not the presence.' We can say things that say you can't have controls that are only available by mouse. But we can demand things that require a PWP to have certain features, or cannot block certain features. As dave said, these documents are for all humans. There are basic things that we can make minimum standards. We can't blanket say 'this MUST be accessible' but we can say certain features are."

Garth: "The actual phrase is that 'a web publication must be accessible to the widest possible group of readers.'"

Leonard: "One thing that is getting muddied - which is that we're working on, and the charter is clear, that we're working on 2 different things. Web publications (and the packaging of them) and a completely separate standard that is currently called 'epub4' It's important we keep that in mind when we talk about these different definitions. Thats where the work of the IDPF/EPUB which is what we're planning on taking forward. I believe all of that work should be pushed forward in the epub work. At the same time, there is a completely separate piece of work that, i believe, will be used in a bunch of ways that epub was designed for. Because we don't know how all these other use-cases will exists. The web itself doesn't mandated it, so there is a reason. We should have separate where EPUB sits as a layer on top."

<Zakim> ivan, you wanted to differentiate between technical must and legal must

<HeatherF> RFC 2119 ftw!

Ivan: "We have to be very careful when talking about standards. MUST and SHOULD have a very specific meaning - more than what the English term is used for. There is a different saying 'whatever technology we develop must have features that make it accessible, then I am absolutely fine with it. This is not something that is a W3C general approach, which is why we will have accessibility review. In the same way, we would have review of internationalization. Everything needs to be internationalizationable - the same way it has to be accessible. A PWP must be accessibility, is something we simply cannot say as it's not technically checkable in practice, so in a standards sense, it is not a meaningful statement. The origianl sentence should say that it must be possible to make it acccessible. We have to be careful what we require."

<liam> [ epub X MUST NOT specify anything that would preclude accessibility of conforming documents ] ?

Garth: "Can you formulate a regraph of that sentence that gets to that place?"

<Zakim> liam, you wanted to say a11y isn't optional for HTML documents, but is impossible today to test for reliably. +1 to MUST

<HeatherF> Need to drop off - good conversation, everyone!

Liam: "If you say anything about accessibility not being required. Accessibility is not optional for HTML, but what was noted - it's nearly impossible to test for it. What we have to worry about is people using the scope and the interest of the spec. We need to make sure we don't do anything to prevent things from being accessible. The question is how strongly we request people to make things accessible."

<dauwhe> +1,000,000,000,000,000,000,000,000,000

<leonardr> that's fine - I'm happy to keep fighting for my side too :)

Deborah: "I think liam and ivan broke it down clearly. Must is vague and not fully meaningful. I can disagree with Leonards note that we can't require because we don't know what people will do with. And, even then, we have to accept that there are limits in the definition, especially the extent we can require, but is absolutely a requirement. Must be built with technologies that allow for accessibility"

Garth: "The publication must be made to be accessible."

<leonardr> and I FULLY support statements like "Must be built with technologies that allow for accessibility"

<dkaplan3> What Nick said, except even stronger: "Must be built with technologies that allow for accessibility for every element of the publication."

<leonardr> or even "must be able to be made accessible"...

Garth: "We should continue this discussion and fine-tuning on the email list."

Ivan: "What I will try to do is to make a separate branch and modification of the text - so there will be a constant push towards getting things complete. I'll make it in Github so we can have be useful."

Garth: "We
... "We'll pick up next week."

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/01/31 09:56:24 $