13:31:57 <RRSAgent> RRSAgent has joined #dpubff
13:31:57 <RRSAgent> logging to http://www.w3.org/2016/06/27-dpubff-irc
13:32:06 <ivan> rrsagent, set draft public
13:32:06 <RRSAgent> I'm logging. I don't understand 'set draft public', ivan.  Try /msg RRSAgent help
13:32:14 <ivan> rrsagent, set log public
13:32:35 <ivan> Meeting: DPUB IG - EPUB WG Joint Meeting on manifests
13:32:40 <ivan> Chair: Tzviya
13:52:49 <tzviya> tzviya has joined #dpubff
13:55:16 <dauwhe> dauwhe has joined #dpubff
13:58:17 <ivan> Present+
13:58:19 <tzviya> present+
13:58:59 <dauwhe> present+ dauwhe
13:59:21 <tzviya> present+ George_Kerscher
13:59:38 <ivan> present+ Luc
13:59:57 <laudrain> laudrain has joined #dpubff
14:00:34 <ivan> present+ avneesh
14:00:41 <ivan> present bjdmeest
14:00:52 <laudrain> present+ Luc
14:01:27 <mgylling> mgylling has joined #dpubff
14:01:38 <ivan> present+ mgylling
14:01:44 <ivan> present+ leonard
14:02:03 <nick1> nick1 has joined #dpubff
14:02:31 <George> present+ George Kerscher
14:02:34 <ivan> present+ romain
14:02:35 <bjdmeest> bjdmeest has joined #dpubff
14:02:55 <ivan> present+ takeshi
14:03:11 <mgylling> present+ Markus
14:03:22 <bjdmeest> Present+ Ben_De_Meester
14:03:23 <mgylling> scribenick mgylling
14:03:31 <ivan> scribenick: mgylling
14:04:04 <Avneesh> Avneesh has joined #dpubff
14:04:38 <Hadrien> Hadrien has joined #dpubff
14:04:43 <lrosenth> lrosenth has joined #dpubff
14:04:44 <Avneesh> present+ Avneesh
14:04:50 <takeshi> takeshi has joined #dpubff
14:04:57 <rdeltour> rdeltour has joined #dpubff
14:04:58 <lrosenth> present+ Leonard
14:05:05 <rdeltour> present+
14:05:21 <takeshi> Present+ Takeshi_Kanai
14:05:25 <mgylling> tzviya: lets get started… short agenda sent out earlier today. Its a pretty loose agenda anyway. Dave will offer an overview BFF, then Ben on DPUB locators. We have a hard stop at the hour.
14:07:24 <mgylling> dauwhe: basic history in case people are unfamiliar… BFF has been a side project of the EPUB 3.1 WG, started out as a 3.1 deliverables, but given timing and ambition level we decided to put it on a separate track
14:09:35 <mgylling> … origins go way back. Fundamental idea is that EPUB is not the most natural thing for a web developer to deal with, or anyone else for that matter… zip object with twists and custom XML vocabularies, and so over the years there’s been some interest in how can we make it easier to understand and use. There’s been some historical precedent, there was a file system container in EPUB in 2010, some RS like Readium already work with they call “exploded
14:09:35 <mgylling> versions” where everything is unzipped, and JSON structures. Also EPUB Zero was thought experiments on simplification. And so all those threads came into it
14:09:45 <tzviya> q?
14:09:59 <dauwhe> https://github.com/dauwhe/epub31-bff
14:10:01 <lrosenth> q+
14:10:02 <mgylling> dauwhe: within 3.1 there’s an unofficial github repo
14:10:10 <lrosenth> (whenever Dave hits a breaking point)
14:10:46 <mgylling> … where the existing work has been done, major players have been Hadrien and myself. The basic idea is to unzip the EPUB and use a JSON manifest that conveys the same information as classic EPUB
14:11:36 <mgylling> … the relationship between BFF and PWP, many of us are working in both corners, I see it as experiments vs theory
14:11:49 <Bill_Kasdorf> Bill_Kasdorf has joined #dpubff
14:11:53 <mgylling> … in one way this is about playing around with the PWP and see how they look in reality
14:11:56 <tzviya> ack lr
14:11:57 <Bill_Kasdorf> Present+ Bill_Kasdorf
14:12:47 <mgylling> lrosenth: the way you described it is that it is really about authors, but what you didnt speak about is what the name seems to imply
14:12:58 <mgylling> dauwhe: I used web developer as a synonym for a RS
14:13:19 <mgylling> … the goal is to reduce the distance between those concepts to zero
14:13:45 <mgylling> lrosenth: are the two sides equal?
14:13:46 <DanielWeck_> DanielWeck_ has joined #dpubff
14:14:07 <DanielWeck_> present+ Daniel Weck
14:14:26 <mgylling> … philisophically I am trying to understand where the BFF group is coming from
14:14:55 <ivan> present+ makoto
14:15:05 <tzviya> q+
14:15:11 <ivan> present+ ric_wright
14:15:30 <mgylling> dauwhe: a tough question, philosophically I am coming from many directions, a desire for simplicity. The EPUB ecosystem can be confusing, a lot in there that exists for good historical reasons but still confusing to newcomers
14:15:45 <tzviya> ack tz
14:15:54 <mgylling> … how can we make it simpler, how can we make it closer to the web of today and tomorrow
14:16:14 <ivan> q+
14:16:46 <tzviya> ack iv
14:17:32 <mgylling> [markus got dropouts but is back now]
14:17:38 <dauwhe> https://github.com/dauwhe/epub31-bff
14:17:49 <lrosenth> q+
14:17:54 <tzviya> https://github.com/dauwhe/epub31-bff#example-1-omitting-linked-data-and-other-enhancements
14:18:02 <mgylling> dauwhe: example one from the github repo is a good example
14:18:05 <ivan> present+ garth
14:18:55 <ivan> q+
14:18:59 <tzviya> ack lr
14:19:00 <mgylling> garth: one should look at where EPUB is today and see that it is pretty succesful in trade, one would hope that BFF would be to get to a place between the packaged format and the web. Roundtrippability is a core feature
14:19:39 <tzviya> ack iv
14:19:41 <mgylling> lrosenth: as long as we keep it within the EPUB context it makes a lot of sense. What I dont understand what the context is in relation to PWP
14:20:36 <mgylling> ivan: garth just said that in the case of BFF, the roundtripping with classic EPUB was very important. In PWP we dont have that requirement [???]
14:21:17 <mgylling> tzviya: to summarize, BFF is looking for a browser friendly format with roundtrippability with classic EPUB. Lets now talk about PWP Locators
14:21:39 <mgylling> ben: we were looking for how to do common locators for different states
14:22:12 <mgylling> … without needing to know the state you are in at the moment, and transfer that locator to other users and everything keeps working
14:22:15 <bjdmeest> http://w3c.github.io/dpub-pwp/#state_definition
14:22:42 <mgylling> … we were talking about two dimensions of states; protocol and file acess as well as packed or unpacked
14:22:54 <bjdmeest> http://w3c.github.io/dpub-pwp/#locator-pwp-func
14:23:15 <mgylling> … in the end what we came up with is the canonical locator. Every PWP also includes a concept of a canonical locator that stays the same disregarding state
14:23:25 <bjdmeest> http://w3c.github.io/dpub-pwp/#manifest_algorithm
14:23:36 <mgylling> … and we would incorporate the CL as part of the PWP manifest
14:24:26 <mgylling> … and in the end we came up with a proposal of we could, starting with a GET request, we could in the end get the full publication without depending on the state that the PWP is in
14:24:26 <tzviya> q?
14:24:34 <ivan> q+
14:24:37 <tzviya> ack iv
14:25:51 <lrosenth> well that’s why we stayed away from the syntax and focused on concepts...
14:26:10 <mgylling> ivan: I think that the work on the manifest work of the two groups has been complementary. They looked at different issues. PWP did not go into details on how the manifest is encoded, for us the manifest is just a kind of buzzword for the information we need in one place. On the other hand we looked at locators, which led to questions like combining manifests
14:27:00 <mgylling> … as far as I remember the BFF work did not concentrate on these issues, the combination of the two is somewhere where we should go
14:27:27 <mgylling> … there is a work going on at W3C with webapp manifest, we have been in contact with the editor
14:27:30 <ivan> https://w3c.github.io/manifest/
14:28:21 <mgylling> … its a JSON manifest, includes a number of features that neither of the two groups didnt look at yet, relating to security, but the basic structure has an extension mechanism built-in
14:29:15 <mgylling> dauwhe: I already have a few examples that uses hybrids of webapp manifest, it seems possible to extend that with the kind of information we need
14:29:21 <lrosenth> q+
14:29:32 <tzviya> ack lr
14:29:33 <mgylling> tzviya: and feedback from Marcos indicates we will be able to do that
14:29:47 <ivan> q+
14:29:58 <mgylling> lrosenth: its not clear to me what BFF is trying to solve in the PWP context
14:30:40 <Bill_Kasdorf> q+
14:30:42 <mgylling> … in PWP do we want to be focusing on authoring or consumption friendly, or both?
14:30:42 <tzviya> ack iv
14:31:41 <mgylling> ivan: I think we have to be careful about this, but at some point in time the goal of the work we have may be EPUB 4 or 25. There are things that are already clear from the use case collection even if its not complete yet
14:32:33 <mgylling> … we already know that we have to have somewhere the information about the resources that make up the PWP, the resources have to be categorized as essential or not essential, and if you look at what BFF has done is to start to give structure to how these things should be encoded
14:32:47 <lrosenth> q+
14:32:59 <mgylling> … we still have to work on the use cases a lot, but I dont think the relationships are so wildly different that we should not think ahead
14:33:11 <tzviya> ack bi
14:33:18 <mgylling> … I think we all know that eventually we will use JSON for manifest and we need to keep that in mind
14:33:51 <mgylling> Bill: the whole point of this call is that both of these activities are in mid stream, and we want them to converge not collide, thats the whole point
14:33:59 <tzviya> ack lr
14:34:12 <mgylling> tzviya: yes, it was clear that it is time to have a joint call, it was getting absurd
14:34:55 <mgylling> lrosenth: if you go in PWP with the expectation that PWP is the future of EPUB, I think thats the major problem, we dont know that it is true, not a conversation we have had
14:35:12 <ivan> q+
14:35:35 <mgylling> … EPUB may not be the only or the best manifestation of a PWP
14:36:04 <tzviya> ack iv
14:36:59 <Bill_Kasdorf> q+
14:37:35 <mgylling> ivan: the way I was reading BFF; sure there is a high priority for roundtripping with classic EPUB, but since it became a side project the discussions became more and more general, so there is a convergence there and how that will evolve depends on a number of issues that may not even be technical
14:37:49 <tzviya> ack bi
14:38:00 <mgylling> … decision will have to be made within weeks or months
14:38:07 <lrosenth> q+
14:38:33 <mgylling> billk: roundtrippability means that they are highly related but still two different formats
14:39:13 <tzviya> ack lr
14:39:51 <mgylling> lrosenth: I’ve been under the assumption that the TPAC F2F was to do the deep technical dive into PWP. Do we need to do something before TPAC?
14:40:06 <mgylling> ivan: “before TPAC” means vacations and sunshine…
14:41:09 <lrosenth> q+
14:41:12 <tzviya> ack lr
14:41:18 <mgylling> tzviya: we have a few proposed manifests, we have the PWP locators proposal, there are a variety of issues we could discuss but lets start with these two
14:42:11 <mgylling> lrosenth: your comment about the removal of CFI for linking in, I have a call with the UK government on the topic of open data and document formats, and they ability to link in is one of the attributes of this
14:42:53 <mgylling> garth: we didnt remove CFIs per se, only linking out from EPUBs was removed because it had zero adoption
14:43:07 <ivan> q+
14:43:09 <mgylling> … its still the way you link externally into an EPUB
14:44:03 <tzviya> ack iv
14:44:52 <mgylling> ivan: let me push a very specific technical issue to the BFF guys. One of the features we thought was important in PWP locators is the fact that the final manifest can be the combination of several manifests that are at different places.
14:45:48 <mgylling> … and of course that makes things a bit more complicated. Is this something that BFF considers being important, how does that modify what is out there? At the moment the biggest tech difference between the two approaches
14:46:13 <mgylling> lrosenth: the context is that certain publications cannot be modified and would have to exist as separate entities
14:47:38 <mgylling> hadrien: we havent considered that, I think it is certainly doable, the way we see it its possible for anyone to point to any resource on the web and make a publication of it, so in BFF its not combining manifest, but linking to resources
14:48:02 <mgylling> … we have mechanisms to discover manifests
14:48:10 <Bill_Kasdorf> +1
14:48:18 <mgylling> … one HTML resource can be part of any number of publications
14:48:41 <lrosenth> q+
14:49:57 <mgylling> ivan: we will have to revisit this in our own use case work, we ran into this issue not only due to the locator structures, combining two JSON structures cannot be done purely mechanically, how you combine may be depend on semantics of keys etc, if we can avoid it is fine
14:49:59 <tzviya> ack lr
14:50:35 <Hadrien> q+
14:50:47 <mgylling> lrosenth: just to add a little more to the context, we felt the need to do this, its an include followed by a set of overrides
14:51:01 <mgylling> … for example adding annotations, or replacing an image
14:51:21 <tzviya> ack ha
14:51:34 <mgylling> … we’ve seen the need for merge and replace in multiple use cases
14:52:14 <lrosenth> q+
14:52:15 <mgylling> hadrien: combining manifests is extremely complex, its very easy however to combine multiple resources, merging metadata is hard or impossible, merging reading order is hard or impossible
14:52:58 <mgylling> … I strongly believe in our core idea of keeping it very simple, the teacher who adds annotations or changes an image would create a new manifest instead
14:53:25 <tzviya> ack lr
14:53:35 <mgylling> ivan: yes, we’ve left it largely open, but we have to look hard at the use cases to see whether its necessary or not
14:54:20 <mgylling> lrosenth: we focused only on resources, and we havent gotten to metadata and reading order yet
14:55:13 <mgylling> tzviya: the original point that Dave made, the BFF group has gotten to practicalities whereas PWP has been more about use cases. I think we are at a good point to talk about where to go from here. What are our next steps?
14:55:15 <Bill_Kasdorf> q+
14:55:20 <tzviya> ack bi
14:55:41 <mgylling> billK: there should at least be some kind of regular joint meetings between these two groups
14:55:45 <ivan> q+
14:55:48 <tzviya> ack iv
14:57:30 <tzviya> PWP Use Cases: http://w3c.github.io/dpub-pwp-ucr/
14:57:32 <lrosenth> q+
14:57:53 <mgylling> ivan: yes of course, the work in the IG is now really concentrating on the use cases, for very practical reasons as well, but we have already heard that without use cases this work is meaningless. I would love, when our use cases document becomes more mature, that the use cases be looked at also from a BFF POV. Eventually, at some point in time, 6-7 months from now, if the IDPF-W3C combination will happen, these efforts will be merged anyway.
14:58:36 <mgylling> garth: the IDPF-W3C discussions will be more clear by TPAC time.
14:59:03 <ivan> rrsagent, draft minutes
14:59:03 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/27-dpubff-minutes.html ivan
14:59:07 <mgylling> tzviya: please look at the use cases document if you havent yet
14:59:15 <tzviya> ack lr
14:59:53 <mgylling> lrosenth: I agree completely. My hope has been that the TPAC agenda was going to be to start applying conrete technical decisions against the use cases
15:00:10 <mgylling> … see one or more directions on how we want to move things forward
15:00:27 <mgylling> tzviya: we need to close now
15:00:34 <ivan> rrsagent, draft minutes
15:00:34 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/27-dpubff-minutes.html ivan
15:00:35 <George> bye
15:00:35 <mgylling> thanks all!
15:00:49 <laudrain> laudrain has left #dpubff
15:01:18 <bjdmeest> bjdmeest has left #dpubff
17:04:44 <Zakim> Zakim has left #dpubff