16:40:20 <RRSAgent> RRSAgent has joined #pwg
16:40:20 <RRSAgent> logging to https://www.w3.org/2018/11/26-pwg-irc
16:40:21 <ivan> rrsagent, set log public
16:40:21 <ivan> Meeting: Publishing Working Group Telco
16:40:21 <ivan> Chair: wendy
16:40:21 <ivan> Date: 2018-11-26
16:40:21 <ivan> Regrets+
16:40:21 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2018Nov/0039.html
16:40:21 <ivan> ivan has changed the topic to: Meeting 2018-11-26: https://lists.w3.org/Archives/Public/public-publ-wg/2018Nov/0039.html
16:51:57 <wolfgang> wolfgang has joined #pwg
16:53:32 <Yanni_> Yanni_ has joined #pwg
16:54:02 <yanni_> yanni_ has joined #pwg
16:55:00 <Yanni> Yanni has joined #pwg
16:55:56 <laudrain> laudrain has joined #pwg
16:56:36 <Avneesh> Avneesh has joined #pwg
16:57:55 <laudrain> present+
16:58:04 <EvanOwens> EvanOwens has joined #pwg
16:58:29 <dkaplan3> present+
16:58:46 <wendyreid> present+
16:58:49 <wendyreid> Chair: wendyreid
16:59:00 <Rachel> present+
16:59:06 <Teenya> Teenya has joined #pwg
16:59:14 <Teenya> present+
16:59:16 <NickRuffilo> NickRuffilo has joined #pwg
16:59:26 <wolfgang> present+ wolfgang
16:59:27 <NickRuffilo> scribenick: NickRuffilo
16:59:50 <jbuehler> jbuehler has joined #PWG
17:00:03 <franco> franco has joined #pwg
17:00:10 <franco> present+
17:00:18 <cmaden2> cmaden2 has joined #pwg
17:00:31 <JunGamo> JunGamo has joined #pwg
17:00:41 <romain> romain has joined #pwg
17:00:44 <ivan> present+
17:00:56 <Yanni> present+
17:01:01 <romain> present+
17:01:01 <George> George has joined #pwg
17:01:04 <bigbluehat> present+
17:01:11 <wendyreid> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-11-19-pwg.html
17:01:11 <JunGamo> present+
17:01:13 <George> present+ George
17:01:15 <Avneesh> present+
17:01:18 <NickRuffilo> Wendy: Welcome everyone - We're going to talk about TOC.  But first, lets approve last week's minutes.
17:01:18 <jasminemulliken> jasminemulliken has joined #pwg
17:01:32 <cmaden2> present+ Chris_Maden
17:01:33 <josh> josh has joined #pwg
17:01:33 <ivan> resolved: last week's minutes approved
17:01:39 <NickRuffilo> ...: Silence is approval.  Minutes approved.
17:01:41 <ivan> Topic: TOC
17:01:43 <jasminemulliken> present+
17:01:45 <dauwhe> present+
17:01:53 <josh> present+
17:02:00 <BenSchroeter> BenSchroeter has joined #pwg
17:02:07 <BenSchroeter> present+
17:02:23 <NickRuffilo> ...: As mentioned in the agenda, we're going to talk about TOC again.  As mentioned, as part of the new system, a short-ish explainer about TOCs and what we want to propose to the group.  the TOC issue has been dragging on for a while.  But it's time to come to an agreement, even if it's a basic definition.
17:02:52 <tzviya> present+
17:03:22 <NickRuffilo> ...: In looking over the comments, we're in more-or-less consesus over a few things. We can go between a limited HTML TOC with a subset of HTML (undetermined) such as the epub3 spec, or our full HTML TOC as identified in the manifest that contains everything and the UAs will have to parse whatever it is.
17:03:36 <wolfgang> s/consesus/consensus/
17:03:41 <wendyreid> q?
17:03:43 <dauwhe> q?
17:03:44 <NickRuffilo> ...: There is a 3rd, a data TOC that's in JSON in the manifest, but the core is really around the first two options.  Comments?
17:03:58 <wendyreid> https://github.com/w3c/wpub/issues/291
17:03:58 <wendyreid> https://github.com/w3c/wpub/issues/350
17:04:00 <rkwright> rkwright has joined #pwg
17:04:14 <rkwright> present+
17:04:22 <NickRuffilo> ...: 291 is about a more detailed definition, 350 is more about the TOC
17:04:30 <bigbluehat> q+
17:04:31 <dkaplan3> q+
17:04:41 <wendyreid> ack bigbluehat
17:05:18 <NickRuffilo> Benjamin: I asked this a couple weeks ago - do we have use cases or explanations about why the TOC must be machine readable?  It seems unrelated to the ability to access it from anywhere.  It has it's own sense of requirements.  Is there a use-case approach?
17:05:20 <wendyreid> ack dkaplan3
17:05:34 <MustlazMS> MustlazMS has joined #pwg
17:05:45 <marisa> marisa has joined #pwg
17:05:46 <ivan> q+
17:05:51 <ivan> ack dkaplan3
17:05:54 <wendyreid> ack dkaplan
17:05:58 <marisa> present+
17:06:01 <MustlazMS> present+
17:06:17 <NickRuffilo> Deborah: While we might not have formal use cases, there are tons in the comments about them being machine readable.  At this point, i'd really vote for saying 'we have discussed this into the ground'  There are a couple of proposals, none make everyone happy, but a couple proposals that are in the tickets make people 'tolerate' them.
17:06:48 <mgarrish> present+
17:06:51 <duga> duga has joined #pwg
17:06:54 <tzviya> https://w3c.github.io/dpub-pwp-ucr/#tableofcontents
17:06:57 <tzviya> q+
17:06:58 <duga> present+
17:07:07 <NickRuffilo> ...: I would be much more in favor of voting on some of the proposals.  Discussion will not be needed, I think it's just time to vote and we'll figure out the best possible option.
17:07:18 <NickRuffilo> ...: There might still be some unresolved issues, but we can't just keep talking.
17:07:18 <wendyreid> ack ivan
17:07:51 <dkaplan3> q+
17:08:00 <garth> garth has joined #pwg
17:08:07 <garth> present+ Garth
17:08:14 <NickRuffilo> Ivan: I just want to emphasis one thing, the proposal is to be able to have both - and it's up to the author to choose either a structured HTML/machine readable stuff, or a fully HTML, or both or the two...  That goes in the direction of Deborah, but if we discuss, we'll never close this.
17:08:19 <garth> q?
17:08:32 <NickRuffilo> Tzviya: Link to the UC document where this is address has been linked
17:08:33 <laurent_> laurent_ has joined #pwg
17:08:35 <wendyreid> ack tzviya
17:08:39 <wendyreid> ack dkaplan
17:08:45 <laurent_> present+
17:09:08 <User2> User2 has joined #pwg
17:09:26 <NickRuffilo> Deborah: What I will say that should make most people tolerate - if the spec allows both (one or the other) and then there are 2 sets of docs NOT in the spec, that are very clear.  One for reading system creators - here is what you must do in the presence of one or another - and one is for creators that says 'here are the cases where you will use one/neither/both'
17:09:45 <NickRuffilo> ...: As long as we document the solution, I think we can all live with this
17:09:49 <NickRuffilo> Wendy: +1
17:10:26 <NickRuffilo> Wendy: Do we allow for both, and do we provide information to reading systems and content creators on how to use them, or do we only allow one in the spec?
17:10:28 <jbuehler> +1 to the dual solution
17:10:33 <ivan> +1 to both
17:10:35 <NickRuffilo> +1 both
17:10:36 <BenSchroeter> +1 both
17:10:36 <laudrain> +1 to dual
17:10:36 <laurent_> +1 for both
17:10:38 <rkwright> +1 to both
17:10:39 <wolfgang> +1 dual option
17:10:46 <romain> ±0
17:10:47 <EvanOwens> +1 to both
17:10:50 <bigbluehat> +0
17:10:51 <tzviya> +1 with extremely explicit documentation
17:10:53 <ivan> present+ garth
17:11:26 <dkaplan3> +1 with documentation for user agents and for content creators
17:11:31 <NickRuffilo> Ivan: Lets get the proposed text exactly then, as a resolution
17:11:39 <timCole> timCole has joined #pwg
17:11:50 <tzviya> q+
17:12:00 <wendyreid> ack tzviya
17:12:19 <garth> q+
17:12:24 <wendyreid> ack garth
17:12:25 <NickRuffilo> Tzviya: It could be just a document in the publication...
17:12:39 <EvanOwens> Q+
17:12:40 <NickRuffilo> Garth: On the visual TOC that we have talked about, that would be pointable in the manifest, is that true or false?
17:12:54 <NickRuffilo> Tzviya: Pointable to as it is explicitly the TOC, or that it's the document?
17:13:16 <NickRuffilo> Garth: That it is identifiable as the visual TOC, so that if you provided neither of the other options, the reading systems could then bring this up.
17:13:18 <clapierre> clapierre has joined #pwg
17:13:33 <ivan> q+
17:13:40 <George> q+
17:13:47 <wendyreid> ack EvanOwens
17:13:47 <NickRuffilo> Tzviya: My opinion is that it shouldn't have a special marking.  Letting reading systems have so many fallbacks seems unnecessary
17:14:25 <NickRuffilo> Evan: Visual TOC - is that what's in a printed book?  Are these two options different from that?  Calling it all TOC is confusing.  Manifest or web navigation makes it clearer.  Is this separate from the text of the table of contents?
17:14:29 <wendyreid> ack ivan
17:15:28 <dkaplan3> q+
17:15:39 <NickRuffilo> Ivan: There is in the explainer, what we call the structured TOC, which is the machine interpretable HTML structure, which usually is a TOC that you refer to.  What we call the visual TOC is usable for the User Agent, but we don't talk about how it's built up, layered, and there we some notes that it could have SVG with all sorts of items or an image map, but which we don't say anything about that
17:15:40 <NickRuffilo> q+
17:16:26 <George> q-
17:16:39 <NickRuffilo> ...: As for what tzviya was saying, the manifest would show a machine readable version, but it would be having the identification of a visual TOC - is also something we may want to have.  As garth said, i'm not laying down on the road over this.  I'm saying give the option that if you want to have a TOC visually displayed, you can.  That was my feeling.
17:16:48 <wendyreid> ack dkaplan
17:17:31 <NickRuffilo> Deborah: I just wanted to say there are two separate issues - 'how is the navigation going to be encoded' and then there's the question of 'what happens for visual navigation' machine VS human readable.  I think that will be a 2nd ticket with how the documentation will be.
17:17:56 <NickRuffilo> ...: We need to know if you're not using a WP compliant reading system, etc, but i think it's idfferent.
17:17:59 <wendyreid> ack NickRuffilo
17:18:17 <wolfgang> s/idfferent/different/
17:19:03 <wendyreid> NickRuffilo: Is our TOC the solution for reading order, is having a logical readingOrder part of the MVP?
17:19:12 <wendyreid> Ivan: ReadingOrder is separate to TOC
17:19:48 <tzviya> q+
17:19:59 <wendyreid> NickRuffilo: I am always thinking of how to get rid of redundant information, having a TOC with reading order in it, is it necessary?
17:20:02 <dkaplan3> q+
17:20:04 <Avneesh> q+
17:20:05 <wendyreid> ack tzviy
17:20:31 <JuanCorona> JuanCorona has joined #pwg
17:20:32 <NickRuffilo> Tzviya: A long time ago we agreed to separate TOC and reading order.  I liked the direction deborah was going in - to separate navigation and visual.  I thought we got to the point where we reached a vote.  maybe we want to go back there
17:20:42 <JuanCorona> present+
17:20:53 <garth> q?
17:21:01 <wendyreid> ack dkaplan
17:21:23 <NickRuffilo> Deborah: Please - lets not discuss, lets vote, then create new topics on the unresolved issues.
17:21:38 <wendyreid> ack Avneesh
17:21:57 <ivan> proposed: the WP manifest does have a reference to a machine resolvable TOC; the draft will have to defined the HTML stucture for it. The TOC is optional.
17:21:59 <NickRuffilo> Avneesh: For the accessibility - identifiability of TOC is very important for accessibility needs.
17:22:12 <ivan> s/defined/define/
17:22:26 <tzviya> q+
17:22:52 <NickRuffilo> Garth: How does that proposed text match with the 'dual' option above?
17:22:58 <NickRuffilo> Ivan: I think we should separate those two things.
17:23:23 <garth> q?
17:23:33 <ivan> proposed:  the WP manifest does have a reference to a machine resolvable TOC; the draft will have to define the HTML stucture for it. The TOC is optional. The should be documentation (possibly separate from the WP draft) on how that TOC is used be RS-s and authors
17:23:59 <mgarrish> q+
17:24:08 <wendyreid> ack tzviya
17:24:08 <wolfgang> s/The/There/
17:24:31 <wolfgang> s/stucture/structure/
17:24:35 <wendyreid> ack mgarrish
17:24:35 <NickRuffilo> Tzviya: A few comments: I don't recall why we have the TOC as optional, but that troubles me.  I waould like to take out the parenthetical.
17:24:39 <dkaplan3> q+
17:24:53 <wendyreid> ack dkaplan
17:24:54 <NickRuffilo> Matt: Is it optional or recommended.  We don't have an optional - is it still a should?
17:24:58 <wolfgang> s/waould/would/
17:25:05 <garth> q?
17:25:17 <garth> q+
17:25:25 <NickRuffilo> Deborah: As for optional, if it is not present, our documentation for reading systems needs to say what happens.  For accessibility reasons, if the document doesn't create navigation, we need to document explicity navigation.
17:25:50 <NickRuffilo> Garth: If that was the proposed language, i'd give it a +1.  I know you wanted to separate the issues, what the other issue in the dual approach
17:26:05 <NickRuffilo> ivan: the other one is if the manifest should have a separate preference to a visual TOC.
17:26:21 <NickRuffilo> Garth: Thank you.  I just wanted to know if the other was JSON or not, but it's not...
17:26:27 <NickRuffilo> Wendy: Yes, that's a separate issue.
17:26:40 <dkaplan3> s/For accessibility reasons, if the document doesn't create navigation, we need to document explicity navigation./For accessibility reasons, in the absence of explicit navigation, the reading system will have to create navigation implicitly. So if we make the TOC  we will need to clearly document for both reading systems and content creators what is the implicit behavior in the absence of explicit navigation./
17:26:51 <NickRuffilo> ...: If we can decide on this, then we can log issues on the TOC for further changes.
17:27:26 <NickRuffilo> Ivan: I think the reason goes that the reading order ... it's important do document, but it's important we don't say must.  Recommended sounds like a sound argument.
17:27:34 <ivan> proposed:  the WP manifest does have a reference to a machine resolvable TOC; the draft will have to define the HTML structure for it. The TOC is recommended. The should be documentation on how that TOC is used be RS-s and authors.
17:27:43 <NickRuffilo> Garth: The proposed, most recent - change resolvable to readable, then drop the parenthetical?
17:27:49 <wendyreid> Proposed: The WP manifest will have a reference to a machine-readable TOC, the draft will have to define the HTML structure for it. The TOC is recommended. There should be documentation in the spec on how that TOC is to be used by Reading Systems and Authors.
17:28:05 <garth> +1
17:28:08 <ivan> +1
17:28:09 <NickRuffilo> +1
17:28:10 <timCole> +1
17:28:14 <jbuehler> +1
17:28:14 <mgarrish> +1
17:28:16 <duga> +1
17:28:19 <josh> +1
17:28:19 <wolfgang> +1
17:28:21 <tzviya> +1
17:28:23 <JuanCorona> +1
17:28:25 <dkaplan3> +1
17:28:29 <rkwright> +1
17:28:30 <Avneesh> +1
17:28:33 <laudrain> +1
17:28:37 <BenSchroeter> +1
17:28:44 <George> +1
17:28:48 <romain> +0.5
17:28:50 <MustlazMS> +1
17:29:05 <bigbluehat> +0
17:29:06 <George> q+
17:29:10 <Teenya> +1
17:29:13 <wendyreid> ack garth
17:29:14 <garth> ack garth
17:29:15 <dauwhe> +0.5
17:29:19 <wendyreid> ack George
17:29:38 <NickRuffilo> George: If there's only 1 document in the publication, the reading order is defined by that one thing, so the reading order must be defined, even if only one document?
17:29:41 <romain> q+, to ask what "documentation in the spec" means
17:29:46 <NickRuffilo> Ivan: That's already in the spec.
17:30:30 <NickRuffilo> Romain: I'm just wondering what we mean by there "should be" spec.  My thinking is that the way we define the HTML structure, if we are to define how reading systems are using it, thats the part of the spec that matters.
17:30:41 <NickRuffilo> ...: How the reading systems are interpreting this HTML structure.
17:31:00 <NickRuffilo> Wendy: This was the documentation proposed by Deborah as to using one method VS the other, one for RS one from authors.
17:31:17 <tzviya> +1 to romain
17:31:19 <tzviya> q+
17:31:21 <NickRuffilo> Romain: I think this documentation should be the spec and not just documents.  So it should be how the RS uses the TOC structure.
17:31:33 <wendyreid> ack tzviya
17:31:33 <NickRuffilo> Wendy: Which is why we specified it should be in the spec.
17:31:40 <wolfgang> s/the spec/in the spec/
17:32:02 <NickRuffilo> Tzviya: I agree with Romain, but I think we should have documentation for authors so that it's clear for them how they should be creating things.  We want to let both reading systems and Authors know what to do.
17:32:08 <wolfgang> +1 to Tzviya's proposal of a documentation for authors!
17:32:11 <ivan> resolved: The WP manifest will have a reference to a machine-readable TOC, the draft will have to define the HTML structure for it. The TOC is recommended. There should be documentation in the spec on how that TOC is to be used by Reading Systems and Authors.
17:32:22 <NickRuffilo> Wendy: Resolved, I haven't seen any -1s.
17:32:47 <ivan> proposed: the wp manifest will have a reference to a TOC which is not defined to be machine-readable. Such a TOC is optional
17:33:13 <NickRuffilo> Ivan: I think that is the other option on the table, we should once and for all say yeah or nay
17:33:25 <NickRuffilo> q+
17:33:59 <wendyreid> NickRuffilo: Do we want to add something saying it is defined in some way?
17:34:09 <duga> q+
17:34:11 <wendyreid> Ivan: It can be an image, SVG, etc
17:34:24 <mgarrish> q+
17:34:30 <ivan> ack NickRuffilo
17:34:31 <wendyreid> NickRuffilo: We should have a way to identify it
17:34:38 <wendyreid> ack NickRuffilo
17:34:50 <wendyreid> ack duga
17:35:14 <ivan> q+
17:35:26 <NickRuffilo> Brady: My question is - is this visual TOC different from other things we might identify, such as 'where is the reading start' or other interesting points.  Is this visual TOC one of the many things we might want to point to, or an extra special thing (or only thing)
17:35:28 <wendyreid> ack mgarrish
17:35:47 <garth> q+
17:36:14 <wendyreid> ack ivan
17:36:16 <NickRuffilo> Matt: I'm just wondering if this is even necessary.  What's the difference between a visual TOC and machine readable.  The reading system needs to make a determination about the usability of the TOC.  Do we just have two different semantics when we could jsut have 1.  If the RS can't parse it, it can't parse it.
17:36:40 <wolfgang> s/jsut/just/
17:36:42 <tzviya> q+
17:37:07 <NickRuffilo> Ivan: Responding to Brady, if we do this, it is one of those that you refer to.  We have the structure that if we have resources listed in the manifest, we can add additional things as part of the rel value.  There would be a rel value for 'visualTOC' there migth be other requirements for different types.  Structurally it's exactly the same.
17:37:43 <josh> q+
17:37:53 <Avneesh> q+
17:37:55 <mgarrish> q+
17:37:59 <NickRuffilo> Garth: it feels like this answers Matt's question, it isn't two ways to display the TOC, it's two different things.  A machine readable TOC, and things that are interesting.  As just one thing among many, but it is odd to vote on it separately, that's odd.  Do we want to have a way to note interesting places
17:38:17 <NickRuffilo> Ivan: we do have things like cover, description, and we already have one of those ways to describe important things.
17:38:18 <duga> s/garth/duga
17:38:57 <NickRuffilo> Garth: I like that answer - if the machine readable part was a TOC, but if it didn't have a machine readable thing, it would just flip to it...
17:39:03 <wendyreid> ack garth
17:39:07 <wendyreid> ack tzviya
17:39:47 <NickRuffilo> Tzviya: Brady said much of what I wanted to say - are we trying to duplicate epub here?  Much of what we're doing here exists in epub, but we should consider what it is we are trying to accomplish.  'does this add value to the reader'  These are two distinct things.
17:39:50 <wendyreid> ack josh
17:40:38 <ivan> q+
17:40:39 <NickRuffilo> Josh: Following on Tzviya, these two things are different.  The specification, even though we can't imaging a TOC that is both machine readable and presentational.  I haven't given up on that dream.  I just request that the specification doesn't preclude that something is both machine readable and presentational.
17:40:50 <wendyreid> ack Avneesh
17:41:56 <NickRuffilo> Avneesh: I'm confused here.  All the discussion is about having 2 for TOC - machine readable and visual, and a note that the visual may not be a TOC.  I'm just looking at the MVP and that TOC would be only presented.  It would be recommended, not compulsory.  The requirement that TOC should be only content.  So reading system should be able to identify it and put it in front of the user.  If it's not identified in the proper way, how would the readin[CUT]
17:41:58 <NickRuffilo> ...: it present?
17:42:52 <timCole> q+
17:42:53 <NickRuffilo> Tzviya: What we've proposed is mimicing what epub3 does with the nav doucment.  It uses strict HTML structuring, so a bit more expansive than what's in the nav document.  It is HTML so it can be rendered as an HTML document, and assistive technology, but it can be input for an automated TOC by reading systems.
17:43:29 <NickRuffilo> ...: When we are visual, we're talking about TOCs that use SVG, or heavy CSS, so maybe visual TOC is misleading, but we're talking about TOCs that are different from the machine-readable one.  The proposal is similar to epub...
17:43:35 <ivan> tzviya also answered Josh's question
17:43:37 <ivan> q-
17:43:41 <dkaplan3> q+
17:43:41 <NickRuffilo> ...: But it would have a list, and be used by the RS.
17:43:43 <wendyreid> ack mgarrish
17:44:02 <ivan> q+
17:44:48 <George> q+
17:45:02 <NickRuffilo> Matt: I think what's been mentioned earlier - using landmarks from epub, maybe we should consider that to differentiate the machine readable and the content and how the RS gets you there.  it looks like competing TOCs and fallbacks, and they have distinct purposes, but we should be clearer...
17:45:10 <wendyreid> ack timCole
17:45:11 <NickRuffilo> ...: maybe there should be landmarks instead of a bunch of links.
17:45:37 <zheng_xu> zheng_xu has joined #pwg
17:45:43 <NickRuffilo> Tim: Does our manifest prohibit content from appearing twice, so that something could appear with two different rels (so that you could have a machine readable and visual TOC)
17:46:10 <NickRuffilo> Ivan: Yes/no.  At the moment, the resources should have only a single entry for a specific resource.  The rel value can be an array of values.  So the same resources can be identified 15 different ways.
17:46:18 <wendyreid> ack dkaplan
17:46:21 <zheng_xu> present+ zheng_xu
17:46:29 <garth> q+
17:47:05 <NickRuffilo> Deborah: We don't need to solve every publication that everyone is going to write.  Somebody is going to say they don't like footnotes with ARIA, so they make sidebar footnotes, but as long as we document that to be an accessible WP, you also have to include footnotes in a specific way, someone will just do something different...
17:47:52 <wendyreid> ack ivan
17:48:01 <NickRuffilo> ...: My visual TOC of poetry is 3 different pages, done in 3 different ways - that's fine, but we haven't described that use case, and we don't have to.  If they want to be inaccessible but compliant, they just need to have the machine readable one and it'll work, we don't have to note each use case and address it.
17:48:01 <ivan> Proposed: drop the notion of ‘visual VOC’ and close issue #350
17:48:06 <tzviya> +1
17:48:07 <NickRuffilo> Ivan: I have a new proposal.
17:48:10 <duga> +1
17:48:12 <wendyreid> +1
17:48:13 <ivan> +1
17:48:14 <garth> -1
17:48:15 <NickRuffilo> +1
17:48:37 <dkaplan3> +1
17:48:42 <clapierre> s/VOC/TOC/
17:48:54 <timCole> -1
17:49:17 <dkaplan3> s/If they want to be inaccessible but compliant/If they want to compliant/
17:49:45 <NickRuffilo> George: I realize the use of a visual TOC but that can be overwhelming if there are 6 depths to the TOC, and a presentation to the reader would be more palatable.  in hopes of getting to only the machine readable, could you possibly trim the tree at a certain level?  Or having the presentation that is more palatable for a human?
17:49:46 <wendyreid> ack George
17:50:09 <NickRuffilo> Ivan: That can be done today with CSS.  You can have an HTML structure that is machine readable, but with CSS you can 'trim the tree'
17:50:10 <NickRuffilo> q+
17:50:20 <wendyreid> ack garth
17:50:56 <Avneesh> q+
17:51:13 <NickRuffilo> Garth: My -1 is that i'm happy to close issue 350, but I think we want to have the concept of doing what we want to do here.  This visual TOC is one of a handful of landmarks - not as a resource, but a pointer into another resource.  Here's my big long thing of HTML, here's the TOC, etc.  We shouldn't lose the concept that the visual TOC is a pointer to a resource.
17:51:41 <Avneesh> q-
17:51:43 <NickRuffilo> Wendy: A better proposal might be that we do not drop the notion - but close 350, then a champion should make a better proposal for landmarks.  and we can discuss.
17:51:47 <dkaplan3> Wendy++
17:51:56 <garth> +1
17:51:58 <wendyreid> ack NickRuffilo
17:53:15 <ivan> q+
17:53:19 <wendyreid> NickRuffilo: I like the concept of landmarks, the more I think about it the less a visual TOC make sense for MVP, less restricted is best
17:53:23 <wendyreid> ack ivan
17:53:33 <ivan> proposed:  close issue #350, possibly replace it with a more general notion of landmarks
17:53:39 <garth> +1
17:53:43 <NickRuffilo> Ivan: A point: we are not talking exclusively MVP - but here's the 2.0 proposal as proposed closer of this.
17:53:49 <Avneesh> +1
17:53:50 <NickRuffilo> +1
17:53:51 <duga> +1
17:53:52 <zheng_xu> +1
17:53:52 <ivan> +1
17:53:54 <timCole> +1
17:53:55 <wolfgang> +1
17:53:55 <mgarrish> +1
17:53:57 <tzviya> 0
17:54:00 <clapierre> +1
17:54:01 <dkaplan3> +0
17:54:06 <laurent_> 0
17:54:07 <jbuehler> +1
17:54:20 <laudrain> q++1
17:54:26 <JuanCorona> 0.5
17:54:27 <marisa> +1
17:54:35 <laudrain> s/q++1/+1/
17:54:46 <tzviya> +1
17:54:56 <George> +1
17:54:56 <dkaplan3> in that case, +1
17:54:56 <ivan> resolved: close issue #350, possibly replace it with a more general notion of landmarks
17:54:58 <rkwright> +0.5
17:55:01 <dauwhe> +1
17:55:04 <romain> +1
17:55:06 <josh> +1
17:55:44 <NickRuffilo> Wendy: We don't have any F2F updates, it will be in Boston/Cambridge may 6-7 2019.  Monday/Tuesday.
17:56:30 <NickRuffilo> Wendy: the 3rd possible option was the JSON TOC - but I'm happy to close these two issues, then log a new issue with my proposal and the remaining items...
17:56:43 <duga> +1
17:56:46 <ivan> +1
17:56:56 <dkaplan3> dkaplan3 has left #pwg
17:57:28 <Yanni> Yanni has left #pwg
18:00:54 <cmaden2> cmaden2 has left #pwg
18:01:27 <evan> evan has joined #pwg
18:03:32 <ivan> rrsagent, draft minutes
18:03:32 <RRSAgent> I have made the request to generate https://www.w3.org/2018/11/26-pwg-minutes.html ivan
18:03:32 <ivan> zakim, bye
18:03:32 <ivan> rrsagent, bye
18:03:32 <RRSAgent> I see no action items
18:03:32 <Zakim> leaving.  As of this point the attendees have been laudrain, dkaplan, wendyreid, Rachel, Teenya, wolfgang, franco, ivan, Yanni, romain, bigbluehat, JunGamo, George, Avneesh,
18:03:32 <Zakim> Zakim has left #pwg