13:07:30 <RRSAgent> RRSAgent has joined #collection
13:07:30 <RRSAgent> logging to http://www.w3.org/2016/09/21-collection-irc
13:07:33 <HeatherF> scribenick:Heather
13:07:39 <Zakim> Zakim has joined #collection
13:07:46 <trackbot> trackbot has joined #collection
13:08:04 <boris_anthony> boris_anthony has joined #collection
13:08:10 <bob> bob has joined #collection
13:08:26 <HeatherF> dauwhe: suggested the session last week. See summary: https://www.w3.org/wiki/TPAC2016/SessionIdeas#What.27s_new_in_pubrules_and_automated_publishing
13:08:36 <garth> garth has joined #collection
13:09:11 <HeatherF> correction: https://www.w3.org/wiki/TPAC2016/SessionIdeas#Apps_or_Documents.3F_Manifests.2C_JSON.2C_and_the_Future_of_Publications
13:09:25 <HeatherF> dauwhe: how should the web address discrete collection of things?
13:09:31 <tzviya> https://www.w3.org/wiki/TPAC/2016/SessionIdeas#Apps_or_Documents.3F_Manifests.2C_JSON.2C_and_the_Future_of_Publications
13:09:43 <HeatherF> ... higher level than the doc object? Is a web app manifest the way?
13:09:59 <HeatherF> ... this has implications for digital publishing, and more than that
13:10:05 <glazou> present+
13:10:13 <HeatherF> ... may want to bundle web content
13:10:18 <tzviya> present+
13:10:29 <leonardr> https://mikewest.github.io/origin-policy/#app-manifest
13:10:31 <HeatherF> leonard: you also talked about metadata over a series of docs.
13:10:38 <dauwhe> present+ dauwhe
13:10:48 <garth> present+ garth
13:11:06 <HeatherF> ... "origin policy and origin policy manifest" which describes a way to define a set of metadata (or anything), common response headers,
13:11:16 <HeatherF> ... so it is  a concept that might be tweaked for some of our needs
13:11:28 <HeatherF> ... leveraging a collection-wide metadata mechanism
13:12:04 <HeatherF> dauwhe: is there a possibility of having a collection DOM element, above the document object?
13:12:39 <HeatherF> mike: the group that's working on problems around publications
13:13:17 <HeatherF> tzviya: DPUB is working on something for web publications. A publication is a collection of web documents which, for our purposes today, is published on the web
13:13:54 <HeatherF> ... a digital book may have many elements--video, images, text--and these may be actually separate files. In a book, you have a table of contents (TOC)
13:14:03 <HeatherF> ... and can easily jump from TOC to page $foo
13:14:21 <HeatherF> ... we talk about books, journals, magazines, self-published newletters, etc
13:14:49 <HeatherF> mike: at a high level, we should assume that we can make the web do that's needed fo rthese problems
13:15:01 <HeatherF> ... making the user experience of books on the web a better user experience
13:15:21 <HeatherF> ... arguably, books are not a first class citizen of the web, and we want users on the web to have the best reading experience we can, even of long format content
13:15:41 <dauwhe> http://www.clickhole.com/blogpost/time-i-spent-commercial-whaling-ship-totally-chang-768
13:15:49 <Kangchan> Kangchan has joined #collection
13:15:51 <HeatherF> ... in thinking in terms of scripting, or programmatically, what's possibly lacking that we could think about further is some reputation of DOM above document
13:16:05 <HeatherF> ... the highest level of representation in DOM is document
13:16:37 <tzviya> q?
13:16:37 <HeatherF> ... for fulltext search, we have a bounded set of documents, and we don't have a great story about how to do this. We need to optimize for full text search against a collection of docs.
13:17:13 <HeatherF> ... aside: the word collection is not great; we deprecated objects in the DOM with the word "collection" in objects. Currently developers are using "sequence", which are ordered
13:17:36 <HeatherF> ... I think you want things to be ordered; a book is an ordered set of documents (usually)
13:17:55 <HeatherF> ... this makes the case different from a website, which may not need to be ordered
13:18:25 <dauwhe> q+
13:18:31 <HeatherF> ... another case that's important is TOCs. We don't have a good mechanisms to easily generate a TOC/outline. We have the outline algorithm in the HTML spec, but browsers don't implement it
13:18:46 <HeatherF> ... it is good for accessibility, and would be good for other things. Regardless, that's the single doc case
13:19:29 <HeatherF> ... we need a way in may books to generate an outline for more than h1 to h6; that's what the outline algorithm is for
13:20:04 <HeatherF> ... but many books aren't a single doc; how do you generate an outline for a sequence of documents? There are ways of doing these things, but we don't have a standard way to do it
13:20:14 <leonardr> q+
13:20:14 <HeatherF> ... we need a standard way to represent a book in the DOM
13:20:19 <duga> q+
13:20:21 <duga> q?
13:20:57 <tzviya> ack d
13:21:04 <tzviya> ack dau
13:21:21 <tzviya> q+ duga
13:21:26 <HeatherF> dauwhe: aside: while generating an outline from a sequence of documents, there is is also value in having an additional navigation document
13:21:39 <HeatherF> ... EPUB does something like this and it comes close to what we're looking for
13:21:49 <tzviya> ack l
13:22:02 <tzviya> q+
13:22:30 <HeatherF> leonardr: about human curation, and extending the idea further, while this also needs to show up in the DOM, there needs to be a declarative model for that organization/sequence as well as the outline and subsections
13:22:40 <HeatherF> ... these are two of the aspects we look at when we talk about manifests
13:22:57 <HeatherF> ... Another point, it's not just the structure and navigation, but also to represent additional aspects
13:23:20 <rdeltour> q+
13:23:22 <HeatherF> ... e.g., here are elements in the reference and why they are important so a user agent doesn't have to parse the entire document; those items are called out up front (fetch this early, make sure this is cached)
13:23:26 <tzviya> ack d
13:23:50 <HeatherF> duga: Are you intended that an entire pub or book would be loaded in the DOM at once?
13:24:11 <HeatherF> Mike: no. You have these docs already, so no, you don't want to construct a DOM object for the whole book
13:24:16 <HeatherF> duga: so how would this work?
13:24:18 <tzviya> q-
13:24:23 <HeatherF> Mike: magic (we don't know yet)
13:24:27 <dauwhe> q+
13:25:07 <HeatherF> ... a big component that needs to still happen is the offline case. The case where the user doesn't have a network but they want to continue to read the same book without losing content
13:25:26 <HeatherF> ... that's a solved problem with Service Worker. We will have implementation in all user agents soon.
13:25:47 <HeatherF> ... outside the document sequence idea, it would be a good idea to think of solutions in terms of building on top of SW
13:26:06 <HeatherF> ... we're already assuming that the solution involves using HTML, CSS, and JavaScript, so we should also assume it will involve SW
13:26:56 <HeatherF> ivan: the usage of SW is one of the reasons why our community considered that listing all the resources a publication may need...
13:27:09 <HeatherF> ???: you can already do that in the SW; there is tooling that goes through all the resources
13:27:32 <HeatherF> ???: you do this when you create the app, it discovers the resources you need, what you need in what order
13:27:49 <tzviya> s/???/Kennethe
13:27:53 <HeatherF> ???: these need to be fetched, these need to be installed
13:28:11 <HeatherF> ivan: it's good that you say that, because we may have some terminology issues to clear up
13:28:26 <HeatherF> ... when me as an author creates a book, at that point, I have a place where I put the list for the SW to use
13:28:33 <HeatherF> Kennethe: it is an array in the SW file
13:28:45 <HeatherF> ivan: what we are talking about up til now is that this is info in the manifest
13:29:33 <HeatherF> Kennethe: marcos is almost convinced that you'll have a SW in a manifest
13:29:51 <HeatherF> ivan: to clarify, there were some email from marcos this morning that he refered to SW API in the manifest - is that it? Y
13:30:08 <dauwhe> q?
13:30:15 <HeatherF> Kennethe: yes. For a long time there was a discussion if the SW be included in the manifest.
13:30:50 <HeatherF> ...: installing a SW means to download the SW and run an install step
13:31:04 <HeatherF> ...: if that succeeds, then the pieces are installed/downloaded
13:31:32 <HeatherF> ...: this is not yet in the editor's draft.
13:31:56 <HeatherF> ...: SW is more stable now, and there are several ways you can call it. So, now the next step is to do this with manifest as well.
13:32:13 <garth> q?
13:32:40 <HeatherF> tzviya: there is an experimental SW reading systems; it needs attention, but maybe more than one person shoudl work on this. Any volunteers of people who have experience with manifests and SWs, that would be appreciated!!!
13:32:55 <HeatherF> Dave and Kennethe - FTW!
13:32:56 <tzviya> ack ro
13:32:59 <tzviya> ac krd
13:33:02 <tzviya> ack rd
13:33:19 <HeatherF> rdeltour: want to make sure we are done with SW? yes, so web client
13:33:41 <HeatherF> ... it was promising, but it failed. It made assumptions on the level of the headings based on hierarchical position isntead of name
13:33:53 <HeatherF> ... was one of the few people that tried to implement it, but it has some value
13:34:17 <HeatherF> ... using the TOC generation will be even harder in a multidoc concept. Since browser vendors have moved on, is it even worth pursuing?
13:34:31 <tzviya> https://www.w3.org/TR/html51/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements
13:35:08 <HeatherF> Mike: the outline algorithm is a consequence that we changed HTML to allow h1 elements to be arbitrarily nested. As long as we have an HTML section article, we're stuck.
13:35:29 <HeatherF> ...: we could say "don't use h1 anymore"
13:35:48 <HeatherF> ...: what they fixed in HTML5.1 is to say "don't nest h1"
13:36:05 <HeatherF> ...: on the UA processing side, they still have to deal with the nested h1 case
13:36:15 <HeatherF> ...: accessibility software doesn't use the outline algorithm either
13:36:36 <tzviya> q?
13:36:36 <HeatherF> ...: if all you've used in your doc is h1, then the screen reader wont' see any structure
13:36:59 <HeatherF> rdeltour: should we just move on, or should we put more effort into this?
13:37:21 <HeatherF> Mike: don't know how to move on from this; in the multi-doc case, this doesn't change anything.
13:37:43 <HeatherF> rdeltour: just ignore automatically generated TOC and manually create it?
13:37:48 <HeatherF> Mike: that's what we are doing now
13:37:52 <tzviya> ack d
13:38:09 <HeatherF> dauwhe: while talking about the collection DOM element, this might be a mechanism for solving another problem in the multidoc space
13:38:24 <leonardr> q+
13:38:27 <HeatherF> ... There is info, esp CSS stuff, that needs to persist past doc boundaries, such as counters
13:38:54 <HeatherF> ... we need to resume from last known value, and there's no place to keep track of that info. If there's a higher level object, that might allow counter values to persist
13:39:26 <MikeSmith> MikeSmith has joined #collection
13:39:33 <MikeSmith> q?
13:39:42 <HeatherF> ... The other question is, if there is such an element in the DOM, can we have an element in meatspace? If there is an element in a doc, should it point to a file entity that enstatiates this doc element?
13:39:45 <duga> q+
13:39:58 <HeatherF> ivan: to add to the list of things we don't understand, doesn't that mean that the CSS processing should also have this notion of multidoc?
13:40:17 <HeatherF> ... if we have to have list counters that jump from one doc to another, then this goes to the same way. It's not only the DOM in HTML, but also the way CSS processes things?
13:40:44 <HeatherF> astearns: I don't think so; we have longform docs in multiple chapters, and people figure out how to get list counters to persist. Let's keep doing that.
13:40:58 <tzviya> acl le
13:40:59 <HeatherF> leonardr: a conversation this morning about storage and security, this is an interesting problem for a security perspective
13:41:01 <tzviya> ack le
13:41:19 <rdeltour> q?
13:41:28 <HeatherF> ... If we assume that want each publication to be unique (unique origin) because as we add rich scripts, we don't want them to be able to influence other publications
13:41:41 <HeatherF> ... that then influences how we want their storage to go (both temporary and persistent storage)
13:42:17 <HeatherF> ... things like cookies, local storage, things we can do today - there's the simple case of local storage, but now span that to a collection of books (e.g., collection of Harry Potter that you'd want ot have info available across the collection)
13:42:41 <HeatherF> ... whatever we do has to abide to the security model of the web. In our design, we need to ensure we are designing around the security model fo the web.
13:43:02 <HeatherF> ... some of these questions, esp. as we think about collections, become interested and complex to fit into the security model of the web
13:43:35 <tzviya> ack du
13:43:36 <HeatherF> tzviya: what we're tlaking about today is that we have ten files; you are talking about files of files
13:44:00 <HeatherF> duga: please don't make us rely on previous chapter's counters to render current chapters. Don't want to have to render the whole book just to know this is list item #74
13:44:06 <HeatherF> ... it's a lot of work.
13:44:30 <HeatherF> tzviya: if I am a publisher, if I have 3k footnotes in a book, please dno't make me manually number them
13:44:56 <HeatherF> duga: if you spread 500 footnotes per file, just note at the start of each file that it starts at 500/1000/etc
13:45:21 <HeatherF> tzviya: my author may change the footnote numbers the day before publication
13:45:43 <mikepie> mikepie has joined #collection
13:45:53 <HeatherF> Kennethe: why footnote numbers? why not identifiers?
13:46:18 <HeatherF> tzviya: that would be lovely, but that's not how the scholarly publishing community functions (and we can't change that, as much as we'd like to)
13:46:23 <HeatherF> ivan: this is market reality
13:46:50 <HeatherF> ... we can't say "change how you've done thing for centuries"
13:47:35 <HeatherF> dauwhe: there are also human usability things here. If I'm reading Moby Dick in print, I get a visceral sense of where I am in the ocean of text
13:47:47 <HeatherF> ... as humans, we like having guideposts to things
13:47:50 <astearns> Areference number in printed material will be useful much longer than a URL will be, given current standards of web archivability
13:48:22 <HeatherF> ... our reading systems have created analogs to these things (e.g., character counts, progress bars)
13:48:29 <astearns> so the conservative academic community might be on to something, at least for now
13:48:29 <garth> Q?
13:48:42 <HeatherF> ... having a one dimensional indication of progress through a thing is of value
13:48:46 <MikeSmith> q?
13:48:52 <HeatherF> ... what the best way to do that in an Internet environment is, not sure
13:49:07 <leonardr> q+
13:49:14 <HeatherF> ... the system digesting the content is going to have to do some figuring out of how to do this
13:49:18 <tzviya> ack le
13:49:28 <rdeltour> q+ glazou
13:49:46 <HeatherF> leonardr: yes and no. You cannot realistically consume an entire large book. There are cases where the current state of reading is not over the entire thing; it might just be the current piece you are viewing
13:49:54 <HeatherF> ... maybe you started in the middle of the content.
13:50:07 <HeatherF> ... Current models of navigation is evolving.
13:50:20 <HeatherF> dauwhe: just saying there has to be a model, but saying thta it's hard for computers is a cop out.
13:50:38 <HeatherF> ... it will have to take into the entire environment
13:50:42 <HeatherF> leonardr: strongly disagree
13:50:47 <tzviya> ack gl
13:51:16 <HeatherF> glazou: listening to everything so far, long ago we wanted to have multi views, now we want multi doc, single view.
13:51:37 <HeatherF> ... we have to look at what remains constant. What is constant is the browser and the viewpoint.
13:52:00 <HeatherF> ... it could be a way to preserve data across the rendering of the documents, because it is about the rendering
13:52:27 <HeatherF> ... the browsing context and the view port has the concept of scrolling, which takes into account the "size" of the book. This can be rendered in different ways
13:52:48 <HeatherF> ... it's worth investigating if we can glue something here to solve the collection problem, the CSS persistency problem
13:53:44 <HeatherF> ... earlier I heard need for search, manipulation, materializing into a document instance a collection. That's probably an HTML document, but the content is still TBD
13:53:51 <Kangchan> Kangchan has left #collection
13:54:16 <HeatherF> Kennethe: if you want to use the manifest, it would probably make sense to have an entry called the TOC, and it refers to the doc that has an HTML element - where you start
13:54:25 <glazou> s/is the browser/is the browser context
13:54:27 <HeatherF> tzviya: this is what we have now in the EPUB space
13:55:06 <HeatherF> ... any other thoughts from the silent observers in the room?
13:55:14 <HeatherF> *crickets*
13:55:27 <HeatherF> *brief rabble rousing moment*
13:55:41 <leonardr> https://w3c.github.io/manifest/
13:56:49 <tzviya> rrsagent, make logs public
13:57:02 <tzviya> rrsagent, make minutes
13:57:02 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/21-collection-minutes.html tzviya
14:03:54 <rdeltour> rdeltour has joined #collection
14:12:44 <dauwhe> dauwhe has joined #collection
14:14:38 <dauwhe> dauwhe has joined #collection
14:29:18 <rdeltour> rdeltour has joined #collection
14:31:38 <laudrain> laudrain has joined #collection
14:35:05 <duga> duga has joined #collection
14:37:48 <boris_anthony> boris_anthony has joined #collection
14:41:04 <ying_ying> ying_ying has joined #collection
14:41:39 <ying_ying> ying_ying has left #collection
14:47:20 <leonardr> leonardr has joined #collection
14:47:34 <dauwhe> dauwhe has joined #collection
14:47:45 <leonardr> leonardr has joined #collection
15:06:30 <tzviya> tzviya has joined #collection
15:30:05 <boris_anthony> boris_anthony has joined #collection
15:44:51 <dauwhe> dauwhe has joined #collection
15:56:22 <boris_anthony> boris_anthony has left #collection
16:22:42 <dauwhe> dauwhe has joined #collection
16:40:37 <Zakim> Zakim has left #collection
17:07:21 <leonardr> leonardr has joined #collection
19:49:24 <laudrain> laudrain has joined #collection
21:04:58 <tzviya> tzviya has joined #collection
21:33:29 <rdeltour> rdeltour has joined #collection