See also: IRC log
<ivan> Agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2017Feb/0023.html
<scribe> scribenick: nickruffilo
Garth: "Any objections or corrections to the minutes? OK - Approved."
group."
...: "Ivan can talk about the business group update."
Ivan: "The really important part is that the business group has been started. People (institutions) can sign up for the group. I don't believe the chair has been assigned, but there are a few people who have said they would be happy to do it. Face to face meeting is set up for March 13th in London. It's 3-4 hour meeting. I'll be dialing in. Last but not least, I think that the official
announcement should go out to the AC people today (well US time today). That announcement will contain the official advanced notice of the charter."
Garth: "I would like to add... The first meeting will be on the 13th at 1 London Bridge (the news building) at the Harper Collins offices. And the initial 3 co-chairs of the group would be Paul Belfanti, Rick Johnson, and Christina Mussinelli"
Leonard: "I wanted a quick clarification - you said the official advanced notice of the charter. Is that the working group? or the business group."
Ivan: "The business group is already there. This is just an advanced notice, telling the AC, that we're working on it."
garth: "Any comments? Now is the time. "
Deborah: "We met, had a long meeting, we feel strongly that we think it would be good for their to be. We hope strongly that it ends up a digital publishing working group that is creating req-track documents as it feels it would be valuable for digital publishing documents. If there is a Digital publishing group, then there can be normative tracking. These may or may not be requirements that
get added to WCAG. They may or may not have some kind of pipeline attached to them, but if there are req-track documents in DPUB, that is a place where accessibility documents can exist. We've had alot of back and forth as to how we wish to phrase this in the draft charter."
<ivan> https://rawgit.com/w3c/dpubwg-charter/a11y-core/index.html
...: "Ivan created a branch where we've been doing lots of work."
Garth: "Ok, awesome."
<ivan> https://github.com/w3c/dpubwg-charter/compare/a11y-core
Avneesh: "For the text part, deborah as described it well. We are waiting for all the feedback before we put it forward. On a conceptual level, there are two parts. We talked about existing specifications. One part for the specs is to remain in the same state, the second as part of development is straightforward, but the question is where it will happen - a community group, or a different
profile (WCAG?). The requirements and DPUB accessibility note, they get transformed into the working group. It would be relevant to WP/EPUB4. While, what do we have to do with path 1, to solve the epub 3.1 requirements. So maybe Ivan can shed some light how we should proceed."
<ivan> https://rawgit.com/w3c/dpubwg-charter/a11y-core/index.html
<ivan> https://github.com/w3c/dpubwg-charter/compare/a11y-core
Ivan: "First of all, I put two pointers into IRC. As deborah said, I put in a separate branch, it's under discussion in the group. It's information only, there is not even a pull request. The second gives the difference. That is where we are with the core. As for where to do a separate and whether to do a separate document, which would be adjunct to WCAG, for me this is absolutely open, and we discussed it last week. There are some fears that if it's left to WCAG it will take a long time. In the meantime there is discussion in the community group whether some of that work should be done in the community group, but whatever happens in the community group it is standard, but it has to go through a working group. "
leondard: "I like most of the directions of the revised document. We've already previously called out that there would be work on accessibility focused documents. That is very clear, and we want to make that more visible. I remain concerned about some wording issues - the one item around "web publications and accessibility" I thought we resolved the language, yet was dismayed to see the rewording again. "
Ivan: "Clarification - you mean the rewording in a separate branch?"
Leonard: "Yes, your branch re-write completely rewrote the paragraph about all of us agreeing on it. I think you can take some of it and put it in a separate thing, but I think it's inappropriate to re-write it."
Garth: "Yes, It would be ideal as an issue."
<Avneesh> It is not even approved by accessibility TF, so let's wait
Ivan: "One last thing, leonard, I think it's too early to put into an issue yet, as the point is, what happened there, is that the accessibility task force came up with text that was in the air. What I did this morning I tried to say: "if this is the text, how would it look like" and I think Deborah and company have not seen this text. So before they see it, lets not go into issues yet."
Deborah: "That is what I was going to say. The accessibility group have bounced around text that we wanted included somewhere in the charter. This is early-alpha. Text we wanted somewhere that contains statements about how accessibility would be part of the working group, which is what ivan had asked for. And this is just where it was put. We were using it to make people aware of it."
<leonardr> I'll work with Ivan offline...
Garth: "It's not ideal as an issue, but it needs to be part of the track."
Garth: "There was a discussion about the leading 'must' be online. Should it be a must or a should. A must only in a packaged form. Leonard?"
Leonard: "I think part of the issue goes towards the desire of the author of the publication gets more control (or the receiver) gets more control. I always believe the author should have more control. To me, if a web publication is available offline, is the decision of the author. So the decision if it is usable at all, it is up to the author. It might not be a good web publication, but it's up to the author. Granted, we shouldn't be strong in our view that it's bad. We want people to have a seemless experience. "
Dave: "I'm going to argue for must, as I believe the reader's desire can trump the author's desire. If you want something that's unavailable offline, don't do a web publication. It's a minimal functional that is essential towards what we are aiming for. "
<dkaplan3> dauwhe++
Garth: "The offlineness is important to being a publication."
Ivan: "Really really should sounds good to me, but isn't formal."
<dkaplan3> like plaintext is automatically accessible, but you're not stopped from having the entire text of your book being an image of text.
Nick: "If someone want to make a document that isn't offline-able, they should be able to, it's the authors choice, but default should be that it can be offline."
Ivan: "We don't want to define everything on the web. Where we draw lines is important. The way we have to formalize it is tricky. The way we need to understand it. For example, if it's offline and provides the same experience as offline, that's too much to ask. The better description is that it must provide a reasonable fallback when it is offline. So if one of those 'flash is not running properly' it should not stop the publication - just do something reasonable instead. I'm not sure how I would formulate that."
<Garth> "A Web Publication SHOULD be available and functional while the user is offline. A Packaged Web Publication MUST be available and functional while the user is offline. A user should, as much as possible, have a seamless experience of interacting with a Web Publication regardless of their network connection. We make no distinction between online and offline when defining web publications."
Garth: "The package would be the thing that would be passed around offline, so I'm attached to a must in that world, but ..."
Leonard: "I think your change muddies the waters much more. Obviously it's going to come to wording. We all believe the same thing - we want to make strong things about what we expect, best practices. Right now, it's a high level. We should put the details in the details. What Ivan said is great details, but at a high level, lets talk about SHOULDS. They are important recommendations, not a requirements. Then we can worry about fallbacks."
Garth: "I somewhat agree. What I put together is more appropriate for the actual spec and not the charter. These decisions could be deferred. "
Ivan: "In a way, we have to be very careful here. We are discussing the text of the PWP draft, which is not the specification. This text should be synchronized with what's in the charter, which is still just the outline of where we want to go. In the PWP draft, I would think that, being more verbose to explain what we really want here might be the proper way. As Leonard said, we all want the same thing, but we need to be a bit more verbose. In the charter, we have to be more terse. So maybe that is our way out. How we put that in spec language, well we'll cross the bridge when we get there."
Garth: "When you say 'that's where we are now, what are you agreeing/disagreeing with?"
Ivan: "In the PWP document, instead of being terse and arguing Should/Must, we should just make it more clear as to what we expect from online and offline. 'really really should' as this is the intention of the work and what we want to achieve. Even in the charter we can leave it open. "
Dave: "This PWP document is our statement of vision and intent, so I certainly am fine with what Ivan said that there are some things that are not naturally going to be equivalent. As our intention, we want to make it as strong as possible, so we want to be as verbose as possible. I also don't want to leave lots of wiggle room."
<leonardr> I am happy to come up with something if you want...
Garth: "Ivan, are you happy with trying to find better language?"
Ivan: "I trust Dave or Leonard, as they are natively english, and I need a better grasph."
Dave: "Leonard and I can wrestle this out."
Garth: "ACTION ITEM!"
Garth: "The next issue - the origin-trust
issue, seems to have been solved. Or am I crazy?"
... "The trust isn't there any longer, and neither is the origin stuff,
as far as I could tell."
Leonard: "I do agree, I think we're OK. -- Ok, wait, Paragraph 4. under 1.1 - what is a web publication, still says. I think I can clean that up, and I'll submit a proposal for that as well."
Garth: "Ok, it's been nearly cleaned up, but if you clean that up we'll be good."
Leonard: "I think. The reason I see them as separate, is that when we talk about constituent resources... In epub, the manifest only talks about the individual HTML files, what are the chapters in the book. Sure, talking about their sequence and their presentation, but in the context of a web presentation, constituent resources is an important thing. The fact that we're going to have the mona lisa image that will be in the manifest, but it has nothing to do with sequence. So it's about having constiutent resources. "
Garth: "It comes down to what is meant by manifest, and a spine that has a reading order. If we take a look at the OPF (which may or may not be relevant) I don't think there is very much presentation stuff. Clearly we need to have a way to know about the constituent resources are. But somewhere we need to talk about order."
Nick: "I see a manifest hosting some metadata about constituent elements."
Dave: "There is a large class of information that might need to be part of an abstract manifest. Saying 'constituent resources' isn't specific enough. Saying we need constituent resources and sequencing doesn't mean all of them are sequenced. This might be an issue that manifest is a loaded word, but it's worth noting there will be more categories of information here."
<ivan> "We also introduce the abstract concept of a manifest, which serves to carry information about the constituent resources of the publication, such as their sequence, and presentation."
Ivan: "In line of what dave said, it's not simply a matter that sequence and presentation are just examples of various information that must be somewhere. For the time being, we're calling it a manifest. If I say 'such as'. Leonard is right, the mona lisa is not part of a sequence. But we want to provide an example of the information that must be stored somewhere. "
<leonardr> ..publication. It may also carry information about their sequence and presentation.
Leonard: "I'm putting together my own, same idea, but different text, give me a moment, and I'll paste it in. If we end the 3rd sentence and add (pasted above)"
Ivan: "same idea as mine, different language."
Garth: "I'm happy with both."
Dave: "I'm happy."
<leonardr> Will do!
Garth: "Ok, lets put that in the same set of
changes that you're looking for. "
... "OK, that is the end of the agenda. Ivan and I will get together
Wednesday and look for topics next week. If we come up empty handed, we
will let you know. If I could again, encourage folks that if there are
agenda items, please submit them (email) and we'll get it on the agenda.
If there isn't other business, you can have 14 minutes."
Ivan: "One question I would like to ask is - when do you think we can produce the next draft of these two documents? The reason I would like to do that, if possible, is because now the draft charter is out there. Even if the reference goes to the editors draft, whats on the official pages are hopelessly out of date. Putting the drafts of the UCR and this one, that would be good.
Garth: "I think we've dealt with the remaining open issues in the PWP document (not to imply there isn't more). The accessibility is focused on the charter, but it sounds like after these changes, we could probably publish that... Maybe the UCR document is OK as we haven't discussed it in a while. I don't think too much is out there..."
Leonard: "I'll talk on this, but I think we're ready to go with the changes Dave and I will get to. Within the next week, we can finalize it next week then publish."
Garth: "Sounds good. Some of these changes will wander into the charter. The work of the accessibility group is going in that direction too. we should publish an updated draft of the charter as well. Certainly the PWP, but I would hope you can..."
Leondard: "I was hoping we could finalize the Face to face kickoff. Maybe over the next week. Do we have a final date? Do we need one?
Garth: "Probably not in the next minute, but I agree nailing it in the next week. There has been some discussion at the W3C with what's going on with the travel restrictions if being in the US is a feature or a bug. Now it's off, but who knows what it will be next week. I have a slight preference for NY, as it could allow Tzviya to participate. If we were to host at Adobe, as Leonard has offered, that usually corporate facilities usually ahve good remote participation. Which would be good from a dollars and travel related thing. There has been a discussion of doing it directly before or after BEA, which makes sense to me, and would bring some of our constituency to NY as well. Maybe we'll get that on the agenda for next week and nail down both dates."
Ivan: "there was one restriction that there are some Jewish holidays that exclude certain holidays. The Monday after BEA that we finalized because it was OK for everyone, leonard, is that OK?"
Leondard: "For those reasons, I suggested the 5th and 6th of June. Going after BEA isn't bad, as it runs through Saturday, and sometimes Sunday. "
Garth: "May 31st - June 2nd. So after BEA makes sense, as we have memorial day preceding BEA... If we're going to do NY, it makes sense from a memorial day and Jewish holiday."
Ivan: "The other problem is that I need to get the authorization (me going) because at the moment, with the finances that we have, having two face-to-face meetings for me in the US will be a challenge. The other is at TPAC."
Garth: "There is no move to move TPAC from the bay area..."
Ivan: "It would be expensive."
Leonard: "To go along with that, do you want to send out an email with the proposal? "
<ivan> --- adjourned