See also: IRC log
<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
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.
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