15:30:54 <RRSAgent> RRSAgent has joined #pwg
15:30:54 <RRSAgent> logging to https://www.w3.org/2018/09/10-pwg-irc
15:31:05 <Zakim> Zakim has joined #pwg
15:31:17 <dauwhe> Meeting: Publishing Working Group Telco
15:31:26 <dauwhe> Date: 2018-09-10
15:31:28 <dauwhe> Chair: Garth
15:31:35 <dauwhe> regrets+ Rachel
15:50:57 <mgarrish> mgarrish has joined #pwg
15:52:27 <ivan> Regrets+ tzviya, makoto, vlad, hadrien, deborah, brady, luc, Tim_Cole, rdeltour, David_Stroup
15:52:27 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2018Sep/0000.html
15:52:27 <ivan> ivan has changed the topic to: Meeting 2018-09-10: https://lists.w3.org/Archives/Public/public-publ-wg/2018Sep/0000.html
15:55:34 <Avneesh> Avneesh has joined #pwg
15:56:06 <dauwhe> present+
15:57:40 <jbuehler> jbuehler has joined #PWG
15:59:00 <George> George has joined #pwg
15:59:24 <NickRuffilo> NickRuffilo has joined #pwg
15:59:38 <EvanOwens> EvanOwens has joined #pwg
15:59:38 <NickRuffilo> scribenick: nickruffilo
15:59:42 <ivan> present+
16:00:01 <NickRuffilo> present+
16:00:14 <cmaden2> cmaden2 has joined #pwg
16:00:28 <zheng_xu> zheng_xu has joined #pwg
16:00:40 <gpellegrino> gpellegrino has joined #pwg
16:00:47 <rkwright> rkwright has joined #pwg
16:00:51 <clapierre> clapierre has joined #pwg
16:00:58 <josh> josh has joined #pwg
16:00:59 <franco> franco has joined #pwg
16:01:00 <gpellegrino> present+
16:01:04 <franco> present+
16:01:05 <JunGamo> JunGamo has joined #pwg
16:01:07 <josh> present+
16:01:13 <rkwright> present+
16:01:19 <JunGamo> present+
16:01:25 <zheng_xu> present+
16:01:44 <bigbluehat> present+
16:01:48 <cmaden2> present+ Chris_Maden
16:01:51 <George> present+ George
16:02:02 <ivan> present+ jbuehler
16:02:29 <Avneesh> present+
16:04:12 <garth> garth has joined #pwg
16:04:18 <garth> present+ Garth
16:04:27 <JuanCorona> JuanCorona has joined #pwg
16:04:27 <marisa> marisa has joined #pwg
16:04:36 <BenSchroeter> BenSchroeter has joined #pwg
16:04:46 <garth> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-08-27-pwg.html
16:04:51 <BenSchroeter> present+
16:05:06 <NickRuffilo> Garth: Meeting minutes approved...
16:05:07 <ivan> resolved: last week's minutes approved
16:05:08 <marisa> present+
16:05:13 <laurentlemeur> laurentlemeur has joined #pwg
16:05:17 <caitlingebhard> caitlingebhard has joined #pwg
16:05:20 <laurentlemeur> present+
16:05:25 <caitlingebhard> present+
16:05:30 <ivan> topic: issue 291
16:05:30 <garth> https://github.com/w3c/wpub/issues/291
16:05:35 <rkwright> scribe?
16:05:47 <clapierre> present+
16:05:49 <rkwright> AH, OK.  Thanks
16:06:10 <JuanCorona> present+
16:06:14 <NickRuffilo> Garth: Last week, Monday, there was no meeting due to US Labor Day.  There was discussion on the call on issue #291 - we got to a semi-consensus that we'd have two - one for referencing and one for machine processing.  Those, not including me, hung on the call and that rough consensus evaporated.  There has been more discussion...
16:06:16 <garth> https://github.com/w3c/wpub/issues/291#issuecomment-417554685
16:06:22 <mgarrish> present+
16:06:36 <BenWaltersMS> BenWaltersMS has joined #pwg
16:06:53 <BenWaltersMS> present+
16:07:02 <MustlazMS> MustlazMS has joined #pwg
16:07:07 <NickRuffilo> ...: the most recent was that this was a proposal that Ivan put together on having a single point of context that could be used to process the renderable one into something that is more machine readable.  And getting hierarchy around the lists.  That's sort of where we are...
16:07:11 <MustlazMS> present+
16:07:18 <garth> q?
16:07:23 <dauwhe> q+
16:08:04 <derekjackson> derekjackson has joined #pwg
16:08:14 <derekjackson> present+
16:08:44 <NickRuffilo> Ivan: In some sense, I think we're in a deadlock.  One approach is to have a clear algorithm in the spec that say "this is how - from this HTML over there - this is how the hierarchical menu is created" - which is fine.  For the time being, we don't have that algorithm.  My personal belief is that just having an algorithm without some sort of definition of how the talk looks like would be incredibly difficult.  If we define some sort of structure...
16:09:25 <NickRuffilo> ...: then the algorithm should be put in the spec.  Then my proposal goes that the way it would operate from the user is that the algorithm would then be the talk - and the user agent should simply play the HTML content that is there...
16:09:36 <garth> q?
16:09:36 <ivan> q?
16:10:02 <ivan> q+
16:10:06 <ivan> ack dauwhe
16:10:28 <NickRuffilo> Dave: I'm an advocate for 'define an algorithm' but I'm not a JS expert, although I'm sure we can create an algorithm that creates the hierarchy.  I would really like to see what such an algorithm would do to some real-life table of contents before we go much further...
16:11:08 <jbuehler> q+
16:11:15 <garth> ack ivan
16:11:28 <NickRuffilo> Ivan: Having javascript algorithm that could take any HTML would be terribly complicated and would be about the organization of the DOM...  I looked at some examples that are more anecodtal about what Table of Contents are out there, I looked at ones that were generated and not human-created...
16:12:12 <NickRuffilo> ...: I think there was only one exception - most are essentially a NAV or a UL or OL with the LI as the children, which is the natural thing to do with a table of contents.  The other possibility is to use H1,H2, H3 to specify hierarchy.
16:12:25 <garth> ack jbuehler
16:13:19 <NickRuffilo> J: I wrote a number of scripts (node JS) that parse out TOCs and create TOCs, generally from spreadsheets and CSVs.  There's some relationship there that might be helpful.  It generats TOCs from CSVs.
16:14:04 <garth> q?
16:14:05 <NickRuffilo> ...: The hierarchy is pretty brute force - i'm not using DOM parsing, I'm using regular expressions.  There are some tags required for specific elements, but it might be helpful for anyone working on this.  It's been tested over a few years, so it definitely works.
16:15:08 <NickRuffilo> Garth: I tend to agree with ivan that I am very much in the camp that one of the successful things we did in epub was the NAV file, but it doesn't sound that view of the world is going to get traction here, but we might revisit in epub4 land.  I don't see any other way forward other than accepting ivan's suggestion that we'll have a placeholder for, but there doesnt' seem to be consensus support to have 2 TOCs...
16:15:09 <garth> q?
16:15:11 <ivan> q+
16:15:37 <garth> ack ivan
16:15:40 <NickRuffilo> ...: It seems to me that is where we are.  But maybe we do a brief poll for consesus for accepting Ivan's language with an algorithm TBH to be defined and experimented with.
16:16:16 <mgarrish> q+
16:16:41 <NickRuffilo> Ivan: I think we need to modify a bit - we should leave it open and give ourselves a certain amount of time to see if such and algorithm can be created.  If it cannot be created, then we need a combination of what's in epub3, making a reference to this issue - that for me seems to be the best option.
16:16:56 <NickRuffilo> Garth: The best thing you said is that come back in a month - which happens to be TPAC - so that could be an interesting approach.
16:16:58 <garth> ack mgarrish
16:17:57 <NickRuffilo> Matt: I was going to agree with Ivan - I am not of the beleif that completely random HTML will become structured TOC.  The middle ground we might find here is that there is a recommended way of doing a TOC - so YMMV if you don't go with the recommended structure for TOC...
16:18:11 <josh> +1 to recommended structure for TOCS
16:18:12 <George> q+
16:18:19 <garth> ack George
16:18:21 <NickRuffilo> ...: I want to sit on the fence that it's required of epub but not necessarily dpub, and just note there are better ways to do it.
16:18:55 <NickRuffilo> George: Would it be helpful for us to gather a collection of recommendations on how to do it?  For example, if you've got a collection of content documents - how to traverse those files and extract the things you want to put in the TOC?
16:18:56 <dauwhe> q+
16:19:35 <NickRuffilo> Garth: That sort of strikes me as - building a TOC from a whole cloth - this discussion is about how free can we be with an actual doc-TOC but without looking at it from the reading order
16:20:00 <NickRuffilo> George: I don't know how this will be created.  I've seen TOCs where the names in the doc-toc do not align with the content in your document.
16:20:30 <garth> q?
16:20:34 <NickRuffilo> garth: we do have a requirement in the currect spec that there must have a TOC identified, and it must point to an element identified as doc-toc.  If it's wrong and points to things that don't exist, that's the documents fault.
16:20:37 <garth> ack dauwhe
16:21:43 <NickRuffilo> Dave: The key here is that it's the author's responsibility to create a TOC.  They know how to best facilitate access to their content.  We're spending time assuming the User Agent needs to do anything beyond displaying the documents table of contents.  I'm not sure how this fits into the web publication world, if we take the word web seriously.  It's not standard for a UA to search for nav elements.
16:22:08 <ivan> q+
16:22:15 <NickRuffilo> Garth: I think it's very arguable on either side on the WP side.  When we get to epub4, we'll want the reading system to be able to do things with the TOC, but lets not argue that thing now.
16:22:17 <garth> ack ivan
16:23:03 <NickRuffilo> Ivan: I want to make reminders that the TOC is not a required element.  if the author doesn't want the User Agent to do something, they won't create a DOC-TOC element.  We are not contradicting.  There is no problem with a creator doing what they want.
16:23:16 <garth> https://github.com/w3c/wpub/issues/291#issuecomment-417554685
16:23:53 <NickRuffilo> Garth: I would like to propose consensus on Ivan's comments, but proposes an algorithm and/or set of constraints we might place on the table of contents if the algorithm is successful - take a few weeks to TPAC, and if we've gotten somewhere...
16:24:20 <garth> +1
16:24:24 <NickRuffilo> ...: We would have some constraints, and if the algorithm is not successful then just display the HTML.  If that is acceptable to folks, I will go ahead and be the token +1
16:24:36 <garth> q?
16:24:37 <jbuehler> +1
16:24:38 <ivan> +1
16:24:43 <josh> +1
16:24:43 <rkwright> +1
16:24:43 <zheng_xu> +1
16:24:44 <JuanCorona> +1
16:24:46 <marisa> +1
16:24:48 <NickRuffilo> +1
16:24:52 <dauwhe> +1
16:25:11 <ivan> Topic: issue 276: external resource in ToC
16:25:15 <garth> https://github.com/w3c/wpub/issues/276
16:26:02 <ivan> q+
16:26:15 <ivan> q-
16:26:26 <NickRuffilo> Garth: The DOC-TOC element - if it can point to resources outside of the default reading order.  I will throw out a prejudice that the thing - and Dave is going to come in saying 'it's not webby' - my initial 2 cents is that the TOC should point to items in the resources or reading order.
16:27:08 <jbuehler> q+
16:27:09 <NickRuffilo> Garth: The title of the issue is: "outside the reading order" and additional resources.  If it's a publication, then the TOC should point into the publication as it's defined by the boundary.
16:27:27 <garth> ack jbuehler
16:27:49 <NickRuffilo> J: I found that over the years the TOC isn't always reliable, such as resources not available within.  The solution is to create another XML file...
16:27:51 <NickRuffilo> q+
16:28:20 <NickRuffilo> garth: I don't think we want the TOC to have more power, but the pointers in the DOC-TOC, whether the links in there can point only to the items within the publication.
16:28:25 <garth> ack NickRuffilo
16:28:25 <ivan> +1 to garth
16:28:51 <ivan> q+
16:29:50 <garth> ack ivan
16:29:57 <NickRuffilo> Garth: it wouldn't pull all of that section's links into the TOC (the external links)
16:30:15 <dauwhe> q+
16:30:21 <NickRuffilo> Ivan: Any scholarly publication's structure, yes there's a section of references, but the TOC includes a reference to the section, but not the external links.
16:30:23 <garth> ack dauwhe
16:30:59 <josh> q+
16:31:25 <NickRuffilo> Dave: This is more a discussion of scope and boundaries than what happens if a link in a TOC goes somewhere beyond 'inside the publication'  That is a larger question we haven't really addressed.  What I have an external link elsewhere.  What happens, how do we show to the user that they have left the web publication.
16:32:28 <NickRuffilo> Garth: Certainly in web publication land, Nick's suggestion of additional reading - we do agree that the default reading order + additional resources is the bounds of the publication, so - do we - for the TOC should it only fit within the bounds of the publication.  We can't prevent content creators from putting a link to whatever - but we need the rule if it is ignored or not.
16:32:29 <garth> ack josh
16:33:20 <NickRuffilo> Josh: I tend to agree, and prefer for the TOC to be within the bounds of the publication.  What we're doing with web publications is creating the ability to bind different things together.  We could mix-and-match pages, but the point of the WP is to bind them together...
16:34:00 <NickRuffilo> ...: The TOC should direct you within the bounds of what you've just created.  Things like references, they're all external links.  They should be separate from the TOC.  It would be frustrating for a user to click and link and leave the document.
16:34:15 <JuanCorona> nice explanation josh +1
16:34:23 <garth> q?
16:34:27 <George> q+
16:34:31 <rkwright> q+
16:34:33 <NickRuffilo> Garth: We're defining a bounded collection of resources, so the TOC should point within those bounds.
16:34:35 <EvanOwens> Q+
16:34:40 <garth> ack George
16:35:10 <ivan> q+
16:35:15 <garth> ack rkwright
16:35:16 <NickRuffilo> George: I'm envisioning reading order in the additional documents to have link relationships to other documents within the publication, whereas when you get outside the publication there is no relationship.  I'm in agreement that the TOC defined as such helps solidify this.
16:36:01 <NickRuffilo> Rick: I totally agree with what Josh said - well put.  The other comment, more of a question, more relevant here.  Isn't this related to the conversation in chicago about would we allow resources to be external to the document?  As a RS developer, that makes me nervous as it's a security concern.
16:36:25 <garth> ack EvanOwens
16:36:33 <NickRuffilo> Garth: I agree, moving within the TOC you're moving within the publication.
16:37:02 <NickRuffilo> Evan: within journal publishing, you have links to where the article was published, so you would be linking out to a different document/page
16:37:18 <NickRuffilo> Garth: You're envisioning a page that is a pointer to other publications, but it would be a TOC?
16:38:21 <garth> q?
16:38:37 <NickRuffilo> Josh: I come from the journal publishing world, and yes, an article would be a web publication.  The issue for that article would be a web publication of web publications.  In which case, the Table of Contents is - you're still within the bounds of the issue, we're still binding that.  It could be a compilation - all of that stuff...  it doens't matter where it lives, as long as the manifest defines it as part of the publication.
16:38:50 <NickRuffilo> ...: We have to drop the notion of domain - it's still a single web publication and the TOC is within it.
16:38:57 <garth> ack ivan
16:39:11 <NickRuffilo> Ivan: Slightly different question from George if someone wants to respond.
16:39:33 <NickRuffilo> Garth: I thought it was well summarized as nested web publications, so the parents can point to it's children, which are part of the boundaries.
16:40:19 <josh> An out-of-bounds error :-)
16:40:26 <NickRuffilo> Ivan: The question - lets say we decided that a reference in a TOC should be within the bounds.  The question is, what happens if someone makes a mistake.  What is the reaction?  It's a bit like we already have requirements for a person but if a structure doesn't have a name, the structure is invalid and taking out of the list.
16:41:01 <NickRuffilo> ...: Lets say we have a process that creates a machine readable TOC, and the algorithm realizes that one of the references is out of the doc, what should it do?
16:41:06 <mgarrish> q+
16:41:13 <NickRuffilo> q?
16:41:36 <garth> ack mgarrish
16:41:36 <NickRuffilo> Garth: We clearly have to deal with that, and it comes down to if it becomes a should or a must, and what happens if you violate
16:42:39 <NickRuffilo> Matt: Probably a must-not is a bit strong, we won't stop people.  It should be a recommendation for the reasons already laid out, it will be confusing to the user and leave it at that.  We're not going to force people, and reading systems are going to have to handle this.  Throwing it out is going to be odd, but when it's extracted from the reading system, it's not a place we should go, we should just recommend not doing it.
16:43:06 <josh> +1 to SHOULD
16:43:10 <NickRuffilo> Garth: maybe this does inherently answer Ivan's question, that we can resolve this issue, at least for the moment, that the entries in the DOC-TOC table of contents should points into the bounds of the publication
16:43:21 <Avneesh> +1
16:43:24 <garth> +1
16:43:25 <derekjackson> +1
16:43:26 <zheng_xu> +1
16:43:28 <clapierre> +1
16:43:28 <ivan> Proposed: the entries in the DOC-TOC table of contents should points into the bounds of the publication
16:43:28 <JuanCorona> +1
16:43:29 <josh> +1
16:43:30 <jbuehler> +1 also should, 0 to must
16:43:30 <ivan> =1
16:43:33 <caitlingebhard> +1
16:43:33 <ivan> +1
16:43:34 <franco> +1
16:43:35 <NickRuffilo> Garth: If that is consensus, that is probably suitable for us to get in there and resolve the issue.
16:43:42 <NickRuffilo> q+
16:43:44 <dauwhe> +1 to should, -1 to must
16:43:47 <rkwright> +1
16:43:49 <BenSchroeter> +1
16:43:55 <marisa> +1 should
16:43:55 <George> +1
16:44:26 <josh> q+
16:44:31 <garth> ack NickRuffilo
16:45:12 <garth> ack josh
16:45:33 <ivan> q+
16:45:41 <NickRuffilo> Josh: As we are specification writers, the best we can do is should, must, and must not, but it's up to implementors to determine what should happen when they come across a should/must/must-not, etc.
16:45:55 <garth> ack ivan
16:45:57 <NickRuffilo> Garth: It's more incumbent on us to determine what should happen with must and must not....
16:46:10 <dauwhe> q+
16:46:34 <NickRuffilo> Ivan: At some point in time we will have to look at this for the document.  If there is a should or should-not, then there is a checker that should raise a warning (the difference between an error or warning) so a future epub checker could raise a warning.
16:46:47 <garth> ack dauwhe
16:47:17 <NickRuffilo> Dave: I think we need to make distinctino between HTML and the manifest.  We control the manifest, but not HTML.  We should not be making any restrictions on HTML
16:47:28 <ivan> resolved: the entries in the DOC-TOC table of contents SHOULD points into the bounds of the publication
16:47:31 <garth> https://github.com/w3c/wpub/issues/312#issuecomment-415016624
16:47:43 <ivan> Topic: naming things, issue 312
16:48:01 <NickRuffilo> Garth: The last issue, Rachel summarized in the comment provided, this was an issue Dave raised.  Is anyone in a good position to summarize?
16:48:07 <ivan> q+
16:48:12 <ivan> q-
16:48:36 <garth> q?
16:48:51 <ivan> q+
16:49:16 <NickRuffilo> Dave: Because we're inhereting tons of terminology from schema.org they have set names for items, that don't always match up with publishing, what we call a title, schema calls it a name.  So a book title would have to be a "name" so there is a bit of resistance that the common terms different from what we have to call things in the manifest.  Not sure what we can do about it, but it makes our spec harder to understand.
16:49:35 <mgarrish> q+
16:49:36 <NickRuffilo> Garth: Is this an area we need to be more explicit about?
16:50:02 <garth> ack ivan
16:50:03 <NickRuffilo> Dave: Everything we can do in our spec prose to help our readers understand - to express language we use IN language...  We should be really aware of as we write text here.
16:51:30 <NickRuffilo> Ivan: To be clear, technically speaking, if we use JSON LD, it is possible to rename those terms to our own liking by extending the wpub file.  I must admit that we are getting nervous about defining HTML, I get the same about redefining schema.org.  Yes we should give full power to Matt to make things more readable, but I would be very reluctant of changing schema.org terms - with ONE exception...
16:51:43 <dauwhe> q+
16:52:27 <NickRuffilo> ... ivan: JSON LD we have @type @id and @language, and it's a very common practice in JSON LD, that @type is redefined to use type, and @id is redefined as id.  It's so common that schema.org notes it.  This will make things easier to port into a javascript structure.
16:53:58 <garth> ack mgarrish
16:53:59 <NickRuffilo> Matt: We touched on that this is something we can improve in our spec language.  This is the push and pull of using property tech names and natural language.  Our section right now is structured to concepts rather than specific naming.  We can flip it around, put property names with the language, and there's ways of tweaking, but i'm comfortable migrating us away from schema.org.  There are 'read-by' for narrator, and we should strike up a convo with[CUT]
16:54:08 <NickRuffilo> ...: that's probably the most appropriate way to go...
16:54:08 <garth> ack dauwhe
16:54:26 <NickRuffilo> Dave: I wanted to agree with Ivan - yes, I think in the JSON LD context, the cure is worse than the disease.
16:54:44 <ivan> proposed: remove the '@' from keywords; leave other terms as they are
16:55:36 <garth> q?
16:55:37 <NickRuffilo> Garth: Much like Ivan said, we need to use the schema.org terms, but we want to be careful in our drafting that we don't lose the drafting, like the first entry, we live with what we have but we try to be as clear in our language as possible to avoid confusion.
16:56:02 <NickRuffilo> Ivan: we need a resolution on something, so I moved agreeing on the removal of @
16:56:07 <ivan> +1
16:56:09 <josh> +1
16:56:10 <NickRuffilo> +1
16:56:11 <mgarrish> +1
16:56:12 <jbuehler> +1
16:56:13 <garth> +1
16:56:15 <BenWaltersMS> +1
16:56:17 <dauwhe> +1
16:56:22 <ivan> resolved:  remove the '@' from keywords; leave other terms as they are
16:56:24 <rkwright> +1
16:56:24 <marisa> +1
16:56:37 <ivan> Topic: TPAC Agenda
16:56:40 <garth> https://docs.google.com/document/d/1Mt9PTcOdmrCwIsgfxbGMGjwHlUsySU01I0D4oBkSbcA/edit
16:57:16 <NickRuffilo> Garth: above pasted is the draft of the TPAC agenda.  There is an agenda item requests.  A fair number are crossed off, which means they were moved into monday/tuesday...
16:58:08 <NickRuffilo> ...: we will spend more time moving topics down, and some will move around as we co-ordinate with external groups and visitors.  We are getting really close to TPAC now, so if there are particular issues we should address in public, please add a comment in here.
16:58:31 <garth> q?
16:58:47 <ivan> Topic: incubation
16:59:21 <garth> https://discourse.wicg.io/search?q=dpub
16:59:35 <NickRuffilo> ...: Please comment and add.  Lastly there was an Agenda item that Tzviya wanted mentioned, we do have a process in the W3C for incubation of ideas.  We have had things that are outside of the immediate scope of this group - one is the publishing object model - there is an opportunity to use the process for potential incubation.  We certainly encourge people to participate in that process.
16:59:59 <garth> From Agenda: “We have people in the group who are working on things that would be potentially interesting for the future state of publishing, but the current W3C assumes a formal incubation period. We need to do that in our group as well. We already have a dedicated label in WICG, so we recommend incubation of ideas like the Publishing Object Model and transclusion via iframes there [9.6]. We hope to see projects and demos at TPAC.”
17:00:50 <bigbluehat> q+ to request we discuss this again next week (because time)
17:01:07 <NickRuffilo> Ivan: There has been lots of discussion in the group about how to discuss ideas that go beyond the group.  Such as new ways of handling CSS - extending those with features.  Even if those require a much longer work and co-operation with other groups, it would be a pity if those were lost.  We were looking for some sort of way for these incubation ideas to be recorded and documented.  Thats what we were wondering about.
17:01:30 <bigbluehat> q-
17:02:12 <BenWaltersMS> BenWaltersMS has left #pwg
17:02:14 <NickRuffilo> Garth: We'll discuss more next week.  We are a tad over time, but we'll have an agenda for next week, and please comment on TPAC agenda.  Thank you and bye
17:02:20 <ivan> rrsagent, draft minutes
17:02:20 <RRSAgent> I have made the request to generate https://www.w3.org/2018/09/10-pwg-minutes.html ivan
17:02:20 <ivan> zakim, bye
17:02:20 <ivan> rrsagent, bye
17:02:20 <Zakim> leaving.  As of this point the attendees have been dauwhe, ivan, NickRuffilo, gpellegrino, franco, josh, rkwright, JunGamo, zheng_xu, bigbluehat, Chris_Maden, George, jbuehler,
17:02:20 <Zakim> Zakim has left #pwg
17:02:23 <Zakim> ... Avneesh, Garth, BenSchroeter, marisa, laurentlemeur, caitlingebhard, clapierre, JuanCorona, mgarrish, BenWaltersMS, MustlazMS, derekjackson
17:02:30 <cmaden2> cmaden2 has left #pwg
17:05:20 <ivan> rrsagent, set log public
17:05:31 <ivan> rrsagent, draft minutes
17:05:31 <RRSAgent> I have made the request to generate https://www.w3.org/2018/09/10-pwg-minutes.html ivan