15:01:29 <RRSAgent> RRSAgent has joined #dpub-loc
15:01:29 <RRSAgent> logging to http://www.w3.org/2016/03/02-dpub-loc-irc
15:01:36 <ivan> rrsagent, set log public
15:01:39 <Zakim> Zakim has joined #dpub-loc
15:02:01 <Bill_Kasdorf> Bill_Kasdorf has joined #dpub-loc
15:02:51 <Bill_Kasdorf> Is anybody here? I'm not hearing anybody on the phone or seeing any activity on the IRC.
15:03:38 <rdeltour> present+
15:03:39 <Bill_Kasdorf> present+ Bill_Kasdorf
15:05:19 <dauwhe> present+
15:05:36 <bjdmeest> scribenick bjdmeest
15:06:01 <bjdmeest> TOPIC: http://w3c.github.io/dpub-pwp-loc/drafts/PWPClient2.png
15:07:18 <bjdmeest> ivan: reason: Client-side PWP processor responsibilities must be specified (related to the locator issue)
15:07:23 <bjdmeest> ... having a diagram helps
15:07:45 <bjdmeest> ... emphasize: this is the only part that needs a specification.
15:07:54 <bjdmeest> ... how the server is set-up is not prescribed
15:08:06 <bjdmeest> ... the diagram can be set up in various places and various ways
15:08:20 <bjdmeest> ... that is not the job of the PWP spec
15:08:39 <bjdmeest> ... [about the metadata part] this can come from various places
15:08:43 <bjdmeest> ... the processor combines them
15:09:03 <bjdmeest> ... if the publisher wants to publish the docs in various places on his website
15:09:14 <bjdmeest> ... the should be a way to get the metadata independently from the content
15:09:53 <bjdmeest> ... one thing: the first step (left side), after HTTP GET: processor has to do both of these
15:10:16 <bjdmeest> ... if there is a better way of visualizing this, please tell me
15:10:41 <bjdmeest> ... the diagram concentrates on how the metadata can be required
15:11:00 <bjdmeest> ... 2 main branches: the metadata of the PWP, and the metadata of the HTTP Link Header
15:11:26 <bjdmeest> ... without modifying the publication, some extra metadata is added via HTTP Link header
15:12:03 <bjdmeest> ... about bottom side: if Link Header present: Link Header refers to additional Mextra
15:12:42 <bjdmeest> ... you get on the wire the manifest which includes metadata
15:12:57 <bjdmeest> ... so you get the manifest, extract the metadata, and get Mextra
15:13:15 <bjdmeest> ... the top part is about what you can get depending on the returned payload
15:13:37 <bjdmeest> ... at least three types (besides HTML, you might get SVG, etc)
15:13:49 <bjdmeest> ... it can also be directly the manifest file or the packages file
15:14:14 <bjdmeest> ... package is easiest: structure of package defines where to get the manifest
15:14:43 <bjdmeest> ... directly the manifest in some format (e.g., JSON), you can extract the metadata from there
15:14:58 <bjdmeest> ... when you get the HTML, one option is getting via the <link> element
15:15:09 <bjdmeest> ... in the end, I combine
15:15:20 <bjdmeest> ... there are alternatives that aren't here yet
15:16:07 <bjdmeest> ... 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
15:16:40 <bjdmeest> ... this diagram does not reflect well that these two things have to be both done
15:16:59 <bjdmeest> ... also: what it means exactly when I combine the metadata: what is the priority?
15:17:26 <bjdmeest> ... e.g., I have Lp both in Mpartial and Mextra: what would have priority?
15:17:51 <bjdmeest> ... it is only a partial diagram of the total discussion
15:18:19 <bjdmeest> ... going from locators to resources is documented, and not in the diagram
15:18:32 <ivan> q?
15:19:01 <rdeltour> q+
15:20:18 <bjdmeest> bjdmeest: Mextra can overlap Mpartial? so Mextra cannot be necessary?
15:20:34 <bjdmeest> ivan: yes, there are multiple alternatives of setting this up
15:20:51 <bjdmeest> rdeltour: what is the difference between, M, Mextra, Mpartial?
15:21:12 <bjdmeest> ivan: about the locator discussion: the various locators for the various states are part of the metadata
15:21:41 <bjdmeest> ... when we discuss these things in the BFF, there is discussion about different kinds of metadata (author, etc.)
15:21:53 <bjdmeest> ... spine is there not described as metadata
15:22:08 <bjdmeest> ... I kept a difference between manifest and metadata
15:22:28 <bjdmeest> ... question is: is the spine a metadata yes or no, do we need to make a difference?
15:22:45 <bjdmeest> dauwhe: there is still an EPUB mindset (e.g., thinking in opf terms)
15:23:01 <bjdmeest> ivan: if you think it is irrevelevant to keep that difference, I can change the diagram
15:23:40 <bjdmeest> bill: so would you say: one side is locators, other side is metadata?
15:23:59 <bjdmeest> ivan: in our discussion, yes, but if I put aside the discussion between manifest and metadata
15:24:21 <bjdmeest> ... this can be useful for other PWP fields as well
15:24:31 <bjdmeest> bill: so at the far right is the complete metadata for the publication?
15:24:33 <bjdmeest> ivan: yes
15:25:10 <bjdmeest> rdeltour: for the PWP, the list of files is important (as metadata), I would prefer only using manifest
15:25:39 <bjdmeest> bill: I also like that: Mextra typically consists of Lu and Lp, Mcomplete MUST contain Lu and Lp
15:26:09 <bjdmeest> ivan: so we simplify the diagram by not making a distinction between metadata and manifest
15:26:25 <bjdmeest> ... there is also the possibility to embed the manifest inside the HTML payload
15:26:44 <bjdmeest> ... in general, I think it is a good idea to keep this possibility
15:26:59 <bjdmeest> ... atm I don't see why we would disallow that
15:27:11 <bjdmeest> ... I will not add a separate branch for SVG
15:27:15 <bjdmeest> dauwhe: makes sense
15:27:24 <bjdmeest> ivan: an implementation can extrapolate for SVG
15:29:03 <bjdmeest> ivan: possibility of a dropbox server works, just as content negotiation, this is orthogonal to this
15:29:05 <rdeltour> q+
15:29:27 <bjdmeest> rdeltour: difference between Mpartial and Mextra
15:29:52 <bjdmeest> ... can <link> elements contain Lu and Lp, or do they have to be in Mextra?
15:30:00 <bjdmeest> ivan: I wonder about that too
15:30:33 <bjdmeest> 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
15:30:42 <bjdmeest> ... they can all hold the same information
15:30:59 <bjdmeest> ivan: I agree, but on the other hand, I am afraid of a spaghetti-like specification
15:31:06 <bjdmeest> ... which allows various options all over the place
15:31:28 <bjdmeest> rdeltour: my concern is more about using 'partial' and 'extra': do they have the same weight?
15:31:35 <bjdmeest> ivan: I will use M1 and M2
15:31:50 <bjdmeest> ... it is just a combination of the two
15:32:02 <bjdmeest> ... but the question of priority still needs to be answered at some point
15:32:13 <bjdmeest> ... in the doc, we should list some open issues
15:32:37 <bjdmeest> ... e.g., allowing extra <link> elements that contain Lu and Lp
15:32:48 <bjdmeest> ... in the grand scheme, we need more complex information
15:33:00 <bjdmeest> ... to me, it sounds more logical to keep it in the manifest
15:33:07 <bjdmeest> ... but lets leave that as an open issue
15:34:18 <bjdmeest> rdeltour: what kind of spec should we write? separate or included?
15:34:23 <bjdmeest> ... how detailed must we be?
15:34:31 <bjdmeest> ivan: that's up to us
15:35:03 <bjdmeest> ... what I would do, is write all we have in a separate doc (including this diagram)
15:35:15 <bjdmeest> ... it might be too big for the PWP draft as it stands, maybe not
15:35:23 <bjdmeest> ... whatever we produce is not final
15:35:45 <bjdmeest> ... the current PWP draft will change, because everything more use case-ish will be put in the use case document
15:36:06 <bjdmeest> ... atm the PWP doc contains the terminology part and then some more reflections, not much more
15:36:22 <bjdmeest> ... eventually, it may be that merging locators in PWP doc makes sense
15:36:29 <bjdmeest> ... atm, we can keep a separate doc
15:36:49 <bjdmeest> rdeltour: a writeup of all agreements is definitely good to have
15:37:59 <bjdmeest> ivan: combination of the initial draft + musings + open issues, that's a good first step
15:38:57 <bjdmeest> ivan: question: what is the usual way that something has to be done in parallel by a processor?
15:39:28 <bjdmeest> bill: I think the current way is pretty sufficient
15:39:43 <bjdmeest> ... coming from a diamond block is a choice, but you come from a square block, so good
15:40:37 <bjdmeest> bill: the common tool is visio, I can check visio
15:40:45 <bjdmeest> ... I think you use the same syntax
15:40:51 <bjdmeest> ivan: I used draw.io
15:41:47 <bjdmeest> ... company is JGraph limited (of UK)
15:42:05 <bjdmeest> ... I accept presents of the software
15:42:31 <bjdmeest> ivan: alternatives are welcome
15:44:21 <bjdmeest> bill: rectangle is a process, diamond is a decision, so you are good with the rectangle
15:46:34 <ivan> rrsagent, draft minutes
15:46:34 <RRSAgent> I have made the request to generate http://www.w3.org/2016/03/02-dpub-loc-minutes.html ivan
15:50:51 <ivan> Meeting: DPUB Locator TF Telco
15:51:02 <ivan> Chair: Ben De Meester
15:51:55 <ivan> Present BillK, RDeltour, Ben_De_Meester, Ivan_Herman
15:52:04 <ivan> rrsagent, draft minutes
15:52:04 <RRSAgent> I have made the request to generate http://www.w3.org/2016/03/02-dpub-loc-minutes.html ivan
17:34:03 <Zakim> Zakim has left #dpub-loc
17:54:45 <ivan> rrsagent, bye
17:54:45 <RRSAgent> I see no action items