Use Cases

ben: agenda: 1st topic use case
... Romain, any update on the UC?

romain: nothing new, didn't have the time to work on it

ivan's musings

ben: ok, then we can go through Ivan's document

<bjdmeest> https://github.com/w3c/dpub-pwp-loc/blob/gh-pages/drafts/ivans-musings.md

bill: didn't have the chance to catch up on all this yet

ben: we can go over it during this call, and see if we have any extra issues
... although we don't have Ivan or Leonard with us today
... let's not get too much into the details
... any comments ?

romain: I have a comment
... not sure about the idea that the canonical locator can be different from Lu or Lp

ben: the idea was that a publisher doesn't have to provide an unpcked version
... but if there is one unpacked Lu, it can be the same as L

bill: the problem is that it has to resolve to something
... the fundamental is that the locator has to resolve to a state

ben: the pub doesn't have to be published unpacked

the doc says "if Lu doesn't exist, then L resolves to Lp or goes via Lp to resolve to the resource"

rom: my issue is that the spec doesn't say "if Lu exists then L must be Lu", I think we should consider it

ben: if you publish the book on a file server that is not your publishing URL, the locator can be a CDN URL
... maybe we can file it as an issue on the repo and further discuss it with Ivan

<scribe> ACTION: ben to file an issue about "L = Lu when Lu exists" [recorded in http://www.w3.org/2016/02/17-dpub-loc-minutes.html#action01]

<bjdmeest> https://github.com/w3c/dpub-pwp-loc/blob/gh-pages/drafts/ivans-musings.md

daniel: I haven't caught up on the latest discussion.
... it looks like we need some kind of identity in terms of locator, that's the canonical locator
... related to EPUB BFF as well. in the context of alignment with OWP, we're looking at how to represent an exploded / unpackaged EPUB.
... the diff is that resources are not expected to be ditsributed on several locations
... still catching up on the discussion

ben: maybe that's an extra case that we should look into once we have the current use cases agreed upon?

daniel: in EPUB we have the concept of "external resources", reserved for audio/video media at the moment, referenceable via external URL
... RS are expected to provide an on/off toggle
... here we're talking about any kind of resources, including content document
... I thought it was already under consideration

romain: yes, it is under consideration in the existing UCs

ben: I suggest we don't go furhter in the document if there are no other comments?
... let's go over the 2 questions
... Q1: What is the answer of S to a HTTP Get http://book.org/published-books/1 request?
... Ivan's proposal is that it returns at least the metadata about the PWP
... the req can of course also return the packed PWP or unpacked, depending on the state
... then when you have this metadata (M) you can use it to fetch resources inside the PWP
... another question was where this metadata s/b, but the important part is that it *should* be available

daniel: the URL is a locator and just as a URI needs to be referenced to a resource, there is a content type
... is the question: "what is the media type exepected from such query?"
... in a RESTful API the URL would consistently return the same content type
... the URL w/b dereferenced into a data set, not necessarily a representation of the publication but data about the publication

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
... comparable to the manifest in EPUB

dave: it seems the server has a lot of work to do here
... even if I point to the unpacked PWP which would have the manifest as JSON
... 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?

ben: in the simple case it just has a link header with Lu and Lp
... with this list of links you can access the one you want

daniel: I have a slight bias in favor of simple sever / complex client rather than the other way
... content negotiation based on (sophisticated) HTTP headers sounds counter intuitive
... to me a URL should always return the same content type
... I would much rather use some kind of conventions

romain: I absolutely agree

daniel: in fact it simpler server / simpler client, it would make a simpler system

bill: I'm not a technical guy, but I certainly agree that a simple server sounds essential
... PWP must be able to be transmitted everywhere
... 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

daniel: we should be able to upload a bunch of files on a sever and the RS can implement something based on that
... there has to be a lowest comon denominator, it's key

ben: if we have some kind of default settings
... like you publish some PWP on a location, you have JSON, you packed is always at book.pwp, etc
... a more complex case would be to override those default settings

daniel: I would be concerned to introduce language in a spec that would give the impression that a particular naming convention should be followed

<Daniel_Weck> https://domain.com/book.pwp

<Daniel_Weck> https://domain.com/book/

daniel: to humans the URL above gives the impression that it returns a packaged doc
... it's actually a matter of server configuration
... we're not trying to bind a URL convention to a content type

<Daniel_Weck> https://domain.com/book/manifest.json

daniel: this URL above is the entry point to the PWP, the RS will know what to do with it
... the path convention used to differentiate the packaged/unpackeged state is completely differnt
... does the canonical URL has to be a parent of either or both state?
... in one of my comments we talk about <link rel="canonical"/> in the doc

<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.

daniel: what's missing there is that the entry point does not contain info on where to get the zipped version of the publication
... it looks like the manifest.json would contain links to both Lu or Lp

<bjdmeest> so: M = Mmanifest + Mlinks

rdetour: two things: the manifest, which describes the internal of the PWP,
... and extra metadata, basically Lp and Lu (which are unknown at authoring time when the manifest is created)
... the canonical locator should return both the manifest and Lu+Lp
... or maybe, Lm + Lu + Lp ("Lm" being the link to the manifest)

bill: what you say is that we must specify the behavior of the URL, not necessarilty the syntax of the URL

daniel: yes
... we live in a world where everything is linked, naming convention is not going to cut it

tzviya: I was away last week, I caught up with Ivan earlier today.

<Daniel_Weck> (linked and typed)

tzviya: it sounds we have a general agreement here
... what do you think of trying to write something up closer to "spec language"?

daniel: we need to make sure we revisit Ivan's document
... some things may contradict what we just said
... e.g. there are no syntactical conventions

romain: I think we have consensus about the canonical locator providing a way to return Lu and Lp and the manifest
... but not sure there is a consensus on the mechanism (e.g. HTTP headers, links, conneg?)

dave: what I'd like to see is a flow chart that describes all the cases
... maybe even a cartoon :)

tsviya: we don't necessarily sth as formal as a spec draft, but something to share with the group, within 10 days

bill: what you want is a summary: "here's what we agree on, here's what still needs discussion"

ben: it seems that 90% is agreed on, then the mechanism needs to be discussed
... I'll try to make that
... any other comments?
... (silence) end of the meeting

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/statwe/state/
No ScribeNick specified.  Guessing ScribeNick: rdeltour
Inferring Scribes: rdeltour

WARNING: No "Present: ... " found!
Possibly Present: Daniel_Weck ben bill bjdmeest daniel dave https rdetour rom romain so tsviya tzviya
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 17 Feb 2016
Guessing minutes URL: http://www.w3.org/2016/02/17-dpub-loc-minutes.html
People with action items: ben