DPUB Locator TF Telco

http://w3c.github.io/dpub-pwp-loc/drafts/PWPClient2.png

ivan: reason: Client-side PWP processor responsibilities must be specified (related to the locator issue)
... having a diagram helps
... emphasize: this is the only part that needs a specification.
... how the server is set-up is not prescribed
... the diagram can be set up in various places and various ways
... that is not the job of the PWP spec
... [about the metadata part] this can come from various places
... the processor combines them
... if the publisher wants to publish the docs in various places on his website
... the should be a way to get the metadata independently from the content
... one thing: the first step (left side), after HTTP GET: processor has to do both of these
... if there is a better way of visualizing this, please tell me
... the diagram concentrates on how the metadata can be required
... 2 main branches: the metadata of the PWP, and the metadata of the HTTP Link Header
... without modifying the publication, some extra metadata is added via HTTP Link header
... about bottom side: if Link Header present: Link Header refers to additional Mextra
... you get on the wire the manifest which includes metadata
... so you get the manifest, extract the metadata, and get Mextra
... the top part is about what you can get depending on the returned payload
... at least three types (besides HTML, you might get SVG, etc)
... it can also be directly the manifest file or the packages file
... package is easiest: structure of package defines where to get the manifest
... directly the manifest in some format (e.g., JSON), you can extract the metadata from there
... when you get the HTML, one option is getting via the <link> element
... in the end, I combine
... there are alternatives that aren't here yet
... e.g., an extra branch: in the HTML file, the manifest can be embedded, instead of HTTP GET the manifest, you could extract the manifest
... this diagram does not reflect well that these two things have to be both done
... also: what it means exactly when I combine the metadata: what is the priority?
... e.g., I have Lp both in Mpartial and Mextra: what would have priority?
... it is only a partial diagram of the total discussion
... going from locators to resources is documented, and not in the diagram

bjdmeest: Mextra can overlap Mpartial? so Mextra cannot be necessary?

ivan: yes, there are multiple alternatives of setting this up

rdeltour: what is the difference between, M, Mextra, Mpartial?

ivan: about the locator discussion: the various locators for the various states are part of the metadata
... when we discuss these things in the BFF, there is discussion about different kinds of metadata (author, etc.)
... spine is there not described as metadata
... I kept a difference between manifest and metadata
... question is: is the spine a metadata yes or no, do we need to make a difference?

dauwhe: there is still an EPUB mindset (e.g., thinking in opf terms)

ivan: if you think it is irrevelevant to keep that difference, I can change the diagram

bill: so would you say: one side is locators, other side is metadata?

ivan: in our discussion, yes, but if I put aside the discussion between manifest and metadata
... this can be useful for other PWP fields as well

bill: so at the far right is the complete metadata for the publication?

ivan: yes

rdeltour: for the PWP, the list of files is important (as metadata), I would prefer only using manifest

bill: I also like that: Mextra typically consists of Lu and Lp, Mcomplete MUST contain Lu and Lp

ivan: so we simplify the diagram by not making a distinction between metadata and manifest
... there is also the possibility to embed the manifest inside the HTML payload
... in general, I think it is a good idea to keep this possibility
... atm I don't see why we would disallow that
... I will not add a separate branch for SVG

dauwhe: makes sense

ivan: an implementation can extrapolate for SVG
... possibility of a dropbox server works, just as content negotiation, this is orthogonal to this

rdeltour: difference between Mpartial and Mextra
... can <link> elements contain Lu and Lp, or do they have to be in Mextra?

ivan: I wonder about that too

rdeltour: there are several ways to describe a manifest, any of these is potentially relevant, the <link> header is not necessarily used in favor of the other
... they can all hold the same information

ivan: I agree, but on the other hand, I am afraid of a spaghetti-like specification
... which allows various options all over the place

rdeltour: my concern is more about using 'partial' and 'extra': do they have the same weight?

ivan: I will use M1 and M2
... it is just a combination of the two
... but the question of priority still needs to be answered at some point
... in the doc, we should list some open issues
... e.g., allowing extra <link> elements that contain Lu and Lp
... in the grand scheme, we need more complex information
... to me, it sounds more logical to keep it in the manifest
... but lets leave that as an open issue

rdeltour: what kind of spec should we write? separate or included?
... how detailed must we be?

ivan: that's up to us
... what I would do, is write all we have in a separate doc (including this diagram)
... it might be too big for the PWP draft as it stands, maybe not
... whatever we produce is not final
... the current PWP draft will change, because everything more use case-ish will be put in the use case document
... atm the PWP doc contains the terminology part and then some more reflections, not much more
... eventually, it may be that merging locators in PWP doc makes sense
... atm, we can keep a separate doc

rdeltour: a writeup of all agreements is definitely good to have

ivan: combination of the initial draft + musings + open issues, that's a good first step
... question: what is the usual way that something has to be done in parallel by a processor?

bill: I think the current way is pretty sufficient
... coming from a diamond block is a choice, but you come from a square block, so good
... the common tool is visio, I can check visio
... I think you use the same syntax

ivan: I used draw.io
... company is JGraph limited (of UK)
... I accept presents of the software
... alternatives are welcome

bill: rectangle is a process, diamond is a decision, so you are good with the rectangle