W3C

DPUB IG Locator Task Force Call

10 Feb 2016

Agenda

See also: IRC log

Attendees

Present
Bill Kasdorf, Ivan Herman, Luc Audrain (laudrain), Ben De Meester, Markus Gylling, Matt Garrish, Leonard Rosenthol
Regrets
Tzviya, Romain
Chair
Ben De Meester
Scribe
laudrain

Contents


Ben updates on use cases?

<bjdmeest> https://github.com/w3c/dpub-pwp-loc/commit/87a6e229c948806ed0e0f973e9ee0aba090249e3

document on github repo

canonical URL independant of the PWP state

LR: protocol?

LR document line 11

LR: protocol is irrelevant in relative URL

Ivan: add the comment he made

definition of locator : ok

Ivan: a PWP is also always in a certain state

LR: what does the locator returns?

Ivan: content-type

LR: state isn’t a rest request
... what is return is independant of state

BEn: change may by is

LR resource or relative locator?

Ivan: resource could be added in ()

LR: a PWP contains a second PWP , what is the locator

Ivan: leave as is for now

Ivan: put a note on precise terminology points to resource

Ivan: a canonical locator is an absolute and state independant locator

LR: a canonical locator is to a PWP and to its resources

Ben: Reading system

LR: what does the RS do with locators?

BEn text as its?

Consensus

Ben: PWP assumed to be published unpacked

Ivan: why? locator independnat from the state

LR: « unpacked folder structure »

When managing locator, conceptually PWP is looked as if it was unpacked

Ben ; PWP doesn’t physically need to be unpacked

Bill: necessarily online?

Ivan: packed or unpacked, the locator looks at the resource conceptually

LR: canonical locator : who is the distributor of the content?

Ivan: this is addressed later in the document
... the canonical loc change when the PWP is copied
... book on the local file, the original loc is a question of implementation choice

LR: section 47-50 shuld be placed somewhere else

Ben questions

Ben Q1

Ivan: example fetching in the file isn’t a good example
... moving from the canonical to the actual locator is a question

LR: the URL has to go through the metadata to the internal resource

Ivan: mapping has to happen from the Can Url to the particular state on my disk

LR: Where?

iIvan: ideally, typing in my browser the Can Url, it goes the the server and get the resource

LR case where the server has to map the packed to the unpacked resource

LR: how does one find the resources?

Ivan: we don’t have the problem of external resources, but is more upsream

LR: : the RS reads the publication. Do we need to define a PWP processor?
... a RS is not in the server

ivan: displaying and other processes are in the same black box

Ben: adding an extra definition for pwp processor
... the user interacts with the RS
... PWP packed and unpacked on the server, the can loc has to get one of the 2 resources

Ben Q4

Ivan: question Q4bis : locator to a specific state?

LR: it is the responsibility of the PWP proc

Ivan: right

LR: the PWP proc knows how to map to the data

Ivan: this is content negotiation
... from a zip and a folder, what does the PWP Proc do?

LR: for a single resource, the URL returns the resource data, we have no choice

Ivan: any server will throw a non existent error
... the server decides today even without any extension (html ot xhtml)
... extra processing on th PWP proc side : to replace the Can Loc to the State URL

LR: « properly configured server » : a specific configuration
... apache server all have addons
... we never said that we should not have addons

Ivan: we should avoid extensions

LR: the server has always to be configured some way

Ben: put separately this issue?
... processing / content negotiation. Agreed on those functionalities?

Ben to make document revision

Ivan: setup is a fundamental question

Luc: it reminds of service workers

Ivan: SW may be an issue to not server extensions

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/11 09:20:44 $