scribenick mgylling

<ivan> scribenick: mgylling

<tzviya> agenda: http://www.w3.org/mid/54E70DB1.5050600@gmail.com

scribenick mgylling

<ivan> scribenick: mgylling

last weeks minutes

<tzviya> http://www.w3.org/2015/02/09-dpub-minutes.html

tzviya: last weeks minutes approved?

… approved.

identifiers TF first steps

<tzviya> identification: https://github.com/w3c/epubweb/wiki/Identification

Bill_Kasdorf: there are really two aspects: publication identifiers and fragment identifiers, Ivan has a starting point on wiki, as well as in the notes on packaging wiki page

… markus suggested started with developing functional requirements for fragments, which is probably a good start

… think that will be mostly a technical discussion after use cases are provided, w3c anno group is an important party here

… publication identifier issue initially appears to be a total swamp

… registries dont necessarily point to an online document or an epub; DOI as an example can point to anything although you can use DOI for this purpose

… news is different because they have a firehose [of identifiers generated daily]

… talking about all those identifiers, we need to accomodate any kind of publication

… it may be that those IDs used today maybe arent relevant to CID

… is this actually a metadata TF activity, or a new TF? Do we need to start over and recruit people from the beginning?

tzviya: from my POV, it doesnt matter what we call the TF

… looked at Wileys journals, found 5 different ways to do identifiers

… we need to come to consensus about our recommendation, use cases and business requirements [???]

ivan: dont care about the name of the task force either, but there is an intersection of people

… requires a certain experience and mindset, and that’s all what really counts for me

Bill_Kasdorf: we will need to recruit additional expertise

tzviya: we need volunteers to work on this: volunteer now, contact BillK or add your name to the TF page

Bill_Kasdorf: please sign up again on new wiki page

ivan: I will be traveling this week. Thierry could you create this wiki ?

tmichel: I will be on vacation starting tomorrow. Will do my best to create a new wiki for identifiers TF.

<tzviya> action Thierry create new wiki for identifiers TF

<trackbot> Created ACTION-47 - Create new wiki for identifiers tf [on Thierry Michel - due 2015-03-02].

overview of packaging spec

<ivan> http://w3ctag.github.io/packaging-on-the-web/

ivan: this is an editors note that evolves

… for the time being Jeni has left the editors role to Yves Lafon

… if we find somebody in this group or around us that is interested in being co-editor, we would be thrilled

… the hope is that packaging in general might eventually become browser-native, of course not sure that it will happen, but we know that some browser vendors are interested in it

<ivan> https://github.com/w3c/epubweb/wiki/Notes-on-Packaging

… might become the packaging format for EPUB-WEB

<tzviya> https://github.com/w3c/epubweb/wiki/Notes-on-Packaging

… three important parts: 1)packaging itself (how to combine files in a file), 2)the fragment identifier specification, although its not a main section in the doc and 3)link relationship which is defined

… packaging is multipart mime, and [http mumbo jumbo with headers]

… each part can be compressed individually

… advantage that I see from our POV is that in fact a package like this is really a small website which is put in one place, reinforced by http

… brings it even closer to webiness (multipart mime vs zip)

… for example, metadata via http headers, can be used for book purposes

… e.g. link header to create sequence of documents

… one other aspect is that it is possible to do content negotiation for e.g. language

… link relationship: defines a new type of linkage for packages for clients

… we might imagine a scenario with a lending page that via the link mechanism bootstraps getting the package

… fragment identifier: tries to solve how to get into the fragment of a document that is part of the package

… is a three-step approach: 1) find a number of candidate URIs from within the package 2) filter 3)traditional fragment as per media type of filter result

… dont know whether it covers all that we need, this is one thing we need to look at

… dave cramer posted a mail

<ivan> https://lists.w3.org/Archives/Public/www-archive/2015Feb/att-0007/mobydick.pack.zip

Bill_Kasdorf: do resources need to know what packages they belong to?

ivan: all resources are copied into the package

… http header can contain expiration rules

… you can reconstruct the original URI of a resource on the web using expiration

ivan: differences vis-a-vis zip: many of concepts rely on web approaches, relies on tech and tools that are used on the web, so if the goal is to bring the document world closer to the web, that pays off

… http header fields which are pretty powerful, and those are evolving, new headers, new header subinfo, this means that by inheritance we get http evolution in the package, we dont have to reinvent

… for example the spine may become unnecessary

<Bert> (Note that the document itself lists three advantages over zip: streamable, easier to create *well*, more metadata.)

tzviya: the document also points out that zip is hard to create well, and has limited metadata

ivan: this is much better suited for streaming than zip

brady_duga: the packaging spec lists zip drawbacks, I think the metadata is the strongest. The comment that they are hard to create to is strange: there are tools to create zips but none to create these packages, also streamability can be done easily by subsetting zip.

ivan: a bit sidetracking: I was at another conference in january, a presentation that showed that you can build up complicated things [???] by using http headers instead of RDF et.al.

brady_duga: the intent is that you still have a full html file with references as usual, more of a cache use case?

ivan: facilitating cache is clearly one use case, but downloading a whole web application is closer to our book use case

… if epub-web goes that way, epub-web would define additional definitions on top (restrictions or requirements)

<brady_duga> Sorry, lost my cell signal

tzviya: keep in mind that publications go beyond traditional books (e.g. article+data sets)
... last point is to consider whether we want to comment on this spec and what we would need to layer on top

webapps manifest

<tzviya> https://github.com/w3c/epubweb/wiki/Notes-on-Manifest-for-Web-Apps

tzviya: these are just notes, we’ve been asked to provide comments by March 5
... points to pay attention to: method for signalling installability, defines a URL for navigation scope, interesting to see how that interplays with packaging spec

… impacts deep linking

… also display mode: four specfied. And a fallback chain. Orientation specifiable for example.

… members of the manifest: details on what can be included. Because this is deveoped for apps, deals a lot with install issues. But interesting for us is the scope, display and orientation needs to be figured out if it is sufficient

ivan: two things: question: is the manifest file open in the sense that we can add additional terms, or is it closed?

tzviya: seems to be closed, but have the request for comments

ivan: scope: I didnt talk about that but packaging document also has scope, not sure how these two meet

… you can add a scope hint

dauwhe: title and stuff, by first reaction to this is that is only miminal data for apps (icon, title phrase, start)
... I dont think we want to turn this into the book metadata space

+1

… but dont see the need for publication metadata in here

ivan: +1 from me too, maybe the manifest should be open so that various application areas can add additional terms

… its not realistic for the webapps wg to provide metadata fields for everybodys needs

dauwhe: not even sure this is the appropriate place

tzviya: we really need to get moving on this

<tzviya> streampub

… also a contest for remaning epub-web

F2F

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

tzviya: book your hotel soon!