DPUB IG (Virtual) F2F

<pkra> Sigh. webex...

<Bill_Kasdorf> not connecting. Is it the usual phone number and meeting number that we use Mondays?

<brady_duga> No

<HeatherF> https://mit.webex.com/mit/j.php?MTID=mbdb39d6c679eb2f52abbe79e0cf37080

<mgylling> agenda: https://www.w3.org/dpub/IG/wiki/May_2016_Virtual_F2F

<tzviya> https://www.w3.org/dpub/IG/wiki/May_2016_Virtual_F2F

<bjdmeest> scribenick: bjdmeest

<tzviya> chair: Markus

<HeatherF> http://w3c.github.io/dpub-pwp-ucr/

mgylling: let's kick off

Intro discussions

<tzviya> http://w3c.github.io/dpub-pwp-ucr/

HeatherF: first: thanks Romain for getting the issues sorted out
... much was from the issues list
... I hunted down task force items as well
... some cases were duplications
... I do suspect, given all the different use case places
... that there are some missing
... I'll do active updates of the docs today
... I normalized a bit, but there are discrepancies
... it's a first draft
... the categories are my own, so better organizations are welcome

rdeltour: I wasn't sure we needed such categorizations, but reading the first draft, the categories seem convenient

mgylling: the categorization can be revisited later, difficult to tell now I think
... we don't have critical mass yet

round through TF-s

mgylling: before diving in, we want to check the bases of the task forces, to know whether there is more stuff on the way

tzviya: archival TF has some more use cases coming
... there will be at least a few more use cases
... Tim will come round half-way through the meeting

clapierre: we came up with a use cases for DIAGRAM
... we started looking at that
... also, for different user use cases (e.g., blind, etc.), we'll look into that

mgylling: did you stumble on more generic use cases, i.e., not only for digital publications?

clapierre: I feel some of them are, but not quite there yet

tzviya: we're trying to distinguish PWP-specific use cases
... i.e., what makes us portable, and how does that affect persons with special needs

<ShaneM> For example - users who rely upon web-based ATs

mgylling: argumenting why something is a PWP, is to look at 'long-form publications'
... i.e., the difference between a web page and a 2000-page book

<ShaneM> I note that the A11Y COGA task force is expected to put out a first public working draft soon - that should include things that are relevant.

mgylling: efficacy and efficiency is important
... it's not critical for lolcats.com, but it is for a student needing to plow through a course book

ShaneM: COGA have lots of stuff, including use cases

mgylling: what should we expect time-wise from a11y TF?

clapierre: once we dive in, starting the regular meetings again, we'll get somewhere
... at this point, maybe by the end of August, we should have something

mgylling: apart from DIAGRAM, you will also lift in some things from the note

clapierre: I'm not sure pagination vs reflowable is an issue, and, e.g., page turning.. is going to affect that all

mgylling: seems like a personalisation use case

tzviya: let's not focus too much on the category, and get the use case in

mgylling: maybe we should add an a11y use case category?

HeatherF: we have personalization use cases

bjdmeest: we sent the identified use cases

ivan: some use cases were submitted as issues in the ucr repo

<ivan> https://github.com/w3c/dpub-pwp-ucr/issues/19

ivan: are they incorporated?

HeatherF: I went through them
... configurability for important resources is in there, cross-references are in there.. yes, they're done

ivan: as the locators TF is essentially closed, that's that for them

tzviya: (for the semantic structure TF) we have the aria web modules, that's there
... so I'm not sure we need more

mgylling: how about extensibility, how can I add domain-specific semantic?
... perhaps, those use cases should be in there, should they?

<pkra> I'm not sure if any of my IRC messages came through -- I think they didn't.

<pkra> In any case: I can't get onto webex so will stick to phone.

<pkra> I don't think STEM TF has anything to contribute to PWP use cases.

tzviya: I understand that there are domain-specific semantics, I don't know where they go

Bill_Kasdorf: (giving an example): for example
... terms are needed to tagged as 'formal usage', not just in general sense
... they don't have a good place to put information

<pkra> @tzviya yes, I'm on that one. It's a general failing on my end (java issues)

Bill_Kasdorf: these semantics are critically important, they are incorporated into laws etc

<pkra> @tzviya yes. :(

<ShaneM> then use role

Bill_Kasdorf: people put specific attributes in the class attribute, because they can't put them anywhere else

ivan: for our purposes, this means: the dpub aria doesn't scale enough
... because it is bound to, a.o., a11y etc, it doesn't scale to the level we need it for
... that's a use case

mgylling: could we identify a few of these very special cases that have a strong need for specific semantics
... a few, real-world scenarios, where specific semantics is critical

<Zakim> ShaneM, you wanted to ask about "validity"

Bill_Kasdorf: I could easily supply some examples from common domains (education, law, engineering)
... all three domains are important in a broad sense

<mgylling> ACTION Bill_Kasdorf to provide 3-4 examples from specialized domains re use of specialized semantics

<trackbot> Created ACTION-58 - Provide 3-4 examples from specialized domains re use of specialized semantics [on Bill Kasdorf - due 2016-06-01].

ShaneM: I wanted to note: about validity: did you mean 'does it pass validator.nu'?

mgylling: there are 3 ways of defining roles, and we have to pragmatically align with HTML5
... i.e., a role has a specific set of values
... so, I talk about the 'real-world' role attribute as expressed in HTML5 and ARIA
... there, extensibility is not allowed
... which differs from your role-module

ShaneM: there's a fourth player, the WHATWG attribute
... it depends on who you care about
... I can help, by changing the validator, that if it sees the role attribute, it emits a warning instead of an error
... which might ease users
... but, even if you extended the vocabulary, these semantics would be meaningless for AT
... there is a data-*, and you can do whatever you want with that

mgylling: it's not only for a11y, it's a lot about processing
... e.g. role=assessment, we use that in dpub
... when authoring, when making an assessment, to fetch the latest version, etc.
... there are 2 factions: use the role module liberally (which would suit us), or restrict the role module, to make AT more predictable

tzviya: we're just writing use cases, this is about: a world that needs specific semantics exists
... there are some examples here
... so, we have semantic needs, here's why, it's about processing and using, and here are some use cases

<ShaneM> https://www.w3.org/TR/role-attribute/#s_role_module_attributes

tzviya: mentioning a11y is a great idea, because for education, that's crucial

mgylling: so, we went through archival (get back to them), a11y (get new section for them), action for Bill
... (user interface and computer interface would be great)

tzviya: anything for CSS?

ivan: we have to be careful what to put where, but I think the pagination and mainly the pagination over several documents
... is something that should be mentioned somehow
... pagination is discussed in CSS
... but there is this additional thing -- PWP related -- pagination/transition across documents, which remains to be solved

rdeltour: besides pagination, there is also the issue about the customization of CSS
... to not make the same mistakes as in EPUB

mgylling: let's keep these two things in our mind (when dave gets back)
... the multiple documents thing, and the cascade customization thing

ivan: some issues of romain are related to multi-page transition, some are CSS-related
... some are related, and should be written down

mgylling: pagination and generated content, comics-like transitions, and romains issues

ivan: we have 2 or 3 issues on security-related things

mgylling: about identifying areas we are weak in content, that's a good observation

tzviya: they need some clean-up, they are in the issue tracker

<mgylling> acl heather

<ivan> For the records, the security ones are https://github.com/w3c/dpub-pwp-ucr/issues/21 and https://github.com/w3c/dpub-pwp-ucr/issues/22

HeatherF: going through the issues as they are at the issue tracker, might get confusing

mgylling: true, let's not get lost in the details

Fundamental features in PWP

<tzviya> http://w3c.github.io/dpub-pwp-ucr/#use-cases---fundamental-features-of-a-pwp

ivan: one of the core issues we got is: why do this PWP stuff in the first place?
... given that CSS works perfectly, we could just publish on the web, right? Why do we need PWP?
... if we can give some clear use cases, for an end-user, a publisher, etc., we could tackle those questions
... maybe such a use case is easy to make for a publisher

mgylling: so, the rationale for portable documents?

ivan: and also, the rationale of documents that are more than one webpage
... there are several different areas
... portability might be only one of them

<pkra> soo close. now I can see y'all.

<pkra> but you can't see me.

Bill_Kasforf: important area is integrity

<pkra> oh well.

<Zakim> liam, you wanted to ask differently - what long-term value proposition can we offer people reading ebooks and ebook reader maker and Web users

liam: I agree with ivan, but also: what's the value proposition that we can offer to people that read ebooks and ebook reader makers now?
... what significant changes can there be?
... we do have potential for, e.g., interlinking e-books

ivan: I was asking 'what does this approach bring to readers and users'
... there is also 'what does this approach bring to publishers and reading systems'

<pkra> hurgh.

<pkra> and I'm gone again.

<mgylling> scratch pad: https://docs.google.com/document/d/18Y6toZqUkOLbfs43rjMHxcheJv-iQlgJALhXmjCZ1Ec/edit

tzviya: right now, we use jargon in the use cases that we used ourselves (e.g., packed/unpacked)
... but that's not always clear for users

<HeatherF> yarn already purchased. :-)

<HeatherF> I believe you said purple...

<ShaneM> inertia

mgylling: getting back to ivan and Liam: have you asked the hardcore web people why people still use pdf?

ivan: the answer may be: big ugly corporations, pdf is a relic

mgylling: one of the alternatives is making an alternative to pdf that uses OWP

liam: answers include (maybe exaggerated): pdf is legacy, print is legacy, and they should go away

Bill_Kasdorf: both the PDF folks and web folks see those formats as output formats
... but publishers use web formats way upstream in the workflow
... for processing
... the thing is: start with web technology, and it's always web technology, not just delivering a product

<pkra> ahhh. everything is crashing.

ivan: I think they say: you only need Web technology, you don't need anything new

<HeatherF> Link to scratch pad?

<tzviya> https://docs.google.com/document/d/18Y6toZqUkOLbfs43rjMHxcheJv-iQlgJALhXmjCZ1Ec/edit?usp=sharing

ivan: I just added high-level things to the scratch pad, i.e., what makes books different than a single web page
... translating them to technology, it makes a point about multiple resources being considered as one entity
... that's the integrity concept
... and it also brings in the necessity for publishers to handle that thing as a single thing

mgylling: an example of integrity/longevity is a government agency
... it's one reason why government agencies make pdfs: it's a reliable blob that will work as a document for eternity

tzviya: also journals

ShaneM: there is an argument about organizations lag behind (i.e., in web browser versions)
... mature organizations have a requirement for stability

luc: PWP is for publication, not document, so a 'publication' already stands for those issues

ivan: the business model of publishing has been thinking in terms of a stable entity, that is the product
... there's a business model behind that, that we cannot simply ignore

mgylling: about journals: many publishers already use the Web

ivan: as a use case: modern publications need to adapt to various reading systems
... web technologies already provide that

luc: about national archives
... it makes me think about legal deposits
... e.g. archives that get a copy of every publication, print and ebook

ivan: HeatherF, can you work with this scratchpad?

HeatherF: we'll cleanup later

liam: people still use PDF, because we don't have a good linking-story
... bibliographic citations and references etc.

ivan: there's also the issue of conforming on whether the whole PDF toolkit is good

[10 min break]

<HeatherF> The copy on Github has been updated with what I've captured so far from this morning's discussion. Note additions to sections 2, 7, 8, and 9

<ShaneM> HeatherF+

<HeatherF> Bah, a missing </section> tag. I hate it when that happens.

<ShaneM> I use vim + Syntastic + HTML tidy so it warns me about such things when I save. Handy.

<HeatherF> I'll have to look at that at some point. I'm using Atom.

<laudrain> slippery

tzviya: welcome back my friends to the show that never ends
... we've added more stuff to the google doc and the use cases
... we were talking about national archives
... any comments on that?

Bill_Kasdorf: wait for TimCole?

ivan: I'm looking at what heather did
... what I miss is the question of one web doc vs a collection of resources

HeatherF: I have a placeholder under pagination and gencon

ivan: for me this is the first use case, as it sets the tone
... this and online/offline

<rdeltour> +1

tzviya: I agree
... let's put that at the top
... we are talking about multiple html files
... publishers work with chapters and components
... we could put all of them together, but that goes to performance

ivan: it's also related to workflow
... if a 2k page book turns into one html file that's a problem

laudrain: chapters have their own individual workflow

Bill_Kasdorf: different authors

ivan: we are not only talking about html files, but zillions of images and css files, which are all conceptually part of a single chapter

brady_duga: why are CSS and html in different files? It's an organizational thing

ivan: if you talk about media files, it's not only that

brady_duga: there's no reason for html and css to be in different files

ivan: it comes back to workflow, it becomes unmanageable

<Bill_Kasdorf> one html can have many different CSSs

dauwhe: everything in tech has evolved towards division

mgylling: what about the 5doc guy?

tzviya: we have a few bullet points here

dauwhe: I want the freedom to chunk or not as suits my content or workflow

laudrain: chunking is important... can grab a chapter or subdocuments from a larger whole
... using web techniques we could have consolidation of chunks
... a publication may be a combination of smaller chunks that are presented as a whole

tzviya: Heather was editing as Luc spoke
... this might be more than one use case

HeatherF: we're coming up with requirements, but we don't have use cases yet

mgylling: Luc, maybe one scenario is to say
... a publisher puts together an anthology, and uses resources from different rights-holders on different servers
... then you don't have the right to move the content (there's a rights issue)
... and you don't have the right to modify the content

laudrain: I was thinking more of a travel guide or wine guide
... the publication may be a large amount of small pieces
... this publication can be read from a-z like a book, or could be read with personalization (only the white wines)
... if it's one HTML file you'd have to hide some sections
... but we could assemble small chunks of data
... you could have a museum guide, but need to customize for each user

mgylling: you could do this with one doc and scripting

NickRuffilo: there are already businesses doing what you asked, one called slicebooks
... they chop an epub into html chapters and lets you remix
... the purchasers can pick
... I don't think this should be at the spec level
... it's a business problem
... we should make sure whatever package we do is chunkable
... having one giant html file would make chunking hard

tzviya: that's what we're doing, writing use cases

mgylling: what about generated content across multiple docs, URLs, etc?

ivan: we know that web practice is to combine several files into one for a website
... we want to use web tech, want to use whatever is done on the web, so we do several files
... we have to bind that with the requirements that come from the opposite
... that we need one handle for national archives, legal deposits
... having one URI, having a manifest...
... combined with the requirements we already have

Bill_Kasdorf: creating a publication out of chunks, and chunking a big doc to create smaller things
... the components of a publication must be aggregated or disaggregated without loss of information. that's a requirement

NickRuffilo: have we brought up the use case that publishers like to sell your content?
... as a retailer, people want to load their epub onto devices that have no connectivity
... so if it can't be emailed, it isn't viable

<ShaneM> +1 to reading on the beach

NickRuffilo: for traditional publishing

ivan: we haven't talked about the package yet
... right now we're trying to answer the question of why do we need anything at all?
... why doesn't the current web work for us?
... these are the fundamental things for which we need use cases.

laudrain: I agree with Nick about this "whole"
... put before having this whole, we grab many resources and aggregate them
... but specs should not block anything about this possibility
... when it's a publication, it can always be grabbed as a whole, or get some part after publication like slicing
... also in personalization
... if there's only one html file it's difficult

tzviya: nick is adding a use case, if you can add a bullet that would be helpful

ivan: I am trying to extend the use case on anthology

tzviya: going back to use case of publications being composed of multiple pieces
... heather, do you have what you need?

HeatherF: I think so

tzviya: we may break this into a few sections
... welcome Tim!

<HeatherF> I am not at all married to the organization of the doc. IT's more for my own use than anything else right now.

tzviya: we have stuff on offline and online, and why we need portable publications of multiple docs
... we could go on with brainstorming, we're on a roll
... do we want to keep going with portability

NickRuffilo: have we talked rights yet?

tzviya: no

NickRuffilo: do we want to discuss?
... Apache has password protection, but I'm unaware of other web things
... we'd need to solve that problem

mgylling: is there a use case

NickRuffilo: I have a wine book, only want the people who bought it to see it

mgylling: isn't that a paywall

<HeatherF> I have a Read/Write Control REquired use case in there.

<HeatherF> Is this the same?

ivan: I think this is for later
... heather's doc has an entry on security issues

tzviya: feel free to add issues in the tracker

laudrain: it's not a question of security
... it's a question of rights
... we should have a use case that says every component has it's rights

<Bill_Kasdorf> the POE WG (Permissions and Obligations Expressions WG) is working on what is often thought of as "rights expressions"

laudrain: the rights of this resource should be kept as a pwp is made available
... don't know if you've heard of the ??? project
... and being able to retrieve copyright and licensing info

<Bill_Kasdorf> POE WG: https://www.w3.org/2016/poe/wiki/Main_Page

laudrain: in pwp if we assemble some chunks that are inside the package, we should be able to keep copyright info

tzviya: do you want to talk about your other WG?

ivan: bill already has; it's a valid use case, we should remember it
... this is not security, but we need a clear set of use cases for the fundamentals

<HeatherF> I have noted the rights comment under requirements. It doesn't sound like a use case yet.

ivan: I have modified the first use case for why portable docs need to be composed

<HeatherF> I am Anonymous Buffalo! Yay!

ivan: to have a use case that shows the duality of the situation is important
... we have multiplicity of things, but we need the one thing for other reasons

tzviya: does this work for everyone (reads use case)

<ShaneM> "legal deposit" seems arcane

rdeltour: what do we mean by different locations on the web?

ivan: we can simplify it, I can remove this, it doesn't add to the use case

<rdeltour> +1

ivan: the use case is we can't solve everything by having one giant file

tzviya: this use case is packed with detail
... should we have requirements underneath it?

ivan: you have a good point, which is more on the editorial side
... for each use case, we could have requirements and then collect them in the end

<rdeltour> +1 again :-)

ivan: it's clear if we do any use case which is real, it will lead to several requirements

<mgylling> +1

Archival TF input

tzviya: I know the archival task force has some use cases
... what can we expect from the archival tf?

TimCole: Nick was looking at what they need to do with the manifest
... what they need to do when things change
... these didn't sound like drastic changes from current practices
... but archiving servers assume they have permissions
... which gets complicated with distributed stuff
... there are maybe 3 or 4 additional use cases coming
... heather may have more thoughts

HeatherF: one q I had
... several use cases overlap or duplicate use cases
... should we mark duplicate use cases as also applying to archives?

TimCole: I think that's a good idea

tzviya: what kind of timeline?

TimCole: we wanted to get a call later this month or early june, but there are conflicts
... I need to put out a new doodle poll
... and we have some guests, one from IA and someone from national library of Holland

<tzviya> http://w3c.github.io/dpub-pwp-ucr/#use-cases---archival-interest

TimCole: but it will be good to mark some existing use cases as applying to archives

tzviya: there are four broad use cases
... section 8-3 outlines the most important part
... do we think we're going to go much beyond this?

TimCole: I need to look more carefully at what Nicholas did last time
... these might have implications for why the manifest is important

<HeatherF> mgylling: yes, and done in my working copy

tzviya: we want to keep in mind that we have the main use cases, and then we have more nuanced details

TimCole: there's something about the manifest... why the manifest is needed that are not duplicative of what has already been said

tzviya: we might have an archiving case in the first section, then others might end up in other sections
... archiving is one of our most important use cases, but they might be scattered throughout the document
... any more comments on this?

CSS & co

<mgylling> Dave: use cases

<mgylling> - pagination, generated content over multiple documents

<mgylling> - samuel actialuna

<mgylling> - the cascade, who is in charge of the presentation.

tzviya: first we had questions about css things that occur across multiple docs

Tzviya: "we were talking about issues in CSS that affect a package of document - such as pagination and content across multiple documents."

Dave: "Page transitions are subsumed under pagination?"

Markus: "If your use cases cover pagination over multiple documents and you find a nice way to get pagination effects, great. You can have a use case that covers multiple items."

Tzviya: "In the meantime it would be good to write the basic use cases. They can be very simple. "

Dave: "There's lots of UI things like turning pages and navigating the documents. "

Tzviya: "The use case is something along the lines of 'CSS needs to function inside a package'"

Ivan: "one thing is that although a document is spreading over many HTML files, pagination should be smooth enough that the reader should not even realize that."

Brady: "Also useful for searching within a document."

Nick: "what is sub optimal with each HTML file including what they want..."

<pkra> I'm back! (audio only)

Dave: "Useful to have counters - such as CSS for page/chapter counting across documents."

<ShaneM> I like that he knew chapters start on odd pages.

Brady: "In japanese, you may want segregation..."

DavE: "there are techniques, where you could do counter resets."
... "an ebook reading system applies user preferences at the 'whole document' size - so each html file loaded looks the same."

Ivan: "For the CSS people, it may be complicated. But there needs to be a notion of a collection of resources. The continuity of the pages, means the CSS needs to know about the series of documents we are talking about. We aren't talking about solving it, but use-cases and requirements."

Tzviya: "Added some of these items to googledoc..."

<HeatherF> It would be even better if we can turn these requirements into use cases...

<HeatherF> Someone will lose out on being Nyan Cat. That's going to be a huge disappointment.

Tzviya: "I wanted to work on user stylesheets because I've been told I'm dead."

Dave: "I've been told it's how things cascade. It would come into the cascade at a certain point..."

Tzviya: "Are we talking about things like fonts?"

Dave: "Anything, color, size, backgrounds, etc..."

Tzviya: "Does this belong here or in personalization?"

Dave: "It is CSS - changing the presentation. It's both... They are intertwined. Maybe we collect ideas and determine where they should live later."

Ivan: "How do these translate into use-cases?"

Markus: "As a publisher, I want all my footnotes to be numbered correctly... "

Ivan: "... but I want that to happen without artificially merging all my chapters...."

Markus: "Isn't vanilla pagination a use-case here?"
... "Hitting the boundary of one document doesn't cause a break."

Dave: "as a user, i want to go seamlessly from one page to the next."

Ivan: "Wouldn't you want to go to the next chapter?"

Markus: "As a publisher, I want to control the affects of pagination."

Dave: "print focus sometimes makes decisions based off the price of paper. There has been some discussion in epub."

Ivan: "Today, if i understand well, if I have chap 1 and 2 separated, and use the latest houdini pagination, is that when I move from 1 to 2, chapter 2 will be a new page, because it's a new document. I may not necessarily want that. So I want them to be seamless. The presentation should be closely bound to the organization of the files."

Brady: "Epub used to allow it, but no one implemented. It was dropped because it was hard."
... "This is very common in Japanese writing, which has been different due to performance reasons."

Ivan: "Brady, is it a use case you can write down???"

Tzviya: "Luc has been on the queue..."

Luc: "The epub summit presentation on page transition. We're thinking much more about novels but when we come to comics, there is a need for the publisher to be able to manage the transition between pages. The publisher may be able to bind transitions. With books with images, the publishers should be able to master the transitions. The first bullet about numbering of notes. In the digital world, we don't need anymore numbering. Numbering was necessary in paper, but if notes appear as popups, we don't need numbers... It may just be a sign that it is a note."

Tzviya: "To keep the print and the digital in sync, we would need to be able to number so we can reference something."

Dave: "you may choose not to use it for a given piece of content, it isn't something i'd want to eschew"

Tzviya: correction: "for citation purposes... not digital in sync."

<tzviya> s/to keep the print and the digital in sync/In scholarly publishing

Tzviya: "Like dave said, differnet publishers will want to do different things with notes. Some publishers may hard-code note numbers, some will auto-number."

<HeatherF> @tzviya Bio break?

<ShaneM> +1 to the numbers not changing

Bill: "some people in standards and scholarly publishing hard-code numbers."

Ivan: "That was me - and I'd like brady to read over it..."

<HeatherF> http://w3c.github.io/dpub-pwp-ucr/ has been updated with the latest discussion points

<ivan> Heather rocks

<HeatherF> Heather needs to do better with section tags

<HeatherF> Just did another update to fix that.

<HeatherF> Refresh early, refresh often!

Markus: "Regarding transitions, I think we are good. Heather/Dave know that we hope to have some activity about page transitions. We want a guru to join the IG and will have a placeholder for those use cases now."
...: "That means in terms of CSS list, the 3rd thing we wanted to discuss is the same thing that has tormented us in epub-land - who is in charge of the presentation? Whether or not there is any use cases or functional requirements that we want to put in here in order to minimize the risk."
... "What basically is the way to fix this. Are there use-cases we need to spell out on the road to that.

Dave: "This is almost a case where epub is ahead of the web. Almost every epub reading system has reasoanbly easy ways for users to cusomtize what they see. this is easier than most web-pages."

Ivan: "The use case is that readers want to maintain this ability even if they move on the web. "

Dave: " There are fundamental use cases for the reader that they want to pick their font size. CSS in general is working on this hierarchy of needs that the reader's choices outweigh the creator's choices which outweigh the browser's choices."

Ivan: "Can we add to the use case that publishers in many areas are under a legislation that requires much stronger accessibility level than websites and therefore they do have requirements like we just said. Also for legal reasons? Or is that too much to say?"

Markus: "Is there something that sets the bar higher for ebooks than the web?"

<HeatherF> OUtside of accessibility, we also have that nifty use case on "Configurability of Important Resources" and Chef Bob's situation.

Ivan: "It's a legislation? For exmaple books for university students are much more accessible than websites because of fear of being sued..."
...: "Might just mean that those markets will sue them if the markets are not accessible."

Tzviya: "Legislative areas, at least in the US,, the requirements are actually on the universities. So the universities won't buy the books."

<HeatherF> Sound is coming off of Luc's connection.

<HeatherF> That's currently what's interfering with Tzviya. WebEx doesn't handle collision gracefully.

Tzviya: "At least in the US - the legislation goes to the universities. Unis have to provide resources to students that are accessible, so they won't buy a book that isn't accessible. So that ultimately falls on the publishers. It's difficult to write the requirement using legislation."

Ivan: "The fact that you can change the font. A web designer might choose to say: 'so what, websites can get along without it, why would we care?' My answer would be that publishers are possibly under a much more stringent pressure in making more accessible things than the average website designer is."

<tzviya> acl cl

Charles: "I'm thinking of 2 things. One is with DAISY and Benetech we're working on an epub specification that would have items put into metadata. As far as fonts and things like that, I can see a use-case for a dyslexic person to want a different font - and as far as universities wanting different items to ensure accessibility - so it should address that issue."

Tzviya: "Is there a use-case that goes along with it?"

Romain: "I wanted to talk about the ebook ecosystem - there is the book developer, the publisher, and the reading system developer. In the web there is the web developer and the web browser - which is a huge difference in the priority. We should reflect that in the document/use-cases."

Ivan: "If we want this analogy, we leave out the website designer, which is the equivalent of the publisher. I'm not sure it's fair to make this difference."

Romain: "I meant to say that the reading system developer is not represented in the web world - it's new to the ecosystem..."

Ivan: "It's the browser developer. You ahve the browser & reading system developer. And you have an intermediate layer that generates the ebook or website."

Romain: "I disagree because most Reading System developers use browser components, so they have to deal with the browser features but add items on top, so it's an additional piece."

<ShaneM> user stylesheets are not really supported by modern browsers FYI

Markus: "There is an API missing from the browser stack to have a styling/layout decision between the user and the publisher
... " This could be a Houdini issue, but we want use-cases that highlight these issues. Reading system implementers such as brady can help to flesh this out."
... "We're not going to fight that the user needs access to certain display elements."

Ivan: "It may seem embarassing, but it's not there, and this community needs it more than others."

Markus: "Those two paragraphs when revised could make it in. And the final thing which was a question in the beginning. A simplified version of the difference between the epub world and the web. The content provider - regardless who, and the user agent and then the user. in the epub world, all excert changes on the style. On the web, only 1. In the epub world, it's a problem, because it's a big problem because they want their content to look good in all systems. They both have problems but completely different."

Markus: "Where do we want to end up?"

Ivan: "We're back to your first paragraph. There's a good reason why it is what it is. That's the use-case. We have to have a clear way about why the publishing world has approached it in this way."

Markus: "Not saying we should omit users. The culture clash is that in the ebook world, user-agents do changes to the styles. The argument is that there are so many broken ebooks that look like crap. I'm sure there are bad websites, but browsers don't fix them. That's the clash of tradition. "

Tzviya: "What's happened in the ebook world, is that it's mostly retailers, so they're vetting what they sell. For browsers, it's open, there's nothing to sell..
... "The reading systems do interact with the CSS - and the publishers complain about that. The RS offer tons of options, which is only possible because the RS gets in the way."

Markus: "Content producers spend 90% of the cost is on User Agents treating books differently. That culture/organization is not carried into the future. Is there anything we can do?"

Dave: "I agree with markus - it's a really hard problem and it's fundamental to portable documents viewed on someone elses server. It's core to the security problem that I'm not sure if you did a good job, but I have to still display it."
... "The web has faced a related problem (the performance of websites in general) that people throw so much crap in their websites, where mobile performance is horrible - so now you have things like google AMP - by making the rules drastically tighter. One potential solution is to say 'no this cannot be a free-for-all' if you want to play in my sandbox you have to play by my rules. It's horrible, but I'm not sure what other options there are out there..."

Bill: "One of the big points that came out of Bordeaux was transparency - the inability of what would be done or to predict what would be done."

Tzviya: "I think we've defined what has gone wrong in epub so that we can write clear use-cases."

heather: "there are a couple of points where I understand the issue, and I hear requirements, but I'm struggling with what should the use-case be. I didn't hear anything new out of those things about 'who's in charge of presentation' Did I miss something?"

Brady: "Example: 'say I'm reading a programming book that's in a sans-serif book, so as I user I want to change the font to be this lovely serif I have involved. I switch the font. The reading system needs to understand that I want to read in this font - but the reading system needs to know that the code examples are a specific font. So there needs to be a knowledge between the publisher, the

reading system, and the user to know that body text gets changed but not the code examples."

Tzviya: "Manifest? Or next steps?"

Ivan: "I found this very good. Do we want to repeat this before september?"

1+ (half day is also nice as it doesn't kill ALL my productivity)

Tzviya: "Heather did most of the next steps. We definitely have some use-cases in the issue tracker. "

<HeatherF> still hear me?

<HeatherF> I think webex just crashed

Heather - no audio

<HeatherF> charming thing

<HeatherF> ok - quick sum up: there are more issues coming in that I need to integrate

<HeatherF> and, if anyone is going to be at SSP, I'd be happy to hold a small working session there for further cleanup

Tzviya: "Other next steps..."

Markus: "We have incoming use cases from Bill K and at least 2 of the sub-groups. Archival, Accessibility... Those need to be integrated. I suppose ..."

Tzviya: "We have some security use-cases as well. We don't have anyone in charge of it, just some people add items..."

Markus: "The issue tracker stuff."

Ivan: "These are the use cases. Then we have to assign the requirements for use-cases all over the document. That's another big thing that we have to do. The use cases should be sort of... not exactly equal. Some are long and others are one or two paragraphs. Not sure if heather can hear us..."

Tzviya: "Shane knows magic tricks about getting them together."
... "We just gave lots of work to Heather - is anyone helping heather?"

Ivan: "Heather, you are in the driving seat, but please call out. I'm happy to help in any way you want me to help, but you tell me what to do."

Tzviya: "Romain and I volunteered to help as well."

Ivan: "I'd like to have a feeling of planning"

Tzviya: "Timeline..."

<pkra> sorry for being so quiet (and mostly not actually around due to technical difficulties). It was good to learn more about the topics.

Heather: "I cannot assign them dates, but on the editorial side is there a driving function? Something that would add urgency?

<clapierre> a11y team hopes to get our use cases in by end of August as was mentioned earlier.

Ivan: "By TPAC meeting in september, everythign needs to be publishable
... "That would be the ideal goal..."

<HeatherF> Nick: :-D

tim: "I'll try to work with nicholas to talk about what is needed to get the usecases into shape
... "So the next 4-5 weeks we'll spend time."

<HeatherF> If DPUB meets Monday and Tuesday, I might actually be able to fly in and then just fly from LIsbon to Helsinki Tuesday night so I can be at NORDUnet from Wednesday through Friday

<HeatherF> I'll look into it

Tzviya: "ivan/markus/I will figure out our schedule and will figure things out."
... "So a final draft by september, so maybe a first draft in june/july? Charles said the accessibility ones would be in August. With vacation schedules, I'd want to get something earlier than August as it's difficult to get in touch with people."

<clapierre> we will see what we can do :)

Ivan: "I virtual face-to-face in the end of June would be good timing. If heather - you think you'll have a document in a decent state."
... "Having single use-cases that require some discussion should happen during the monday calls. Jumping a bit ahead, putting the security use-cases for monday - is that realistic?"