15:41:44 <RRSAgent> RRSAgent has joined #pwg
15:41:44 <RRSAgent> logging to https://www.w3.org/2018/04/30-pwg-irc
15:41:45 <ivan> rrsagent, set log public
15:41:45 <ivan> Meeting: Publishing Working Group Telco
15:41:45 <ivan> Chair: Tzviya
15:41:45 <ivan> Date: 2018-04-30
15:41:45 <ivan> Regrets+ MustLazMS, BenWaltersMS, laudrain, tcole, makoto
15:41:45 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2018Apr/0035.html
15:41:46 <ivan> ivan has changed the topic to: Meeting Agenda 2018-04-30: https://lists.w3.org/Archives/Public/public-publ-wg/2018Apr/0035.html
15:42:57 <wolfgang> wolfgang has joined #pwg
15:53:17 <NickRuffilo> NickRuffilo has joined #pwg
15:55:38 <dkaplan3> dkaplan3 has joined #pwg
15:56:47 <jasminemulliken> jasminemulliken has joined #pwg
15:57:15 <derekJackson> derekJackson has joined #pwg
15:57:16 <Avneesh> Avneesh has joined #pwg
15:57:35 <rkwright> rkwright has joined #pwg
15:57:42 <mattg> mattg has joined #pwg
15:58:22 <jbuehler> jbuehler has joined #pwg
15:58:33 <ivan> present+
15:58:37 <Evan_Owens> Evan_Owens has joined #pwg
15:58:38 <dauwhe> present+ dauwhe
15:58:49 <rkwright> present+ rkwright
15:58:50 <wolfgang> present+ wolfgang
15:58:50 <NickRuffilo> present+
15:58:56 <laurentlemeur> laurentlemeur has joined #pwg
15:59:02 <dkaplan3> present+
15:59:04 <laurentlemeur> present+ laurent
15:59:11 <adamsisco> adamsisco has joined #pwg
15:59:29 <jasminemulliken> present+
15:59:34 <adamsisco> present+
16:00:03 <JunGamo> JunGamo has joined #pwg
16:00:15 <mattg> present+
16:00:41 <franco> franco has joined #pwg
16:00:52 <zheng_xu> zheng_xu has joined #pwg
16:01:13 <tzviya> present+
16:01:22 <franco> present+
16:01:24 <Bill_Kasdorf> Bill_Kasdorf has joined #pwg
16:01:31 <Avneesh> present+
16:01:49 <zheng_xu> present+
16:01:57 <ivan> present+ derekJackson
16:02:05 <pkra> pkra has joined #pwg
16:02:12 <JunGamo> present+
16:02:13 <pkra> present+
16:02:54 <lsullam> lsullam has joined #pwg
16:02:57 <ivan> present+ jbuehler
16:03:00 <lsullam> present+
16:03:22 <BenSchroeter> BenSchroeter has joined #pwg
16:03:27 <BenSchroeter> present+
16:03:41 <ivan> present+ zheng_xu
16:03:42 <ivan> present+ george
16:04:03 <NickRuffilo> Tzviya: Lets get started - First the meeting notes - Any comments?
16:04:04 <tzviya> minutes: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-04-23-pwg.html
16:04:18 <ivan> resolved: last week's minutes accepted
16:04:38 <ivan> TopicL affordances TF meeting
16:04:44 <NickRuffilo> ...: Minutes approved.  The affordances task for met on Friday.  Jasmine, Mateos, anything to report?
16:04:48 <jasminemulliken> https://www.w3.org/2018/04/26-pwgatf-minutes.html
16:04:48 <tzviya> s/TopicL/Topic:
16:05:11 <jasminemulliken> https://github.com/w3c/wpub/issues/143#issuecomment-374888961
16:05:48 <marisa> marisa has joined #pwg
16:05:54 <derekJackson> Thank you
16:06:02 <NickRuffilo> Jasmine: We have the minutes for that meeting.  We went through the affordances list.  We decided that we would approve the template that Zheng Xu made.  We're using this template so that we have something to talk about in the face to face.  We have a couple already drafted out.  Time-based media and text, or offline reading capabilities.  Feel free to comment or add to anything here
16:06:03 <bigbluehat> present+
16:06:16 <josh> josh has joined #pwg
16:06:18 <marisa> present+
16:06:26 <josh> present+
16:06:27 <tzviya> q?
16:06:28 <NickRuffilo> Tzviya: There were a few items we were possibly going to close...  Do we want to discuss now?
16:06:55 <Bill_Kasdorf> present+
16:06:57 <NickRuffilo> George: Do you need the template posted somewhere?  I sent it to the list.
16:07:00 <HeatherF> HeatherF has joined #pwg
16:07:09 <cmaden2> cmaden2 has joined #pwg
16:07:15 <NickRuffilo> Jasmine: The template is sitting inside issue #143 - which should be in the spec for affordances.
16:07:31 <cmaden2> present+ Chris_Maden
16:07:43 <NickRuffilo> Tzviya: Would it help for others to have it outside github?  Where it is just text?
16:07:56 <NickRuffilo> ...: Ivan suggests it gets put on the wiki.
16:07:58 <Hadrien> Hadrien has joined #pwg
16:08:04 <Hadrien> present+
16:08:43 <NickRuffilo> ...: Hopefully we'll be adding to these affordances - like Jasmine suggests, we'll have a robust set of affordances to discuss at the F2F.  It should be on the agenda for next week.  The next item is the gaps from 'classic' epub and our existing documentation.  Hadrien opened an issue...
16:08:46 <ivan> Topic: Gaps from "classic" EPUB
16:08:48 <tzviya> topic: gaps from classic EPUB
16:08:48 <tzviya> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-04-23-pwg.html
16:10:04 <NickRuffilo> ...: What we need to do is break this down to a number of issues and identify where thye go.  We're not duplicating terminology, we're duplicating functionality.  We need to figure out where things go - infoset, navigation, etc.  Once we figure that out, we can figure out which repository things belong and where it belongs in the document.  We decided that lots of things that could be debated, so
16:10:04 <NickRuffilo> we'll start with a discussion today about how to split things up.
16:10:34 <tzviya> https://github.com/w3c/wpub/issues/176#issuecomment-382634697
16:10:36 <duga> duga has joined #pwg
16:10:42 <duga> present+
16:11:04 <garth> garth has joined #pwg
16:11:07 <NickRuffilo> ...: There is the issue - with the GAP analysis.  If anyone else finds gaps, add them.  So we need to go through and determine if they go to WP, PWP, or epub4
16:11:20 <garth> present+ Garth
16:11:23 <tzviya> the EPUB infoset contains a link element that's currently missing from the WP infoset (this is tied to #159, #162 and #163 as well)
16:11:40 <Hadrien> q+
16:11:50 <tzviya> ack Hadrien
16:11:52 <NickRuffilo> ...: The first item - Hadrien THANK YOU - the epub has a LINK element - which is what enables externalized metadata in epub.  It can do lots of things in HTML.  I'm not sure this is missing, and we don't forbid this.
16:11:54 <garth> q?
16:12:59 <ivan> q+
16:13:37 <NickRuffilo> Hadrien: I've created a bunch of issues related to linking before the infoset.  It isn't just external metadata - it's also privacy policy, search, etc.  To comment on what you just said - I think it's conceptually where do items belong.  There was a comment ' when you add to an HTML resource, you're adding for that resource, and not for the whole publication.'  For example, if you link to a
16:13:37 <NickRuffilo> privacy policy, it relates to the specific resource.  But if you have something in the manifest, it relates to the entire document.  It could be handled in HTTP headers, but we don't fully have that today...
16:14:07 <garth> q?
16:14:09 <tzviya> ack ivan
16:14:11 <NickRuffilo> ...: The way I wrote - not the infoset - but the web IDL part of it - the web IDL already has that, mostly because I needed that for other items.  Web IDL has it, but infoset does not - or it is very vague about it.
16:15:13 <Hadrien> WebIDL is different than serializing though, it's half-way
16:15:20 <NickRuffilo> Ivan: I feel a bit uneasy because the link element is obviously something that might come up - when we get to the manifest but my understanding is that this issue would look at the infoset level.  I would prefer to concentrate first - just as we always did - is what are the infoset elements/items that are missing compared to what epub does - and then how would we serialize it.  Yes, there is the
16:15:20 <NickRuffilo> item of using the link element, but that can come later - lets not mix the two things.
16:16:01 <NickRuffilo> Tzviya: I was going to say - if we focus on the technology of the link element - link is the way in which you accomplish X, Y, and Z - we need to then understand what LINK can accomplish in epub.  I don't care that link is the spec'd element, what I care about is what is the functional role.
16:16:28 <NickRuffilo> Hadrien: And I think thats in the other issues I've raised - but it also enables much more than those.  LInking and the ability to specify media types and rel values.
16:16:44 <NickRuffilo> Tzviya: Right, like Ivan was saying - what is it that our infoset needs to accomplish.
16:17:40 <NickRuffilo> Ivan: The 3rd item is examples for features that are in epub and we have to be very careful that these would be in the infoset as well - some way or another.  For example, metadata.  Those are the issues we need to focus on.  The first goal is to have our infoset finalized.
16:18:20 <bigbluehat> q+
16:18:26 <tzviya> ack bigbluehat
16:18:33 <NickRuffilo> Hadrien: For link - I think what we're missing from our infoset, we're missing a way to reference a resource that is not in the reading order.  We cannot reference something on the web that is on neither of the lists.  Metadata records, a search service, a privacy policy...  IN general we lack the ability to reference something that is not IN the publication, but referenced by the publication.
16:19:08 <Hadrien> q+
16:19:20 <NickRuffilo> Benjamin: We have the link tag in HTML for referencing stuff for the browsers understanding of anything included, but not presentable - hypermedia semantics, can be cached, etc.  It is afforded for - and available at that layer.  It does have a correlation in the web, and we can take advantage of it.
16:19:24 <tzviya> ack Hadrien
16:20:10 <NickRuffilo> hadrien: I think you are going in a circle by saying that.  Earlier today I already mentioned a comment about that - if you reference something from a source, the rel value is the relation between the source and the resource - but from an infoset, we don't have a way to note it on the document level.
16:20:12 <garth> http://www.idpf.org/epub/301/spec/epub-publications.html#sec-link-elem
16:20:17 <ivan> q+
16:20:35 <bigbluehat> q+
16:20:44 <tzviya> ack ivan
16:20:48 <NickRuffilo> Tzviya: We need to be clear about what is needed and where - so this isn't about missing a link, it's about what functionality it represents and where it should go
16:21:56 <NickRuffilo> Ivan: at the moment - we need to separate the infoset and the specific serialization.  I want a high level concept as to what it is we need - what is the functionality that epub requires...  The question is - do we have to say in the infoset, that the infoset should refer to a DC element ... OK - these are the questions we have to decide.  This moment I don't care about the LINK element - if it's
16:21:56 <NickRuffilo> in JSON, or HTML, etc...
16:22:15 <NickRuffilo> Hadrien: I was just concerned with Benjamin saying that it was already covered - that link is in HTML therefore it's covered.
16:22:30 <garth> q?
16:22:30 <NickRuffilo> ...: I was listing what was in epub...
16:22:38 <bigbluehat> q-
16:23:05 <bigbluehat> q+ to add note about data modeling
16:23:13 <NickRuffilo> Garth: Tzviya - should the issue be relevant to the link element?  Or should it be related to the functions?
16:24:02 <NickRuffilo> ...: The question is how to accomplish the link functionality in our infoset...
16:24:05 <tzviya> ack bigbluehat
16:24:05 <Zakim> bigbluehat, you wanted to add note about data modeling
16:24:43 <Hadrien> q+ to explain how the list in the issue was built
16:25:06 <NickRuffilo> Benjamin: Just one quick thing - a question about datamodeling - we need to be clear about what we're expressing.  Epub's datamodel is one thing, and we should not focus on how it's expressed, but the functionality of it.  Whether the whole publication brain needs to know the relationships is a serialization thing.  Lets focus on model not serialization.
16:25:26 <tzviya> ack Hadrien
16:25:26 <Zakim> Hadrien, you wanted to explain how the list in the issue was built
16:25:26 <NickRuffilo> Garth: So this is a WP scope issue?
16:25:30 <NickRuffilo> Tzviya: I would agree...
16:26:22 <NickRuffilo> Hadrien: the list was built by looking at the spec - and there is no infoset in epub 3.2  I did list things like DC and the serialization.  But we can look at it and break it out into what goes into an infoset.  As long as we stay away from how things are serialized, I don't think there should be any controversy.
16:26:34 <NickRuffilo> Garth: Anything in the OPF metadata section would be the infoset.
16:27:05 <NickRuffilo> Hadrien: Mostly yes, but for epub, it's spread a bit everywhere.  There are things in the vocabulary list, spine, manifest, etc, that are infoset related.
16:27:24 <NickRuffilo> Tzviya: The next item - no explicit support for a list of REL (related items using the rel tag)
16:27:51 <pkra> sorry, I have to drop off early.
16:28:19 <NickRuffilo> Hadrien: to clarify, in epub, the approach is to have a controlled vocabulary.  Since we're on the web, we shouldn't be doing that, but using a link registry.  For now we're not talking about linking.  I think it's irrelevant to how we serialized, but what's the common vocab we're using for linking.  We use it for lots of our items.
16:28:27 <NickRuffilo> Ivan: and we should avoid inventing our own.
16:28:41 <bigbluehat> q+
16:28:42 <NickRuffilo> Tzviya: it's not a good idea to create our own, and we should use standard vocabs
16:29:28 <NickRuffilo> Hadrien: for the linking part - there are things where there are not equivalents on the web - such as cover.  There migth not be a rel value - like an icon - where it's similar but not the same.  As part of this work, we might also need to identify what is missing.
16:29:31 <tzviya> ack bigbluehat
16:30:17 <NickRuffilo> Benjamin: I wanted to note that we've been assuming linked data and using vocabs that exist - they can be done in HTML as well as JSON, so serialization is not a factor here.  That's all quite doable.  I don't think we've brought up any issues that aren't actually craftable.
16:31:13 <NickRuffilo> Tzviya: Other than cover - what invented rel values did epub create?
16:31:51 <NickRuffilo> Matt: We had record...  We deprecated most in 3.1.  We left record and alternate.  I think we're mostly aligned with web-standard rel values.
16:32:00 <Hadrien> I'm not sure there's an exact equivalent for "record"
16:32:10 <bigbluehat> q+
16:32:18 <NickRuffilo> Tzviya: Especially based on the link, we should be able to find reasonable rel values.  But we do need to create/find web equivalent solutions and open an issue for WP (which will affect PWP and epub)
16:32:32 <tzviya> ack bigbluehat
16:33:10 <Hadrien> q+
16:33:17 <NickRuffilo> Benjamin: Rel values can be URLs so they can be extended.  There are also default contexts that put schema.org, so you can do context maping and make it extensible.
16:33:30 <NickRuffilo> ...: We should not forget that this is well trodded ground.
16:33:34 <tzviya> ack Hadrien
16:33:47 <wolfgang> s/maping/mapping/
16:33:49 <bigbluehat> example of a URL-based rel <link rel="http://bib.schema.org/CoverArt" href="image.jpg" />
16:34:21 <ivan> q+
16:34:24 <tzviya> ack ivan
16:34:29 <NickRuffilo> Hadrien: Just a quick note - referencing a URI is a little better, but not the same as using a value that exists in a registry.  If we use something that exists in schema.org, we will need to have a list or registry for what is being used.  You could use dozens to represent cover, but we need to be careful.  Going in that direction is nearly equivalent to what we're doing in epub.
16:34:47 <Hadrien> q+
16:34:59 <NickRuffilo> Ivan: I'm looking at the link definition of the REL value in the LINK element of HTML5 - and it doesn't say we can have a URL.  I am not sure that statement is true.
16:35:02 <garth> q?
16:35:09 <tzviya> ack ha
16:35:14 <NickRuffilo> Benjamin: RDFA did...
16:35:23 <bigbluehat> q+
16:35:40 <NickRuffilo> Ivan: that becomes a very slippery slope.  That may get extremely strong pushback.  We have to be very careful of that dependency as we may shoot our own foot.
16:36:15 <bigbluehat> q+ to make point about data modeling again
16:36:19 <NickRuffilo> Hadrien: This is actually serialization specific.  Depending on the serialization, you're allowed to use this as an extension method.  Part of serialization - there are some that let you have one, and some that let you have many.  We cannot say that all link elements have multiple rels.
16:36:33 <NickRuffilo> Tzviya: We're getting into too many details.  We'll create the issue and go from there.
16:37:24 <garth> q?
16:37:28 <tzviya> ack bigbluehat
16:37:28 <Zakim> bigbluehat, you wanted to make point about data modeling again
16:37:29 <garth> ack bigbluehat
16:38:08 <Bill_Kasdorf> q+
16:38:16 <Hadrien> I think this is getting serialization specific again
16:38:18 <NickRuffilo> Benjamin: Garth said something in /me about cover being a manifest and not a rel issue.  The question is about data modeling - are we putting the vector of the rel model a thing about a thing or are we doing it directly.  Is the cover - by definition - a rel value pulled by some registry, or is it direct.  There are formats that different in how much relationships/relating they can handle, but we
16:38:18 <NickRuffilo> need to figure out what can be expressed - and what is core to the meaning of the object.  And if we want to lean on rel being the key.
16:38:22 <NickRuffilo> q+
16:38:57 <NickRuffilo> Garth: There are a couple of other - unused rel values - in our vocabulary.  And there are external metadata ones.  The cover issue is a unique one.  Is this linked into the first issue?
16:39:15 <NickRuffilo> Tzviya: We already have a requirement for cover image - so it should be already covered.
16:39:24 <garth> q?
16:39:27 <tzviya> ack bill-k
16:39:36 <tzviya> ack Bill_Kasdorf
16:39:41 <ivan> ack Bill_Kasdorf
16:39:51 <tzviya> ack NickRuffilo
16:39:54 <NickRuffilo> Bill: It strikes me that there's a difference between the epub and the WP - in WP the cover might be a rel value, but in epub, it might be a property
16:40:17 <ivan> q+
16:40:23 <Hadrien> sorry Bill_Kasdorf, but there's no reason why cover image should be handled differently in WP vs EPUB4
16:40:48 <Bill_Kasdorf> does a WP actually have to have a cover image? I think only an EPUB has to.
16:40:52 <tzviya> ack ivan
16:41:24 <garth> q?
16:41:32 <NickRuffilo> Ivan: What this whole rel thing says - is that the rel thing should define the type of the external reference.  There should be a mechanism in the infoset.  I think that's all we have to agree on.
16:41:41 <NickRuffilo> Tzviya: We're up to the Dublin-Core terms...
16:42:04 <Hadrien> q+ to comment on metadata usage in EPUB
16:42:34 <tzviya> q+ to talk about extensibility
16:42:38 <tzviya> ack Hadrien
16:42:38 <Zakim> Hadrien, you wanted to comment on metadata usage in EPUB
16:42:41 <NickRuffilo> Ivan: The question for each of these terms are that the infoset should have an item which identifies the publisher of the publication.  That may be already there.  We look at these functionality - what DC gives us.  If these are required, then there needs to be something to define these.  Whether we use DC or not, it's not on the infoset level.
16:43:24 <tzviya> ack tzviya
16:43:24 <Zakim> tzviya, you wanted to talk about extensibility
16:43:33 <NickRuffilo> Hadrien: Once again, I'm not going to talk about serialization.  Metadata items are often used by software and not necessarily by the publishers.  We need to look about what is actually used, and if they are used often, we can reintroduce them at the infoset level.  Some might only be in epub.
16:44:04 <Hadrien> q+ about extensibility
16:44:18 <NickRuffilo> Tzviya: We haven't talked about the extensibility model - but we haven't talked about the required fields.  No one is going to exclude you from including things like publisher.  You can add as much data as you want, just not inside the publication.
16:44:27 <NickRuffilo> Garth: What did you mean about the last item?
16:44:50 <NickRuffilo> Tzviya: if I have information someplace on the web - and I point to it, the information is still there, it's just not in the manifest.
16:45:04 <tzviya> ack Hadrien
16:45:05 <NickRuffilo> Garth: all of the DC are things we can include in the epub manfiest, but should they be external in the WP world?
16:45:09 <NickRuffilo> Bill: thats what i was getting at?
16:45:19 <wolfgang> s/manfiest/manifest/
16:45:30 <garth> q?
16:46:01 <dauwhe> q+
16:46:04 <garth> ack about
16:46:12 <garth> ack extensibility
16:46:19 <tzviya> ack dauwhe
16:46:21 <NickRuffilo> hadrien: extensibility is another item - but we should be careful about that.  While exploring 3.2 i saw that for title, it's possible in epub to say how it should be done using the opf file.  Because this never existed before - the community using caiblre used their own elements.  So we ended up in a situation where people handled the same things differently.  We risk fragmentation by not addressing
16:46:21 <NickRuffilo> them.
16:46:33 <NickRuffilo> Dave: A quick comment - the OPF attributes will not survive in 3.2
16:46:36 <wolfgang> s/caiblre/Calibre/
16:46:37 <Hadrien> q+
16:46:41 <tzviya> ack Hadrien
16:47:11 <NickRuffilo> Hadrien: yes/no.  For people writing software, people might be expressing it differently.  It might be easier on the spec side, but it makes it more difficult on the browser/reading system side.
16:47:30 <NickRuffilo> Tzviya: Are you proposing in WP we are explicit about how to create every metadata element?
16:47:33 <Hadrien> q+
16:47:40 <tzviya> ack Hadrien
16:48:20 <NickRuffilo> Hadrien: I am not saying we should do that for every element, but we should look at what is widely used.  If something is widely used, but we dont' address it, i would consider it a bug.  Early on in epub, we didn't define how cover was used, so people were defining it in different ways...
16:48:55 <NickRuffilo> ...: We can reach out to communities to get data.
16:49:33 <NickRuffilo> Tzviya: If calibre for example - if they aren't going to support or participate in WP, if their trajectory is epub, I'm not going to factor in their use of epub...
16:49:51 <Hadrien> q+
16:49:56 <tzviya> ack Hadrien
16:50:00 <NickRuffilo> ...: We need data to know what's going on.  We need to know where WP is going to be implemented, or else it will be a guessing game.
16:50:11 <garth> q?
16:50:41 <NickRuffilo> Hadrien: they might not do WP but they might for epub4...  During the 3.1 cycle, one of the reasons we went back and accepted more metadata was that we got a pushback from other communities.  So there is some data from the 3.1 tracker.
16:50:58 <zheng_xu> q+
16:51:23 <dkaplan3> q+
16:51:28 <NickRuffilo> Tzviya: What are we proposing to do for this specific issue.  Anyone who creates a reading or authoring system who has information about what DC elements should be required or expressed, any feedback would be helpful.
16:51:30 <tzviya> ack zh
16:51:37 <tzviya> ack zheng_xu
16:52:59 <Hadrien> q+
16:53:04 <tzviya> https://github.com/w3c/wpub/issues/176#issuecomment-382634697
16:53:05 <NickRuffilo> Zheng: I agree to expose title, publisher, more explicitly into the manifest.  One reason is that one thing we are facing right now is that we recieve metadata from publishers that sometimes come in different formats.  When we want to display the cover image, or publisher information...  there is some information that we need to display.  We need to correspond with CMS data as well.
16:53:15 <tzviya> ack dkaplan
16:54:59 <NickRuffilo> Deborah: I don't have an opinion if it should be in the infoset or not - but I have a question.  We talk about publishers and reading systems - one question is 'are we worried about librarians and archivists not being part of this.'  If the only 2 players are reading systems and content creators, then there are one set of needs, but if we're worried about how libraries work, that's another issue
16:54:59 <NickRuffilo> .  Dublin Core is a simple set of metadata.  It's small to make it sustainable.  I don't have opinions myself - but the question is, are we only worried about traditional publishing, or are libraries and archives also part of this.
16:55:17 <NickRuffilo> Tzviya: Yes, we are concerned.  But, this is the solution we have to come up with.
16:55:20 <Hadrien> q-
16:56:07 <ivan> topic: goals for the F2F
16:56:11 <NickRuffilo> Tzviya: After looking at these, we need to break them out to separate issues and have discussions there.  In the next 5 minutes, our F2F is in a month.  I'm not sure we're meeting every monday - as the epub summit is in 2 weeks, then there is a jewish holiday.  A quick update, how are people doing on meeting goals for F2F.  Affordances is on task.  WAM taskforce?
16:56:37 <Hadrien> q+
16:56:52 <tzviya> https://docs.google.com/document/d/1Qe8Q8wMC1LKy_-JO-UCy8bFw4D4VN0si1Q5EPW9c-rY/edit?usp=sharing
16:56:54 <tzviya> ack Hadrien
16:56:55 <NickRuffilo> ...: If you are working on something for the F2F but not going to be ready, please let me or garth know ASAP.
16:57:33 <NickRuffilo> Hadrien: I'm willing to take the list I started and turning that into something more infoset related.  I will point out where we have gaps in serialization.  I can then add my personal take if it should be WP, PWP, or epub4.
16:57:38 <bigbluehat> q+ to clarify WAM TF status
16:57:41 <ivan> q+
16:57:56 <NickRuffilo> Garth: Tzviya - you said 3 issues a while ago.  Extenral metadata, one on DC?  Then what?
16:58:03 <NickRuffilo> Tzviya: I was saying we got through 3 bullets.
16:58:18 <tzviya> ack bigbluehat
16:58:18 <Zakim> bigbluehat, you wanted to clarify WAM TF status
16:58:18 <NickRuffilo> ...: Any other business?  We hoped to talk about offlining - a few people had homework...
16:59:14 <NickRuffilo> Benjamin: I wanted to clarify with WAM - we haven't had any calls about the WAM taskforce, as we had some foundational items we wanted to iron out first.  Until that's resolved, we can't really look at it more.  We don't want to soldier off until there are direct asks to make.  we have routed it to github issues.
16:59:14 <tzviya> ack ivan
16:59:43 <NickRuffilo> Ivan: Hadrien - just one request.  I value your opinion, but I think it would be better if you put the issue and your personal recommendation as a separate note.
17:00:20 <NickRuffilo> Ivan: for the time being lets not address serialization
17:00:26 <NickRuffilo> tzviya: Bye!
17:00:29 <ivan> rrsagent, draft minutes
17:00:29 <RRSAgent> I have made the request to generate https://www.w3.org/2018/04/30-pwg-minutes.html ivan
17:00:29 <ivan> zakim, bye
17:00:29 <ivan> rrsagent, bye
17:00:29 <RRSAgent> I see no action items
17:00:29 <Zakim> leaving.  As of this point the attendees have been ivan, dauwhe, rkwright, wolfgang, NickRuffilo, chirping, chicks, dkaplan, laurent, jasminemulliken, adamsisco, mattg, tzviya,
17:00:29 <Zakim> Zakim has left #pwg
17:00:32 <Zakim> ... franco, Avneesh, zheng_xu, derekJackson, JunGamo, pkra, jbuehler, lsullam, BenSchroeter, george, bigbluehat, marisa, josh, Bill_Kasdorf, Chris_Maden, Hadrien, duga, Garth