Digital Publishing Interest Group Teleconference

<ivan> trackbot, start telcon

<scribe> scribenick: NickRuffilo

<ivan> Chair: Markus

<mgylling> https://www.w3.org/2016/06/20-dpub-minutes.html

Markus: "First on the agenda is approval of last week's minutes. URL in IRC"
...: "Comments or objections, voice them now. --- Ok - great, minutes approved."

<mgylling> http://w3c.github.io/dpub-pwp-ucr/#manifests-metadata
...: "2.7 of use-cases, live-editing. Ivan/Tzviya - what did you have in mind here? Should we chug away on the refinements here? "

Tzviya: "Last week we talked about this being a more important section, and things are just single-sentences. No volunteers, so we're going to do it together. heather isn't here so we need excellent minutes..."

<tzviya> https://www.w3.org/TR/dpub-annotation-uc/#tagging-a-publication
...: " we wanted to use the web annotations use-cases as a model. Here's a link for what they look like. Simple paragraph with some examples of the use-case."

Ivan: "While tzviya is looking, as we well know, no good deed goes unpunished. This list comes from a discussion we had 3 or 4 weeks ago. Heather was very quick in picking up these issues and putting them into the document. Some of these sentences come from people who might be around the table here today, so as many suspect, it may be those people who can go into detail of what they meant. I am not sure if people recognize what they said three weeks ago."

<ivan> http://w3c.github.io/dpub-pwp-ucr/#manifests-metadata

Tzviya: "We can get started."

<tzviya> A user agent needs to know the sequence in which to present components of a PWP to the user. A PWP will likely be composed of multiple web documents. A typical simple PWP will have, at a minimum, 10 to 15 HTML documents and several image files, in one location or many. A more complicated PWP may have many more components potentially including SVG, CSV, JavaScript, and multiple CSS files.

<tzviya> Examples:

<tzviya> 1. Moby Dick contains 136 chapters. Each chapter is a separate HTML document. The user agent must present the chapters sequentially.

<tzviya> 2. The Encyclopedia of Stuff includes 1348 articles, each one a unique HTML document. The user agent must present the articles in order (alphabetically, by title).
...: "I chose one simple sentence. 'As a reading system I need to know the order in which to display the reading material.' I wrote the words above:"

Tzviya: "We can pick this apart if needed, but this is the kind of structure I had in mind for all these use-cases. "

Markus: "2.7 is just scribbles for now but is this structure something that we should modify the rest of PWP UCR document to follow?"

Ivan: "Eventually, yes. The first thing is to put some meat on 2.7 in some sense. "

markus: "This is a good start. In terms of live-editing, would note that a simple PWP might have just 1 html. But thats the only thing I see."
... "OK - creating a google doc we can use to collaborate

Charles: "You mentioned the 10 HTML documents, but really we should clarify that there might be other supporting documents as the HTML main content, just as NCX?"

Tzviya: "We havne't defined an NCX or things like that, so not sure we want to mention it."

<mgylling> https://docs.google.com/document/d/1S_T-j0yr-d6nwO2PagnnM7V_3qDQgynOgyL30jmv3oQ/edit

Ivan: "The fact that the NCX is there or something similar comes from a use-case that is there. Whether we need those auxilliary documents in a new setting - we aren't sure."

Markus: "Remember Charles, this is about reading order - doesn't matter if you have 24 CSS files, it's just about the spine."

George: "I'm hoping that we're going to have a use-case that we can model and we can take that as a template and plug in all our other uses. Do we have that?"

Tzviya: "That's what we've just created - we're keeping it very simple. Paragraph and a list of examples - that's all."

George: "Will we have an ID on it?"

Tzviya: "Yes, but we don't have them yet."

Markus: "Link to document in IRC. We'll first take her scribble text and put it in the new document."
... "[repeats the description copied by tzviya previously]"
... "What strikes me Tzviya when you talk about CSS, SVG, etc doesn't actually contribute to the spine. Yes, the top-level documents may reference these documents but it doesn't matter to the spine or ordering. "

Dave: "How they are placed/displayed is irrelevant to the content within. "

Tzviya: "Ok, I can just cut off the end of that sentence."

Markus: "How - we know Ivan is interested in having these use cases - to explain to the web folks why the web is simply not enough. For example, why isn't the entire Moby Dick in one HTML file."

Dave: "This idea of sequence is fundamental to a publication. We're looking at it from the point-of-view of a reading system, but it's also an issue for the reader. As a reader I want to be able to read a book without caring what the file structure is. I don't want to have a different user interface gesture from getting from 3-4 then 4-5 which crosses a file boundry. I think there i something

important there and that is one problem that I have with the things I create on the web - where I have to click a link to load the next page."

Romain: "I wanted to say that there are some use-cases in the fundamental. There is one about the collection of resources and having lots of resources. Not sure if you want to merge these or not, as there may be some duplication."

Markus: "Just to echo what Dave said, this is a core use-case. So why not have several use-cases from different actors."

+1 to this

Dave: "Files could have different display/metadata/sets/etc and may be different in many different ways, so having them all in one document simply makes no sense."

<clapierre1> Also performance issues with everything being in one HTML file.

Markus: "2.1 is from a publishers perspective - but coming from a different actor perspective is important."
... "Dave, do you want to look at 2.1 and see if there is anything you want to amend to it."

Ivan: "Dave made an important point that should be in the text. Combining everything in one single place with one single site doesn't work when different pages have different styles/languages/etc. The fact that we have several files is sometimes unavoidable. I don't know if you'll put that somewhere but it's an important point. We also have to add somewhere - the reason why we have many many files is that frankly it's more efficient in many cases - such as mobiles, having 1400 articles in one file is not the best way of doing things. There is an efficiency/caching issue that is much more difficult with a single file. I don't know where we would have to put that - which use-case...."

...: "What tzviya had there is the reading order, which is one thing, but we may have to have a separate use-case that, in some cases resources should be kept in different files to keep things manageable. Is there an existing use-case somewhere?"

Markus: "So memory and bandwidth restrictions."

Tzviya: "We can just say: 'as a reading system, I have limited resources.'"

Markus: "Lets grab that one as our next one, so we can tick number 2 off our list."

Tzviya: "We talked about looking at these from different perspectives. We could write multiple use cases, or in the examples, we might choose to use different perspectives..."

Markus: "We should state the functional requirement first, then the use-cases after. Personally I loved the annotations use-case document because of it."
... "Or am I misreading things?"

<Bill_Kasdorf> +1 to following the Annotations model
...: "The following examples are use-cases, and the paragraph is the functional requirements. I think we state the requirements and the use-cases follow."

<Zakim> liam, you wanted to note reading system may need to know what else I have downloaded, for cross links, and must deal with bookmarks and annotations across chapter/file boundaries

Tzviya: "Ok, lets keep with this as I find it readable."

Liam: "I'm always interested in exploring scope boundaries. A reading system may need to know what other things I've downloaded to be able to link to them offline. Similarly on the topic of links, if you're trying to show multiple files as we've seen, then you've got to deal with the case of a section that goes across multiple files. "

<ShaneM> another use case approach: http://w3c.github.io/webpayments-ig/VCTF/use-cases/ identifying user needs by vertical, but mapping "tasks (read requirements)" back to those needs.

Markus: "A range may have a start and end point in multiple resources. A publisher separates them out as different resources."

Nick: "In the case - like reading system resources - I believe we should have a unique use-case, even if the solution of having multi-resource solutions (such as the spine) is a solution to that issue."

Markus: (paraphrased): "Ok that makes sense..."

Ivan: "I tried to be a bit balanced. 2.1 has already some text to it. We can go into the details but that is fine. I am much more bothered by the cases when we have a single sentence which is not enough. I'd prefer to go back to 2.4, 2.5. 2.7 and possibly 2.7. There are others that have less text. What bothers me the most is the 2.4 - 2.7. As a reading system I need a list of things to process. I don't know who put it there. We need to have a good argument for this one. One counter might be "if things are in links in HTML files."

Ivan: "We need to note what items are not on the web, and a strong case why it was there"
... "To be able to reliably go offline with content - I need to know what I have to move offline. I tried to take the essence of this - one of the general use-case that we have somewhere is that I want to be able to move offline/online easily and our system needs to know what we have to go offline. A list of things that belong to the document."

Markus: "For the first example - 'I have an HTML document with a number of links/SRC documents. I could fetch those documents - why would I need to duplicate that information in a different list?"

Ivan: "If you read the case, it doesn't mean that these items need to be in the HTML file. This information is needed for caching, but that doesn't mean it can't live in the HTML files."
... "The next case is what is essential for the user to view the content. We've had this example many times. To differentiate between - such as the font example - some fonts are not for offline use. Some fonts are essential for offline use. This information has to be there for offline reading."

Tzviya: "I wouldn't say - convey meaning - as some fonts are for dyslexia"

Dave: "That's conveying meaning to the user."

Tzviya: " I would be careful with the wording."

Markus: " Why do I need to know this as a reading syste? If I can grab the font, I will"

Ivan: "Then the reading system can optimize based on what is essential"

Markus: "In order to optimize for caching for offline - and delivery to the user."

Nick: "Certain items cannot be taken offline - because of license."

<ShaneM> +1 to these restrictions - this is a common problem.

Ivan: "At this point, what we have to put into the document is that this situation may come up. It may not come up with Monotype, but this is a use case that may occur. This is a use-case..."

Vlad: "In many cases, the reading system cannot determine the license - so the reading system should help the user do what the user wants to do. When Sony built a blu-ray player that would not play on writable media. The result of the action was user backlash. it's not the readin system that should make these distinctions. Proper license is the author's responsibility."

Markus: "In an ideal world, maybe. But a publisher... A publisher needs to be able to acquire and express the license situation for the resources in the book. A publisher may focus on things that go online first - and not worry about whether or not the user goes offline..."

Vlad: "Going offline/saving offline content for temporary offline use. Distribution of the epub as a separate standalone content."

Nick B: "Related, but minor - we've create a new heading - is this not a duplication of one further down? Is this a dupe of the offline one?"

Markus: "Yes"

Nick Barreto: "They are different, as part of the document might be available offline - there's another one - can the entire document be not offline? Is that a distrinction we wish to have?"

Markus: "Should we continue with these - or go on to the next agenda items?"

Ivan: "Will we have a call next Monday - July 4th - it's independence day... "

<ShaneM> (I am in a web payments working group meeting in London on 7 July)

<Vlad> :)

Tzviya: "Lots of work to do on this document, we could have another brainstorming session, lots of editorial work. If you have time to give, please give time..."

Markus: "It would be great if we had one section completed, so that we would have a great template/role model for the rest of the work. Now that the approaches to editing are all over the place..."

Ivan: "I don't know Tzviya if you've had contact with heather, when is she back?"

Tzviya: "Oh, just her Monday's. She's back later this week."

Ivan: "I know she has already made some changes. The question is when can she take the various things out there - like the googledoc and put in everything that we have into the same document."

Markus: "We should touch base with her first. One piece of stable ground to stand on and copy the feel of is a great start."

ivan: "As a further help do you think you can get her to join the chairs meeting?"

Tzviya: "not sure if she is available."
... "She's asked for an intro"

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

Nick: "i will write an intro"

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

Tzviya: "There's a link to ALL the DPUB githubs on the wiki page"

Markus: " With some luck, we may be able to solidify things before the meeting - so we need an agenda further than that one. What did we do last time? We did the joint google doc thing. Did we focus on a specific area or did we just jump around?"
... "We will amend the wiki page with the agenda - to complete the first section of the 'Fundamental Features of a PWP' but the first question we need to discuss if the stuff in there is right. Great. Thank you everyone."