See also: IRC log
<NickRuffilo> scribenick: NickRuffilo
<Bill_Kasdorf> What a pleasure to hear Markus's voice!
Markus: "We will discuss the PWP document updates, then a timeline for the document. First, to begin with, as per the agenda, the next 2 meets are canceled - due to holidays or no chairs available (guess we can't sit down)"
...: "Speaking of chairs - the next announcement is that I'm stepping
down as chair. I've taken another job with another organization. I will
be working with IMS global. Tzviya will not be left alone. The W3C
Management have... agreed... Garth Convoy as co-chair of the interest
group. The transition is ongoing and both of us will be in Lisbon. I
expect the transition will be done just around Lisbon (another month)"
<Bill_Kasdorf> Good call to have Garth co-chair
Garth: "I'm sure after this transition, everyone will miss Markus, but I'll push things forward, and when the IDPF merger happens or doesn't - this group... What Markus said is great, we will miss you."
Markus: "What you will all notice is that Garth is an upgrade."
Ivan: "on the formal side, in today's
world - this will be tweeted and made public soon. The formal
transition, in the sense of W3C appointing Garth - this is something
that should be done soon. Formally speaking, it will happen this week,
but we don't let Markus go that easily, and we will have lots of
co-operation with him on things like TPAC. "
...: "I need a paragraph from Garth - as when we appoint a new person,
we tell the AC who that person is. Markus, I'm not sure how to formulate
it, but please let me know what we are authorized to say about where you
are going and what your position is."
Markus: "Updates to the UCR doc. Lets make sure to save 15 minutes to talk about the schedule. I asked ivan before we started here if tzviya's list is the best cherry picking the areas of change. Ivan - you think what we have here is good enough. Lets stay with the current ... Meaning that first we should look at the horizontal section. Deborah and Ivan are name dropped there. "
Ivan: "I'll start. This is the section I did. There is some discussion on the email thread. This is the 2nd version. I did what we agreed last week. I cherry picked and massaged some text that I found on the w3c side. I gave some usage examples. In those examples I covered ... the accessibility part was there. I added use cases on internationalization and privacy. Either something should go there or on security... a separate discussion right now, which may be more complicated - so we may just make a reference to a section that will come. Maybe or maybe a short 1-paragraph example can go there. "
...: "I would prefer to delegate that to Baldur as my knowledge isn't the best on this. Deborah, not sure if what is there is more or less what is there."
Deborah: "This is what I was envisioning when I put the sketch in there. This is a good comprehensive definition of the bits we care about, and the fact that some of these use-cases are content-creator based, and some of them are reader based. i think I actually want to add a couple more use-cases, but it's really good."
Ivan: "If you want to add some use-cases there, then put them."
Markus: "Questions or remarks?"
Boris: "Just chatting with Baldur - inserting it should be fine. We'll reach out to Ivan about the best way to do that."
Ivan: "The various things we discussed on the email list were way more than that. So we should take one of the simpler ones for this chapter here."
Markus: " The only question I had Ivan, the usage examples, these are bona fide use-cases? Even though this is an umbrella? We should probably number them."
Deborah: "One thing about the formatting. Should these use-cases be broken out to the different horizontal dependencies? Such as 'this is privacy'..."
Ivan: "Yes, that clarified. Because of the
nature of the section, this is hodge-podge."
... "we don't even have a separate internationalization section, or
privacy section - at least yet. The accessibility, there is a separate
section, there will be one on security, but not sure there will be one
for devices..."
Deborah: "Even if they stay in a bucket, we could have bolded words in each use case - right after the bullet."
<HeatherF> And, links within the doc to related sections?
Ivan: "Makes sense, I can do that."
Markus: "OK, we know what needs to be done. Baldur & boris producing a lighter-security related to go here with an additional section with the heavy stuff later. Ivan will note specific vertical for the use cases... Ok good, next."
<ivan> distribution, sharing
Bill K: "What was contributed was, then I turned it over, at which point more in-depth technical items were added. "
Bill: "The comment I can make - is wether
we should incorporate the collections section - see if we can get
comments first, then decide if it should be incorporated. I don't have
strong feelings either way."
... "There were a bunch of different use cases that were all about
accessing external resources - so we grouped them and put all the usage
examples into a single use case."
... "We have 4.4 and 4.5 might be useful to join."
... "We didn't really change much, but we added a usage example. What I
can say is that anyone who contributed, please review what we re-written
to ensure we captured the essence of what you put."
Bill K: "One thing we did change was that there were several usage examples about the reading system - such as keeping track of how many copies were sold. Just wanted to make sure people were aware."
<Bill_Kasdorf> That is, we took such RS-specific issues out of the usage examples.
Markus: "Moving on. State Locators - Ben, you sent an email about an hour ago. Thank you for that update. Want to take us through this stuff?"
<bjdmeest> http://w3c.github.io/dpub-pwp-ucr/#the-same-publication-in-multiple-states
<Bill_Kasdorf> I was not suggesting joining 4.4 and 4.5, I was suggesting swapping their sequence
<bjdmeest> http://w3c.github.io/dpub-pwp-ucr/#non--essential-content
Ben: "Let me fetch the link already. [link posted above] - Basically, what Leonard and I did was that we merged section 6 and 3. They were overlapping. Together with Ivan's comments, we moved some stuff around and put some stuff on the fundamental requirements. With 2.1.5 and 2.1.6, basically I added a use-case example there. Also in 2.1.13. The biggest changes were in section 3. You can read through it. Things got moved around and restructured. With 3.1.1 it's non-essential content. It is just a subsection pointing to the fundamental requirements. "
Markus: " The job is for everyone to read through this properly. For section 6.3 - one thing that strikes me on the overall structure of the document is that having state changing and state locators as chapter is may or may not be a good idea, as it is quite heavy. There could be a point for moving it later int he document as to not scare people away. You did choose this as 3 instead of 6..."
Ben: "We could say that 3 can go and 6 can stay, there was no master plan for that."
Markus: "Once we know we have the top-level done, we can know better about shuffling."
Ivan: "First of all - I think that putting this content into 6 would be good as it's more heavy and technical stuff. I think that's in a better place. You had a question about an almost-empty 3.1.1. I faced a similar problem when I did the manifest section. In that section I do say roughly what I mean and when there are use-cases that are already there, I then created an essentially empty section. It looks funny. actually that relates to my other problem as well. Although the introductory section will still change, but I think somewhere we should have a more precise notion of what we are talking about. We know what we mean about state, but the term here comes out of the blue, so we should have a more clear definition of what 'state' means. You can go to an older document that discusses what the different states are. You can then refer back to 2.1.13 about something we already address. I don't know how that sounds to you."
Ben: "Thinking about 3.1.2 will be uplifted?"
Ivan: "Then maybe we don't need subsections... I think that would be OK. A little easier to read."
Ven: "I could probably refer to a document - we had that defined somewhere."
Ivan: "We have it in the PWP draft. It would be better if we don't refer to the draft. The Draft should rely on the UCR, not the other way."
Markus: "Accessibility cleanup:"
<ivan> accessibility section
Charles: "We've been working on the use-cases. We're down to 5 different areas. Braille, a custom PWP, package needs to support time-based media and text. Deborah, I, tzviya, george... The only thing left is to discuss the braille examples, as she was concerned that they weren't just for this document but more generally useful for the web. Even though we have use cases why braille would be needed inside of a PWP - why is it a use-case for PWP and not just web in general?"
...: "What makes braille within a PWP differnet from braille on the web in general?"
Markus: " There are lots of people and organization that want to depend on the ability to do preformatted braille. It can be seen as a use case, but it is important enough for certain users - that if there isn't another open bucket, we should at least keep it here. And note that it is a generic concern. "
Charles: "Those were my thoughts as well."
Deborah: "Any more examples, please email"
Ivan: "A question on braille. There is
something i think is missing. Somehow the epub world and IDPF and epub
world - put in possible more stringent rules for accessibility than the
web - there is probably a general reason for that. There is a possibly a
greater reason where publishing needs stricter rules - for example
around braille. If that is so, I'd like to see those reason listed here
... Why is accessibility so present in the digital publisher world, even
more so than the standard web. "
<Bill_Kasdorf> the issues are both being sued and also procurement requirements--a book won't be acquired if it isn't accessible
Deborah: "This is - in response, it's awkward to talk about that. One response makes the web look bad. Many of the same legal requirements that make the epub/PWP world care more about accessibility - many of those apply equally to the web world, but because of the business sectors which care very much about epubs - tend to care more about being sued. It's difficult to put that in the document. Academea cares more about legal compliance' When it comes to putting out a publication - which isn't always clear - people in the news media tend to care more about legal compliance with the epub than the general web. And the epub lawsuits tend to go through more often than the web based ones."
<garth> I think it's more the nature or "ad hoc" content versus "publications"
<clapierre> +1 garth's comment
<Bill_Kasdorf> I would suggest a use case along the lines of "ABC Educational Publisher needs its publications to be accessible because universities and school systems will not acquire books that are not accessible.
Avneesh: "What Ivan says ties up to some technical reasons. The main difference between the web VS epub - dynamic VS static. When we talk about the PWP - the portability, the static documents, the preformatted braille. If there is something in the shape of tree, the braille should tie up. Braille is a type of publication."
George: "The PWP are normally products being sold. Websites that you go to are usually not. The proposed rule with the ADA is that the accessibility requirements for the web & published documents will get closer. We're getting closer to what will be required in the future."
Markus: "Can we write something that isn't politically hot."
Ivan: "I had the impression that what deborah said could be formulated noncontroversial. There's no reason to make a comparison to the web. What I heard about the stability of the publication which requires accessibility. The industry has faced legal action. Just stating that accessibility is important. I think it's possible to describe in a positive manor - as an introduction to section 8."
Markus: " Lets keep that in mind."
Nick: "There are laws requiring certain levels of accessibility - shouldn't that be enough of a reason?"
Markus: " Boris & Collections"
<ivan> http://w3c.github.io/dpub-pwp-ucr/#collections
Boris: "I don't have too much to update. I haven't made any changes in the past week. Not a big update - it's still in process. I added another section on annotation. I put them at the bottom of the document. As time permits I'll make it better."
Markus: "The annotations working group use-case document contains many things that cmae from us - so we should make sure that there are no duplication."
George: "Does accessibility group need to add anything to the use-case groups for annotations?"
Markus: "I'd need to check to see if the annotations group has existing use-cases, if so we just reference that."
George: "I think they're talking about
data transfer, but no statements about the presentation of the
information - such as images, hand-writing, text, so it seems to be
possible - a use case that would channel images to text would be good,
unless it's already there."
... "i'll bring it up with our accessibility group and make sure we have
it covered."
Markus: " Ivan - what is our target publication date? TPAC?"
<TimCole> existing annotation use cases don't go into this enough, so if there are dpub annotation accessibility use cases, should be added to dpub UCR
Ivan: "I think what we can have as a goal is to have a first draft published the week before TPAC, which means it won't be final,, we may still add, discuss, or cleanup, but early october we can have the final version. Since it would be just the first draft, the document as it is today is already in good position. Some task in september - can be set to review. What we should try to have as a
schedule is what we really plan to do and in a realistic stance what we plan to do now, with the knowledge that the publishing itself is no big deal. The only thing I need is the approval to say that it can be published. What we also agreed last week was that before we publish, Heather and Nick will have an editorial round to unify the style, language, references, as now it is a document put
together by many people."
...: "Counting back from there, the missing items we discussed today -
we didn't discuss archiving... There amy be issues there. We did not
discuss some other issues. That is how I would schedule."
<TimCole> for annotation body and
target accessibility schema.org's accessibility attributes are
suggested, but properties from other schemes can be used - https://www.w3.org/TR/annotation-model/#accessibility-of-content
...: "How much time does heather and Nick need to unify?"
Heather
Heather: "It would be easier to edit things that are 'done'"
Ivan: "If i look at the dates now - is it reasonable thing to say that next Monday is a feature-freeze date?"
Markus: "1 week from now?"
Ivan: "Introduction from Boris and the Security Section"
Boris: "If that's the date, then I'll make it work but I'll need help."
Ivan: "Ben has additional editing to do - not much but needs to be done."
<bjdmeest> I'll do it ;)
Ivan: "Ignoring Boris' part, it isn't huge. So what if next Wednesday?"
<clapierre> We should be able to get our a11y section done by next week Monday
Markus: " Freezing at the end of August"
Ivan: " I would need it the 12th
<dauwhe> scribenick: dauwhe
mgylling: anything else we need to plan?
ivan: we can work on the TPAC schedule with the chairs
mgylling: we're done for the day. The next meeting is September 12; we're canceling the next two meetings.
Ivan added this to the minutes by hand as as a schedule summary: