Digital Publishing Interest Group Teleconference

<tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2016Mar/0063.html

<pbelfanti> I want to share with everyone that I'm leaving Pearson this week. Moving to a new opportunity with another publisher - not a W3C member but I intend to stay active in standards initiatives so I hope to re-emerge in this forum once I settle in to my new role

Tzviya: "Approve minutes from last week?"

<scribe> scribenick: NickRuffilo

<tzviya> https://www.w3.org/2016/03/07-dpub-minutes.html
...: "Any comments on the minutes? Ok - All approved."
... "Only agenda item - discussing the use-cases. Since there's much to discuss, we have given the whole meeting."

Use Case document

 Tzviya: "These will be excellent support to help transition into a possible working group or specification. To date, there isn't much in the document - but Romain will walk us through what is needed. There is lots of room to grow. Heather is going to take over lead of this group."

<rdeltour> https://github.com/w3c/dpub-pwp-ucr/wiki/Use-Cases-Overview

Romain: "The best is to watch the wiki page - which lists the use-cases and areas that we need to focus on. When there was existing use-cases, I added a link to those. I can go through the list... "
...: "First item is portability - so I identified the item. The first bullet is the locations of the old wiki, but are not the final organization of the document. If we are to mimic the CSV on the web - what they have there is a flat list of use-cases. For now, lets not talk bout the organization of the use-cases. Portability - based on the locators task-force - these use cases are primarily about what it means for a PWP to be able to move offline - change it's state and ownership. Whether it moves with or without annotations. Has to deal with change of state or locators, or so on."

Ivan: "Do we want to comment on each of the bullet points, or do you want to do it later?"

Romain: "Whatever is best for this."

Ivan: "Ok - so lets comment bullet by bullet. In the first - what I think is important to outline as a use case - is the fact that we have one URL for a collection of resources on the web, something the web doesn't have today. It's very important and something we need to back-up with use-cases. It goes a little beyond what the locators task-force is responsible for."

Romain: "In terms of process - with the locators task force. We can expand on the definition. The gap is that the locators task for assumed we had the resource."

Tzviya: "Anyone who wants to volunteer to write the use-cases for the document."

Romain: "It would help to have longer use-cases that cover several of the bullet points."

Ivan: "What these bullets are is what we see as needing covered in use cases, not each as use cases."

Romain: "Nick - please gather your thoughts on the mailing list on a use-case for state changing online/offline

<tzviya> ACTION NickRuffilo to write UC regarding manifest

Leonard: "We've been working on this in locators - and trying to be very generic - non technical solution. We need a manifest of sorts, but not talking how it needs to be found, but what it needs to do."

bill: "What the focus on the locators task force - our purpose is the metadata needed so that we can properly do locators. But there is something bigger as well. Locators wouldn't define everything that would be needed in a manifest."

Tim: "The portability category illustrates what we're going to see throughout - there will be multiple use-cases for all these categories. The archive will have different use-cases for portability. There will be at least three or four use-cases for each of these concepts."

Tzviya: "Yes, archiving is possibly it's own category - overlapping - but good to note."

Romain: "Portability is one of the primary use cases that we need to get right. it's one of the key selling points. The next point is layout. The details of pagination requirements - such as the use cases for an API for pagination - is out of scope for this document. So we're looking for a simple use-case for handling multiple documents as a single set. I think that is all we'll need for pagination."

Markus: "To be clear, Romain - we all agree we shouldn't repeat pagination details in here. There are a few other categories that are deflected to other documents. A top-level document, if we plan on referencing external documents or plan on being completely silent."

Romain: "I would turn the question to you - do you think it makes sense to reference external documents? As an interest group, it makes sense for us to work on a detailed pagination document and highly needed for digital publishing and it's huge work that requires details and should be a separate document, whether to reference one is an editorial doument."

markus: "I think we should. Having one entry point to understanding digital publishing requirements - it would be nice to have it on the web. "

Romain: "You were talking about digital publishing requirements. The document here is about portable web publications - so maybe we would want an umbrella document that sits on top of this use-case document."

Markus: "Yes - that's correct. I think it's a good idea to reference out to existing documents."

Romain: "The next use-case is about identifiers. We are not tasked to find a solution, but we at least need to make it appear in the use-cases. There is not one specific use-case, but multiple. Bill talked about this in his earlier comment. The next category is metadata. The primary use-case is about discovery, but it can be integrated into a larger use-case. We have a use-case that could be the basis..."

Leonard: "The problem with accessibility of ebooks for discovery. I think we need to be more clear as to the general value of such metadata."

Tzviya: "A few of us are working on that and we can do that."

Romain: "Accessibility metadata ... If we have a use-case that covers this discrete need, it could cover additional aspects of metadata - so it would cover all the use cases by covering this specific case. "

Leonard: "If we can discuss how the accessibility metadata in more general terms, it could provide more value."

<lrosenth> actually I would like metadata discovery to be about ANY type of metadata or document features - not specific to Accessibility

Ivan: "The reason it's set up is that this is what we have right now. There will be many other use-cases that will lead to metadata issues. Such as how in a PWP we want several different documents - so there are many documents that need to work together. Metadata should be available for the collection of those documents and not just an individual document."
...: "For many, metadata has a specific connotation in terms of structure and specific vocabularies. For others, it's just data about data, so we have to be careful about the terminology - especially int he locator work, so we use the term 'manifest' as a general thing that may contain metadata or other things. Some of the discussions in the BFF on the epub side which may include a manifest which may include metadata.... A manifest is more general and less specific, but lets see how the use cases evolve."

Bill: "Quick terminology note. We should try very hard to not use 'books' and use publications - and only use 'books' when you specifically need to."

<lrosenth> +1

Ivan: "HUGE PLUS ONE"

Markus: "The items linked are the old use cases, so the wording is subject to change. I suggest that we use them as starting points. The wording there is not the absolute final wording."

Romain: "Content and market - there are a few use cases there. What we have to keep is inter-publication linking. Linking from the web to a publication and from the publication to another publication. About external resources and how to link to them inside a publication - images, scripts, data, etc. Another use-case about a PWP being used as a dictionary. Do we need a use-case about doing a browser polyfill?"

Leonard: "The locators is also addressing inter-publication linking."

Romain: "We are all assuming that the browser can natively display the PWP - although thats not the case for the next few years. Should we have a use-case for a polyfill of features? Implementing a reading system?"

Ivan: "My answer is - yes and no. On the one hand, from a use-case point of view - one of the major use-case we do have is that a PWP should be automatically/easily handled by a browser. The poly-fill is a very technical thing that sort of refers to a technique that people are using. I'm not sure we should use this technology here. I'm worried about using that terminology for 'putting some javascript where the browser doesn't'"

Leonard: "Agree with Ivan. While we want browsers to display PWP, it's not the only place we expect PWPs to be processed - which is why we've discussed general things like 'publication processor.'"

Ivan: " The reality is such as a use-case saying PWP should be - eventually - handled by browser - is a great use case. How it happens is different. The fact that we want the browser to be there as the renderer..."

Romain: "What I had in mind was that - ultimately - the extensible web manifesto should be applied to PWP as well. Polyfills are used in this context to cover the new advances in browser technology while waiting for the proper implementation.

Ivan: "Ok, I'm fine with that."

<mgylling> https://docs.google.com/document/d/1ZTBiSyyIgQMXh_9Ubtep4I7TfW6Yu6l8e06-9EKaNQU/edit

Markus: "About this question - I agree with Leonard that it sounds implementation thinking. On the above URL on google docs, we put down some use cases for browser-reading-system in trying to understand the pure use-cases. With the user as an actor, understanding the need to read in a browser and sometimes the need to read in a stand-alone app of sorts. I think this is where we need to be and all we need to provide."

Leonard: "Alot of us spent a lot of time going through this document"

Romain: "Interaction - a use case about scripting and communicating with a remote server - this is related to what we just talked about - and merged with external resources. I think thats what we have in the existing use-case in the old wiki. "

Leonard: "I'm happy to add that communicating with external resources links up with external resources use-case. Does anyone else want scripting as a general concept - as I don't want that one."

Romain: "What you can do when writing use-cases, create a bullet list of items that you don't feel confident or just don't want to write more about scripting."

Marcus: "One of the issues we've struggled with in epub - with an origin based security model - how does that translate into something like a PWP that doesn't have an origin? I agree with Tzviya- not many use cases are needed here. I've heard from archival that there is an issue with archiving that you should be able to retain a document without a runtime. So maybe there needs to be an archival use-case?"

Dave: "The fact that we've struggled with this in epub, I'd say it might be easier to let PWP go with standard web."

Markus: "If we tie it together with security - maybe it could be bundled like that. "

Dave: "It's something we have to have. It's been a huge issue for epub - that scripting has struggled so much with."

Leonard: "Yes, bundling with security makes sense. Archival will need to look into that. I was asked to give a brief history of how PDF/A had decisions made on what makes sense long-term."

Brady: "I wanted to say that I agree that scripting should be wrapped into security. The security is hosting a 3rd party script on your site. It's easy to support scripting. It's much harder when you are hosting someone else's document. It's largely a security issue, but also a privacy issue. If your site has a privacy policy, the external script might break that privacy policy (as that script might use cookies, etc)."

Tzivya: "There are some use-cases about personalization that we'll want to included. Charles/Deborah and the accessibility task force should be on this one. Things like having the user adjust the font family...."

Leonard: "Terminology question - for book publishing - personalization is the common term used here? Is that the proper term or just a word we applied?"
...: "To me, personalization is having the content modified to the person - so a 'put yourself in the book' or something like that."

<billm> I agree w/ Leonard

Tzivya: "We can determine that later on - i've heard both terms used."

<billm> we should use Web terminology where possible

Charles - "The taskforce is focused on this, but I'm busy right now."

<astearns> I'm trying to keep user pref topics on the CSSWG agenda, looking for dpub reinforcements

<lrosenth> @astearns - thanks!

<billm> also in EDU, personalization includes custom learning trajectory in courseware based on learning outcomes (assessments) but this is quite different than changing rendering

Tzviya: " Internationalization. Big topic but all that's on here is if 'multiple renditions' will be in scope. What that means in this case is that multiple languages i.e. english, spanish, etc."

Dave: "Multiple renditions is a possible solution to that, but not required."

Leonard: "Multiple languages is a use-case that PWP should support."

Ivan: "This is a use-case that - I presume - that when epub added multiple renditions that someone from IDPF figured it was a solution to this. So there should be use cases out there, where we can inherit them from the IDPF. Not that we only want to work with epub, but they have gathered use-cases on this and they should be re-used."

markus: "I can try to find them."

Vlad: I wanted to remind everyone that multiple-renditions does not necessarily have to be multiple-language content, but you can have multiple-language items in the same content. You could also have mixed-language in the same content - which is a different use-case."

Dave: "The web seems to handle multiple language content."

Ivan: "It is often handled by separate documents and isn't inherent in the web..."

Markus: "In a single rendition epub with boatloads of scripting, you can do boatloads of things that multiple renditions does - whether there is a server or not. If you're dealing with a portable document or not. The question becomes - is this an important enough feature to warrant a declarative syntax. Or do we say to publishers that they should put in scripts to solve the problem. It's where you end up having to make a technological solution. "

<tzviya> https://github.com/w3c/dpub-pwp-ucr/wiki/Use-Cases-Overview

Tzviya: "A large number of these we can pick up next week. I've put out the link to the updated wiki page. If you want to take one use-case on, please do so! And lets talk a bit about timing in the next two minutes. If you've offered to write a use-case, you have two weeks to write a rough draft. Then we need people to step-up and volunteer to write the other use-cases."
... " Any other comments?"

<ivan> trackbot, end telcon