15:04:16 <RRSAgent> RRSAgent has joined #dpub-loc
15:04:16 <RRSAgent> logging to http://www.w3.org/2016/02/17-dpub-loc-irc
15:05:04 <bjdmeest> Topic: Use Cases
15:05:13 <rdeltour> ben: agenda: 1st topic use case
15:05:20 <rdeltour> ... Romain, any update on the UC?
15:05:53 <rdeltour> romain: nothing new, didn't have the time to work on it
15:06:00 <bjdmeest> Topic: ivan's musings
15:06:05 <rdeltour> ben: ok, then we can go through Ivan's document
15:06:13 <bjdmeest> https://github.com/w3c/dpub-pwp-loc/blob/gh-pages/drafts/ivans-musings.md
15:06:41 <rdeltour> bill: didn't have the chance to catch up on all this yet
15:07:05 <rdeltour> ben: we can go over it during this call, and see if we have any extra issues
15:07:28 <rdeltour> ... although we don't have Ivan or Leonard with us today
15:07:44 <rdeltour> ... let's not get too much into the details
15:08:17 <rdeltour> ... any comments ?
15:09:41 <rdeltour> romain: I have a comment
15:10:23 <rdeltour> ... not sure about the idea  that the canonical locator can be different from Lu or Lp
15:10:43 <rdeltour> ben: the idea was that a publisher doesn't have to provide an unpcked version
15:10:57 <rdeltour> ... but if there is one unpacked Lu, it can be the same as L
15:11:11 <rdeltour> bill: the problem is that it has to resolve to something
15:11:32 <rdeltour> ... the fundamental is that the locator has to resolve to a state
15:11:45 <rdeltour> ben: the pub doesn't have to be published unpacked
15:12:18 <rdeltour> the doc says "if Lu doesn't exist, then L resolves to Lp or goes via Lp to resolve to the resource"
15:13:01 <Daniel_Weck> Daniel_Weck has joined #dpub-loc
15:13:11 <rdeltour> rom: my issue is that the spec doesn't say "if Lu exists then L must be Lu", I think we should consider it
15:13:46 <rdeltour> ben: if you publish the book on a file server that is not your publishing URL, the locator can be a CDN URL
15:14:21 <rdeltour> ... maybe we can file it as an issue on the repo and further discuss it with Ivan
15:14:54 <rdeltour> ACTION: ben to file an issue about "L = Lu when Lu exists"
15:15:38 <bjdmeest> https://github.com/w3c/dpub-pwp-loc/blob/gh-pages/drafts/ivans-musings.md
15:16:51 <rdeltour> daniel: I haven't caught up on the latest discussion.
15:17:08 <rdeltour> ... it looks like we need some kind of identity in terms of locator, that's the canonical locator
15:17:41 <rdeltour> ... related to EPUB BFF as well. in the context of alignment with OWP, we're looking at how to represent an exploded / unpackaged EPUB.
15:18:04 <rdeltour> ... the diff is that resources are not expected to be ditsributed on several locations
15:18:19 <rdeltour> ... still catching up on the discussion
15:19:11 <rdeltour> ben: maybe that's an extra case that we should look into once we have the current use cases agreed upon?
15:19:51 <rdeltour> daniel: in EPUB we have the concept of "external resources", reserved for audio/video media at the moment, referenceable via external URL
15:20:04 <rdeltour> ... RS are expected to provide an on/off toggle
15:20:22 <rdeltour> ... here we're talking about any kind of resources, including content document
15:20:29 <rdeltour> ... I thought it was already under consideration
15:20:50 <rdeltour> romain: yes, it is under consideration in the existing UCs
15:21:43 <rdeltour> ben: I suggest we don't go furhter in the document if there are no other comments?
15:21:53 <rdeltour> ... let's go over the 2 questions
15:22:17 <rdeltour> ... Q1: What is the answer of S to a HTTP Get http://book.org/published-books/1 request?
15:22:44 <rdeltour> ... Ivan's proposal is that it returns at least the metadata about the PWP
15:23:03 <rdeltour> ... the req can of course also return the packed PWP or unpacked, depending on the statwe
15:23:11 <rdeltour> s/statwe/state/
15:23:34 <rdeltour> ... then when you have this metadata (M) you can use it to fetch resources inside the PWP
15:24:33 <rdeltour> .... another  question was where this metadata s/b, but the important part is that it *should* be available
15:25:22 <rdeltour> daniel: the URL is a locator and just as a URI needs to be referenced to a resource, there is a content type
15:25:42 <rdeltour> ... is the question: "what is the media type exepected from such query?"
15:25:58 <rdeltour> ... in a RESTful API the URL would consistently return the same content type
15:26:31 <rdeltour> ... the URL w/b dereferenced into a data set, not necessarily a representation of the publication but data about the publication
15:27:12 <rdeltour> ben: when you send a get req to the canonical locator you receive a PWP, but this information will also include the metadata about the PWP
15:27:19 <rdeltour> ... comparable to the manifest in EPUB
15:27:33 <rdeltour> dave: it seems the server has a lot of work to do here
15:27:52 <rdeltour> ... even if I point to the unpacked PWP which would have the manifest as JSON
15:28:33 <rdeltour> ... if there is several renditions, etc, it would have to present a UI to select among them, display the various choices. is that how it's expected to work?
15:28:54 <rdeltour> ben: in the simple case it just has a link header with Lu and Lp
15:29:08 <rdeltour> ... with this list of links you can access the one you want
15:29:34 <rdeltour> daniel: I have a slight bias in favor of simple sever / complex client rather than the other way
15:30:33 <rdeltour> ... content negotiation based on (sophisticated) HTTP headers sounds counter intuitive
15:30:58 <rdeltour> ... to me a URL should always return the same content type
15:31:54 <rdeltour> ... I would much rather use some kind of conventions
15:33:03 <rdeltour> romain: I absolutely agree
15:33:27 <rdeltour> daniel: in fact it simpler server / simpler client, it would make a simpler system
15:33:48 <rdeltour> bill: I'm not a technical guy, but I certainly agree that a simple server sounds essential
15:34:00 <rdeltour> ... PWP must be able to be transmitted everywhere
15:34:38 <rdeltour> ... and the obvious: not every web page is a PWP. you may have to do something to make it a PWP, and it's the client that can handle this specificity
15:35:24 <rdeltour> daniel: we should be able to upload a bunch of files on a sever and the RS can implement something based on that
15:35:51 <rdeltour> ... there has to be a lowest comon denominator, it's key
15:35:58 <tzviya> tzviya has joined #dpub-loc
15:36:08 <rdeltour> ben: if we have some kind of default settings
15:36:37 <rdeltour> ... like you publish some PWP on a location, you have JSON, you packed is always at book.pwp, etc
15:36:48 <rdeltour> ... a more complex case would be to override those default settings
15:37:13 <rdeltour> daniel: I would be concerned to introduce language in a spec that would give the impression that a particular naming convention should be followed
15:37:15 <Daniel_Weck> https://domain.com/book.pwp
15:37:34 <Daniel_Weck> https://domain.com/book/
15:37:47 <rdeltour> ... to humans the URL above gives the impression that it returns a packaged doc
15:37:57 <rdeltour> ... it's actually a matter of server configuration
15:38:16 <rdeltour> ... we're not trying to bind a URL convention to a content type
15:38:53 <Daniel_Weck> https://domain.com/book/manifest.json
15:39:20 <rdeltour> ... this URL above is the entry point to the PWP, the RS will know what to do with it
15:39:37 <rdeltour> ... the path convention used to differentiate the packaged/unpackeged state is completely differnt
15:39:50 <rdeltour> ... does the canonical URL has to be a parent of either or both state?
15:40:34 <rdeltour> ... in one of my comments we talk about <link rel="canonical"/> in the doc
15:43:36 <Daniel_Weck> in EPUB: META-INF/container.xml is the main entry point for exploded content, but does not contain information about where to get the packed EPUB.
15:44:12 <rdeltour> daniel: what's missing there is that the entry point does not contain info on where to get the zipped version of the publication
15:44:36 <rdeltour> ... it looks like the manifest.json would contain links to both Lu or Lp
15:45:50 <bjdmeest> so: M = Mmanifest + Mlinks
15:46:13 <rdeltour> rdetour: two things: the manifest, which describes the internal of the PWP,
15:46:36 <rdeltour> .... and extra metadata, basically Lp and Lu (which are unknown at authoring time when the manifest is created)
15:46:50 <rdeltour> ... the canonical locator should return both the manifest and Lu+Lp
15:47:00 <tzviya> q+ to talk about next steps for this grou
15:47:08 <rdeltour> ... or maybe, Lm + Lu + Lp ("Lm" being the link to the manifest)
15:47:52 <rdeltour> bill: what you say is that we must specify the behavior of the URL, not necessarilty the syntax of the URL
15:47:56 <rdeltour> daniel: yes
15:48:08 <bjdmeest> q?
15:48:45 <rdeltour> ... we live in a world where everything is linked, naming convention is not going to cut it
15:49:10 <rdeltour> tzviya: I was away last week, I caught up with Ivan earlier today.
15:49:10 <Daniel_Weck> (linked and typed)
15:49:21 <rdeltour> ... it sounds we have a general agreement here
15:49:52 <rdeltour> ... what do you think of trying to write something up closer to  "spec language"?
15:50:05 <rdeltour> daniel: we need to make sure we revisit Ivan's document
15:50:16 <rdeltour> ... some things may contradict what we just said
15:50:33 <rdeltour> ... e.g. there are no syntactical conventions
15:52:43 <rdeltour> romain: I think we have consensus about the canonical locator providing a way to return Lu and Lp and the manifest
15:53:05 <rdeltour> .... but not sure there is a consensus on the mechanism (e.g. HTTP headers, links, conneg?)
15:53:33 <rdeltour> dave: what I'd like to see is a flow chart that describes all the cases
15:53:39 <rdeltour> ... maybe even a cartoon :)
15:54:24 <rdeltour> tsviya: we don't necessarily sth as formal as a spec draft, but something to share with the group, within 10 days
15:54:50 <rdeltour> bill: what you want is a summary: "here's what we agree on, here's what still needs discussion"
15:55:37 <rdeltour> ben: it seems that 90% is agreed on, then the mechanism needs to be discussed
15:55:57 <rdeltour> ... I'll try to make that
15:56:23 <rdeltour> ... any other comments?
15:56:42 <rdeltour> ... (silence) end of the meeting
15:56:50 <tzviya> rrsagent, make logs public
15:57:02 <tzviya> rrsagent, make minutes
15:57:02 <RRSAgent> I have made the request to generate http://www.w3.org/2016/02/17-dpub-loc-minutes.html tzviya
16:56:17 <tzviya> tzviya has joined #dpub-loc
18:01:01 <rdeltour> rdeltour has joined #dpub-loc
18:03:04 <tzviya> tzviya has joined #dpub-loc
18:57:11 <tzviya> tzviya has joined #dpub-loc