See also: IRC log
ben: agenda: 1st topic use
case
... Romain, any update on the UC?
romain: nothing new, didn't have the time to work on it
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[End of scribe.perl diagnostic output]