Digital Publishing Interest Group Teleconference

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

<tzviya> chair: tzviya

<George> Present George

<tzviya> scribe: cmaden2

<ivan> scribenick: cmaden2

tzviya: approving previous minutes

<tzviya> https://www.w3.org/2016/05/23-DPUB-minutes.html

Catch up on previous meeting

tzviya: was meeting with chaals and idpf merger. no objection; minutes approved.
... action items from last meeting. json vs. xml/zip manifest. dave was going to file an issue.
... dave is sitting right next to me, giving me a dirty look. issue not filed yet.

dave: lots to be done; first thing, asking about using manifest *as* manifest. has scope, but not enumeration of files.

ivan: relates to question of what a manifest is. (who was speaking?)

tzviya: extending app manifest

ivan: there is also an agenda item for that, postpone?

tzviya: good idea. app manifest postponed.
... discussion of packaging in app manifest issue tracker.
... issue tracker deals mostly with launching apps, no mention of packaging. could it point to something?

<dauwhe> https://developer.mozilla.org/en-US/Marketplace/Options/Packaged_apps

ivan: app manifest does not enumerate content, but has more packaged features

dave: while rummaging around the web, mozilla talks about a web app with a json manifest at the top level of a zip, very similar
... not sure how similar, though.

Use cases on Manifests

tzviya: we need to flesh out use cases before we file issues against app manifest. let's move on to use cases.

tzviya: virtual f2f was successful in fleshing out use cases.
... let's look at where we are with manifest use cases.

<tzviya> http://w3c.github.io/dpub-pwp-ucr/#use-cases---manifests-and-packages

tzviya: most important at this point, defining what the manifest is.

nick_ruffilo: package is single resource location that defines all the necessary components; manifest defines components.

BillK: is it a description or an identification?

nick_ruffilo: it is a description. we want to say more than just here are the files. here's *why* they are here (e.g. reading order)

<laudrain> +1

<Bill_Kasdorf> +1 to manifest for publication, not [just] for package

ivan: manifest for the publication, not for the package. has a role to play in a publication even without a package.

dave: description of files isn't a use case. what actions to we need to do, which need information to be carried out?
... service workers can take action, but need to be told where files are.

<ivan> +1 to dave

jean_k: idpf manifest was about packaging. nav was the double-purpose thing providing list of content, chrome.
... has anyone thought about double-purposing manifest within pwp?

tzviya: extensively.

jean_k: are we sure?

tzviya: for use cases, don't need to solve that.

ivan: [and then a truck drove by] follow up on what dave said; what are the files i want to put offline? but also characterization of those files.
... a list, plus a characterization of files, so i can make a decision of what i need offline.

laudrain: in terms of manifest, it's a question of actions. use cases about distributing a publication means an assembled document, a package of well-prepared documents, whether internal or external, they constitute the set of items' first action is to prepare the assembly for distribution, manifest is key to explain what we wish to do
... actions on the items needs to be guided by some kind of description, i.e., manifest

bill_kasdorf: purpose of manifest is to say, here are resources required by this publication, how they can be obtained. some metadata (e.g. mime type) can be conveyed by the thing, manifest doesn't need to replicate.

ivan: currently, document has separate manifest and document sections. in fact, having manifest is raised by other use cases (collection of resources). use-cases doc could be restructured, but not sure how. maybe heather has a clear idea?

tzviya: added use case, list of objects i must access whether on- or offline

george: streaming is a use case. client needs to know what pieces they need first

heatherf: like the idea of focusing on manifest to develop use cases, rather than saying it's a requirement. mailing list had debate about whether manifest was even required.

tzviya: best to start with new, simple requirements for manifest.

<HeatherF> 1+

ivan: need to see how requirements can be integrated into something like a manifest.

<laudrain> the web isn't published at a certain date

tzviya: ivan, can you clarify?

ivan: if i look at use-cases doc, §7 is manifests; manifests comes from the document, as it was one of the use cases. most use cases require a manifest. manifest is more fundamental than one section.

tzviya: maybe manifest needs to be fundamental, at the start?

<Jean_K> +1

heatherf: was going to suggest same thing, put manifest in fundamentals

tzviya: heatherf has probably already made this change.

ivan: next use case is loads of metadata about the publication

jean_k: why don't we have a fundamental use case about metadata?
... in edupub, metadata just as important as manifest

<Jean_K> metadata manifest in a manifest... How very meta.

laudrain: metadata is fundamental, agreed. difference between web and pwp is web isn't offline. web isn't created at a certain date. manifest has to solve specific preparation of data made available offline at a certain date.

tzviya: keep in mind that use cases are about portability; metadata does or does not come from those use cases

<tzviya> rdeltour: we need to be careful when discussing metadata

<tzviya> ...title or cover may be crucial to the publication, but schema.org may not be a use case that is relevant

jean_k: rights and permissions also needs to be part of the offline-available information

<laudrain> +1

ivan: is this enough input for heatherf and romain to update the document?

heatherf: i can come up with basic use cases; if anyone has more intrinsically interesting ones, would be appreciated.

<HeatherF> What I have for metadata so far:

tzviya: we need to be mindful; we talked about a basic manifest use case, and now we're in metadata. metadata use cases need to be written up, but should be distinct from manifest.

<HeatherF> As a reading system, I need descriptions about the publication that travel with the publication whether online or offline. For example: author, title, size, rights and permissions, accessibility, multimedia details.

<HeatherF> We can definitely break it up - they are just examples

tzviya: e.g., authorship can be whole or partial.
... so let's start with manifest

ivan: basic manifest item, list of resources, author, title, these belong to the same category in some sense, and so are metadata about the publication.
... whether some go into the manifest as json, or some into turtle files, that is secondary. fundamental is that a pwp needs knowledge about a bunch of resources, not just a list.

george: manifest is the bootstrap, isn't it?

tzviya: it is in epub; pwp doesn't have to work the same way.

<dauwhe> scribenick: dauwhe

tzviya: @manifest has something called the start member
... but that's different than what's in epub

<rdeltour> FYI, the Web App Manifest UC&R: https://w3c-webmob.github.io/installable-webapps/

tzviya: manifest can be the thing that indicates where to start, but it may look different than in epub

ivan: I come back to my previous point, which includes what George said
... one of the fundamental use cases (on a high level)
... if we have pwp, we must have a lot of data available for the processing
... that gives a structure for a document... the fundamental thing is the list of resources
... we need use cases about additional data
... I won't even use the word manifest, because it reminds us of json or xml, which may be premature

<tzviya> dauwhe: one of the key things in a publication is that there is an enumeration that defines what is in the publication and what is not

<laudrain> +1

ivan: what is and what isn't in the publication
... what is necessary for the whole publication to be published is not only the list of resources

tzviya: we have 15 more minutes and we have the basic use case
... we get into some scenarios in the other use cases, where we need to know what's in and out
... we don't have basic examples of "i'm publishing a book/journal, and processing it requires xyz"
... should we talk about that now? assign it as homework?

NickRuffilo: defining them now would be good

tzviya: nick, let's write a use case!

dauwhe: as a reading system, I need to know if I support media-type foo

NickRuffilo: as a reading system i need to order in which files are displayed

ivan: as a reading system i need to know size of resources

Jean_K: i need to know if i'm online or offline

NickRuffilo: do we need to know the state, or what to do when in the state?

Jean_K: it's a separate question

tzviya: AARS, I need to know which files are "essential" for the user to percieve the content

rdeltour: I need to know name and cover image to display publication on shelf

Bill M: AARS, I need to know...

<ivan> bill: I need to have access to the resource "efficiently"

Bill: without having to inspect every file...
... but it's more efficient to not have to parse all the content

Luc: I need to know what the next file is

Avneesh: I need to know if content requires special processing, such as MathML

<laudrain> Luc: I need to know what the next file is the next one

ivan: I need to know if I have the right to use a resource offline

<HeatherF> Already typed in

george: i need to know if there are extraneous files in the publication
... if it's not in the manifest you are processing at your own risk

NickRuffilo: I want to make sure when I recreate the package it's complete

george: some readings systems use that mech to update

ShaneM: AARS I want to know that the resources are unaltered

<Jean_K> +1

tzviya: AARS I want to know if the resources are intentionally updated

ivan: I want to know why

rdeltour: I want to know the origin

George: I want to know if there's a newer version available

tzviya: five minutes to go. we need ten more use cases and we'll get a matching grant

<ShaneM> What about annotations?

tzviya: we don't have time to go into detail about bugs for web app manifest
... we have enough info to have a discussion

HeatherF: four minutes left, maybe a quick discussion on the next virtual meeting?

<HeatherF> And that will give me time to update the use case doc on github

tzviya: to answer shane's question, yes, we want to allow for annotations
... there is a use case for portability of annotations
... so we want to allow annotations and the portability of annotations

ivan: is the drawing physical or virtual?

dauwhe: both napkin and keynote

tzviya: three minutes on the virtual f2f

<HeatherF> Doc has been merged on github. Reload http://w3c.github.io/dpub-pwp-ucr/#use-cases

tzviya: ivan, markus, and I talked with heather about a virtual f2f, we felt it was very helpful
... we need to schedule around ietf meetings

<HeatherF> There's irony in t here somewhere

tzviya: week of 20 june or 4 july

<laudrain> +1

tzviya: will people be around?

<HeatherF> Preference from me for the week of 20 June if we can

NickRuffilo: I'll be here

<HeatherF> I'll still be mostly on EU time

<HeatherF> I can do the July date as well

tzviya: another four hour session, or maybe shorter?

<laudrain> Make a Doodle?

<ShaneM> I am not available the week of the 4th nor the week before

tzviya: we'll send out a poll
... we're targeting the week of 20 june or 4 july

tzviya: thanks everyone

<ivan> trackbot, end telcon