16:29:06 RRSAgent has joined #pwg 16:29:06 logging to https://www.w3.org/2017/12/11-pwg-irc 16:29:07 rrsagent, set log public 16:29:07 Meeting: Publishing Working Group Telco 16:29:07 Chair: Tzviya 16:29:07 Date: 2017-12-11 16:29:07 Regrets+ 16:29:07 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2017Dec/0008.html 16:29:07 ivan has changed the topic to: Meeting Agenda 2017-12-11: https://lists.w3.org/Archives/Public/public-publ-wg/2017Dec/0008.html 16:40:42 cmaden2 has joined #pwg 16:43:28 jbuehler has joined #pwg 16:51:57 NickRuffilo has joined #pwg 16:53:43 dkaplan3 has joined #pwg 16:56:28 Avneesh has joined #pwg 16:56:50 scribenick: nickruffilo 16:56:59 present+ 16:57:02 present+ wolfgang 16:57:02 present+ 16:57:13 present+ 16:57:38 laurentlemeur has joined #pwg 16:58:08 present+ 16:59:22 present+ 16:59:26 laudrain has joined #pwg 16:59:31 present+ 16:59:49 present+ 16:59:57 pkra has joined #pwg 16:59:57 baldurbjarnason has joined #pwg 16:59:58 present+ 16:59:59 present+ 17:00:01 present+ 17:00:10 present+ dauwhe 17:00:36 toshiakikoike has joined #pwg 17:00:38 present+ 17:00:42 rdeltour has joined #pwg 17:00:56 JunGamo has joined #pwg 17:00:59 present+ 17:01:03 present+ 17:01:07 present+ 17:01:33 lsullam has joined #pwg 17:01:33 mateus has joined #pwg 17:01:42 present+ 17:01:44 present+ 17:01:58 Tzviya: "Agenda got an update - are there new members on the call today?" 17:02:16 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-12-04-minutes.html 17:02:21 josh has joined #pwg 17:02:21 tzviya: Minutes from last week - Any comments? 17:02:25 Topic: last week's minutes 17:02:29 HeatherF has joined #pwg 17:02:30 RESOLVED: meeting minutes approved 17:02:34 ...: Minutes approved. 17:02:36 present+ 17:02:42 present+ 17:02:46 present+ Heather_Flanagan 17:02:58 present+ George 17:03:25 present+ Chris_Maden 17:03:40 BenSchroeter has joined #pwg 17:04:10 present+ 17:04:15 present+ 17:04:25 Topic: PWP ad a FPWD 17:04:27 https://w3c.github.io/pwpub/ 17:04:31 ...: Lets take a look at the drafts for PWP. Dave Wood sent them around over the weekend. 17:04:37 George has joined #pwg 17:04:41 rkwright has joined #pwg 17:04:53 ... Comments? 17:04:59 present+ George 17:05:01 s/ad/as/ 17:05:03 q+ 17:05:12 ack dauwhe 17:05:13 ...: This is about looking at packaging already in WP. 17:05:18 regrets+ garth 17:05:30 q+ 17:05:34 Dave: I've mentioned things like this before - but it seems very early for first public working draft - and we don't have a packaging mechanism or anything. 17:05:42 ack ivan 17:05:47 ...: A large portion is issues and editor's notes 17:06:27 q+ 17:07:17 Ivan: At this point, it's all we can say - and that's the direction to the world - we are not in a place to make a decision on the packaging format. This is clear from the document. From a first draft, we want to say 'this is the direction we want to go' and that's all we can say. We could leave it open and not publish for a long time, but nobody really knows where we want to go with packaged 17:07:17 web publications, and there were controversies around that - people thinking we would define our own. I think it's worth the while to publish now to put that info out. 17:07:20 present+ 17:07:36 q? 17:07:41 Dave: There are cultural differences across different parts of the W3C where some places editors drafts are more final documents. 17:07:45 ack George 17:07:50 Ivan: That's true - it is different for different groups. 17:07:53 marisa has joined #pwg 17:08:25 George: From my reading - there was two options - the option for packaging where people could define their own rules and individually make up their own packaginag - are we wanting to say that in a public draft that they can roll their own? 17:08:32 duga has joined #pwg 17:08:35 present+ 17:08:45 Hadrien has joined #pwg 17:08:52 present+ 17:09:38 cmaden2 has joined #pwg 17:10:23 s/packaginag/packaging 17:10:26 Ivan: It is there - in a sense that there is now a concept of conformance classes - that you can declare yourself conformant to the general part of PWP that you are a packaged WP - but you roll out your own packaging. Obviously - what did come up, is the next generation of PDF - then you could define yourself as conformant. This is clearly controversial thing. To go back to what dave was saying, 17:10:26 these sections are short, they are only a few statements. I don't expect this spec to be very long, but it's better to get them out for discussion early on. If the reaction is 'no way' we can discuss. 17:11:27 Tzviya: Any other comments about this draft? --- no comments -- OK, I propose we go through this - lets leave this open for comment for 5 days, then have a freeze on editing, so we can publish it in the new year - in the first week in January. Are we ready to move forward with a vote? 17:11:31 PROPOSED: Publish the PWP as a FPWD, with the short name pwpub, expected publishing date 4th of January 17:11:42 +1 17:11:45 +1 17:11:46 +1 17:11:47 +1 17:11:47 +1 17:11:47 +1 17:11:47 +1 17:11:49 +1 17:11:49 +1 17:11:50 +1 17:11:50 +1 17:11:50 +1 17:11:51 +1 17:11:51 +1 17:11:52 +1 17:11:55 +1 17:11:56 q+ 17:11:56 +1 17:11:59 0 17:12:01 0 17:12:04 0 17:12:06 0 17:12:07 +1 17:12:11 +1 17:12:37 0 17:12:47 q+ 17:12:48 0 17:12:55 Laurent: Because I feel that it is empty - and some people will misunderstand the content in the draft, but we could still publish it one month after with an editorial note. 17:13:05 ReinaldoFerraz has joined #pwg 17:13:06 ...: Just keep it on the side until there is more meat to put inside. 17:13:20 Ivan: The biggest meat would be the packaging format itself... And we know that in 1 month nothing will change. 17:13:27 Laurant: maybe you are right... 17:13:31 +1 17:13:35 present+ 17:13:43 s/Laurant/Laurent/ 17:13:45 Ivan: We're dependent on external movement - which is the biggest challenge. 17:14:01 q? 17:14:05 Laurent: Maybe we should add a note that this is just a skeleton - and what we expect for people who see this. A note that this is a placeholder. 17:14:35 Ivan: If you look at things with 2.1 and 2.2 - they are not empty skeletons. Those are much more important statements than the packaging format itself - like the clause I just outlined. 17:14:58 Tzviya: It would be good to specifically state we are awaiting information from the packaging 17:14:59 ack NickRuffilo 17:15:47 q+ 17:15:52 Since I don't have a working microphone: I don't understand it well enough to make an informed decision; thus neutral. 17:15:54 ack baldurbjarnason 17:16:05 Nick: What about an intro that provided reading context - into why we are publishing and what readers are expected to get 17:16:44 Baldur: I think it's much too early - but if we cannot publish a draft with more meat on it's bones without more clarity - then we shouldn't publish until that is ready. I don't think we should publish a PWP draft until we have more details on the WP side. I feel it's too early 17:17:40 Tzviya: If we wait too long, we might never have a draft. We have a timeline to follow. I understand the reluctance. The feedback about requesting feedback - I've seen this in other groups. With ARIA we put a list of questions in the first working draft - so we could just put in a list of questions in with the document. 17:17:53 ack ivan 17:18:55 q+ 17:19:49 ack dkaplan3 17:19:50 Ivan: Reflecting back on Nick's proposal - it's perfectly fine to put - either in the abstract or the status of the document - that we are looking for reactions on specific points - i think there is a part of the document that is not dependent on specificities on the format of packaging itself. We have had lots of discussion on the basic definition of what a packages web publication - and the 17:19:51 conformant classes - and the earlier we have agreement on those parts, we can plug in the community packaging formats afterwards. Making that reference to those classes very explicit - 'this is why we publish, because we want that part ready, and have an agreement with the community and ourselves, and we will complete the package format when the community is ahead of it' That makes sense - and 17:19:51 publishing like that makes sense. 17:20:27 +1 to Ivan/Nick proposal 17:21:11 +1 dkaplan3 17:21:14 Deborah: the reason it's good to publish - we are all perfectionist, and we all want this perfect - if we publish a skeleton, it's out there, and we will all do what we need to make it real. If we don't publish it until it has more meat, we will keep pushing off - and we will have an asymptotically perfect draft. Lets make a skeleton, and then make it real. How do we cope with a desire for 17:21:14 perfection and making it real 17:21:18 +1 17:21:55 PROPOSED: Publish the PWP as a FPWD, with the short name pwpub, expected publishing date 4th of January, but add a text into the intro part on the fact that we expect the community to comment on section 2-4 17:22:28 +1 17:22:31 +1 17:22:37 +1 17:22:37 +1 17:22:39 +1 17:22:42 +1 17:22:48 +1 17:22:48 +1 17:23:00 +1 17:23:01 +1 17:23:05 +0 still. Doesn’t address my concern that this spec is fundamentally waiting on the packaging issue. 17:23:07 +1 17:23:09 +1 17:23:09 +1 17:23:12 +1 17:23:15 +1 17:23:17 +1 17:23:18 +1 17:23:31 RESOLVED: Publish the PWP as a FPWD, with the short name pwpub, expected publishing date 4th of January, but add a text into the intro part on the fact that we expect the community to comment on section 2-4 17:23:31 +0 17:23:39 +0 17:23:53 Topic: Revisiting the locator FPWD 17:23:56 0 17:24:07 as before, my limitation more than the spec. 17:24:12 https://rawgit.com/w3c/publ-loc/new-things-only/index.html# 17:24:20 Tzviya: I'm going to skip the ARIA overview (we'll do it next week). We got feedback on the locators document. Tim and Ivan worked over the weekend to clarify the document. Link above to the revision. 17:25:49 Tim: Some concerns raised were things we already decided in the annotations recommendation - therefore they weren't things we could do anything about. We think it happened because we repeated most of the selectors from the web-annotations recommendation - we did it because we referenced them - and we wanted people to understand that you didn't have to include the parts, just the resources location 17:25:49 . So we wanted to rely on the references instead. There were some last minute changes to the introductions. 17:25:49 q? 17:25:51 present+ tcole 17:26:07 q- 17:27:49 Ivan: What I did if you look at the document - it's much more short. I cut out essentially everything that is non-normative. I left only some things - the top level notions - because it was better to make the document readable. Everything else - the various selectors we inhereted - i took them out. The document now essentially contains the parts that are normative. It is much clearer. As a 17:27:49 consequence, I re-wrote the whole introduction. I have a separate section that gives an outline of what we inheret - i have examples from there. Then there is a separate section about what we do - and the normative editions. That takes away the possible problem of getting a bunch of issues that are things we cannot act upong. It's not our goal, and per charter - we are not allow to go back 17:27:50 and change an existing recommendation. 17:28:19 Tim: This doesn't resolve all of Daniel's issues - he had concerns about selectors that span more than one file. He thought it was overly complicated. But that's a post FPWD I think. 17:29:43 Ivan: It may well be that we also can count on the fact that Daniel will come back and question the whole line of taking up the whole annotations spec and using that as a starting point. At least by removing things that are not our own, we at least have a starting point. Essentially, instead of publishing the FPWD in the form it was a week ago, we would take this verison here, and we use that 17:29:43 as the FPWD - then we can have a much more concentrated discussion. 17:30:12 Tzviya: I envision this becoming a bigger discussion - about something expanding multiple DOMs is one of the biggest discussion we will have. 17:30:21 q+ 17:30:23 Ivan: the only point we have is that we're taking out things that are unnecessary to have. 17:30:23 q+ 17:30:28 ack bigbluehat 17:31:07 q+ 17:31:40 Benjamin: Locators is always confused to me - I know the locators term is probably inhereted by EPUB, but the document doesn't express why it uses locators - and doesn't explain why it would be useful to people who know annotations - where it is not quite clear what you're talking about when, and you have to turn back and forth. Once I understand it, I can explain it better to something more web 17:31:40 annotationy 17:31:52 Tim: I think it had to do with locating resources 17:32:25 ack ivan 17:33:32 Ivan: What happened is that the web annotations spec uses the term 'specific resource' which is more general and includes other features we don't care about. What I did is that I made an explicit statment that we use locator in this document, it is an alias to 'specific resource' and we did it as it is easier to read. If you can add to the text something that is more readable - please do. 17:33:34 +1 to ivan 17:33:41 ack wolfgang 17:34:25 q+ 17:35:06 ack ivan 17:35:10 Wolfgang: I understand of separation of concerns about things we MAY define and change - and things in the web-annotation spec that we cannot change. But a practical use, i think it would be helpful to have all these locators that we are re-using, or defining new ones in this document - and not being forced to consult the web-annotation doc. It's not general objection, but practical. I want to 17:35:10 locate any thing with different ways. It's nice to have one document that I could consult to do this. Locator is much much better than a specific resource, which didn't mean anything to me before I joined this group. 17:35:33 q+ 17:36:47 q+ to talk about not duplicating 17:36:50 Ivan: This is exactly the argument we had to ourselves - when we created the official 'editors draft' We pulled in all the locators that are defined in one place - but it's clear it's lead to misunderstandings. We already had some discussion in this group - which had the same origin. There were a number of things there that were not specific to web publications. In this sense - we created more 17:36:50 harm than good. At some point in time, we would have some accompanying document - best practics or something - which we will clearly have to have. In that case, at that place - when we are techically done - we'll have to do a separate note that describes that, or add all the inhereted things - but all that should be later, when we are 'done' 17:37:06 Tzviya: What do newer members things about this? 17:37:09 ack big 17:37:15 ack bigbluehat 17:38:25 Benjamin: Maybe we just need to change the title to clear things up. Locators sends a signal that we're defining something new. Possibly 'Web-annotations for Web Publications' might be more clear that we're extending something for web publications - then Locators becomes something we are expanding, or restricting from the web-annotations. I realize specific resources as vague - but locators 17:38:25 doesn't come with implicit actions. 17:38:27 ack tzviya 17:38:27 tzviya, you wanted to talk about not duplicating 17:38:28 I see locators as a much broader concept than "web annotation", e.g. think of cross-references 17:38:51 q+ 17:38:55 ack baldurbjarnason 17:38:56 Tzviya: In my life as a spec writer - we do alot to avoid duplication. I really want to just point - and we can say 'if you need the addendum, stay here. 17:39:16 +1 Tzviya: Hyperlinks++ 17:40:25 q+ 17:40:34 s/alot/a lot/ 17:42:01 Baldur: I've been quite anxious about the locator spec because i was very strongly against epub CFI - in early epub 3.1 - I've started looking at it agian. Fundamentally I'm not sure this document -- it doesn't provide a strong argument for it's own existence. First, what is provides beyond the data model, we aren't in a position to have an opinion on -such as a fragment identifier - since we 17:42:01 don't know what the package looks like. The second - anything that spanns multiple resources is not our job - it's a job for the HTML spec. Finally - the name - as people mention before - is confusing. It will lead to the same issue as CFI. One of my objections to CFI is that they were inappropriate for content production. They were not good at linking two different epubs together. When I 17:42:02 raised this issue, I was assured that CFIs were primarily being standardized as internal for bookmarks and were not going to be recommended for production - yet all of those qualifiers were later thrown out the window - and I'm concerned we will see the same thing. What was originally something for internal, will end up being used between content linking between publications... 17:42:39 ...: I have a decently long email in draft - I'm really skeptical about the specification, even with the changes made over the weekend. I'm hesitant that we use it as is. 17:42:57 q? 17:43:33 ...: I'm OK with the web-annotations spec, but my concern is that the additions are either not-our-job, or too early - as it's too early to have opinions about packaging format - yet we have a spec that hinges on that. 17:43:34 ack ivan 17:44:19 The fragment identifier is meaningless outside of packaged publications. 17:45:14 Ivan: I do not agree. The spec as it stands does not refer to the packaging format. It refers to the publication - that there is a resource URL that has a list of resources within the document. We don't refer to the package for the reasons you noted. The only thing we noted is that we need a locator that requires a list of resources. I don't think it's up to the HTML working group - it does 17:45:14 not care or work on issues around several resources together. What we do beyond publications - is to address this concept - to have many resources that are bound together with a single URL. I believe it is a part of the group. If it's the right solution - we will see. 17:45:58 q+ 17:46:03 Tzviya: I don't agree that the fragment ID is meaningless outside of the package. If you have comments - after we publish is a great time to do so. We want to know if this new format is the way to go. We are not looking for perfection. We do not have to agree completely, we just need general concensus. Is the shortened format the way to go? 17:46:15 ack jbuehler 17:46:47 Jeff: I wanted to mention - the name of the document 'locators' what we're talking about is a web-annotation model for publications. What we're referring to - maybe we could call it something related to that. 17:46:48 q+ 17:46:52 ack ivan 17:47:57 Ivan: I don't agree we should rename. We started with 'web annotations, we extended something as it was one of our use cases. The same mechanism can be used - but just to have a means to record bookmarks in the middle of the document. It's different than what we usually use for web-annotations, and we need that as the traditional way doesn't work. 17:47:57 q+ 17:48:32 q? 17:48:38 Tzviya: Maybe i've heard too much about web-annotations, so i'm more about using the name web-annotations in it. 17:48:48 ack NickRuffilo 17:49:45 Nick: "What about 'Extending web-annotations in Web Publications' 17:50:00 Ivan: We have all the arguments around it, but not sure we have an agreement... 17:50:16 Tzviya: 'Lets circle back to the name. Do we agree on publishing the shortened version? 17:50:25 PROPOSED: Use the short format (https://rawgit.com/w3c/publ-loc/new-things-only/index.html#) as an alternative to the FPWD document for Locators 17:50:30 +1 17:50:32 +1 17:50:32 +1 17:50:32 +1 17:50:34 +1 17:50:38 +1 17:50:39 +1 17:50:45 +1 17:50:45 +1 shortened version is less harmful than the longer one. 17:50:46 +1 17:50:46 0 17:50:52 +1 17:50:53 +1 (avoiding duplication is good) 17:50:54 +1 17:50:55 +1 17:50:58 +1 17:51:03 +1 17:51:05 Wolfgang: The reasons I gave earlier - I prefer the full version 17:51:33 0 (no objection - I don't understand the elements of the arguments or the alternatives so can't weigh in) 17:51:41 Wolfgang: It would be better to put more pointers to the existing annotations spec. 17:52:03 ...: If we make things more explicit, as to the use, i think we could use that information in the document 17:52:25 RESOLVED: Use the short format (https://rawgit.com/w3c/publ-loc/new-things-only/index.html#) as an alternative to the FPWD document for Locators 17:53:05 Ivan: I propose we rename it after publication. This is a longer discussion - finding the right now. We may have to change or keep the short name, which isn't hugely important, but I'm worried about getting into a long discussion. 17:53:08 q+ 17:53:12 ack NickRuffilo 17:53:27 +1 to Nick 17:53:45 Indeed, the title is very important. 17:54:20 Nick: I feel it is important to at least discuss 'locator' vs web-annotation in the title. 17:54:41 Josh: I agree - once a term is out, we can't get it back. If we try to change it later, it will be confusing. 17:55:08 Tim: Can I suggest that - by thursday, people submit names, and we vote next week? 17:55:14 Tzviya: That should be OK. Ivan? 17:55:36 Ivan: I am considering the practicalities of changing things. Thursday should be the LAST day for submission... 17:55:56 Tzviya: Let's say wednesday - the prize for winning is the knowledge of contributing. 17:56:25 Tzviya: 280 character limit 17:57:01 Tzviya: We will resolve monday. Any other business? 17:58:14 Thanks! 17:58:14 cmaden2 has left #pwg 17:58:28 dkaplan3 has left #pwg 17:58:45 rrsagent, draft minutes 17:58:45 I have made the request to generate https://www.w3.org/2017/12/11-pwg-minutes.html ivan 17:59:13 rrsagent, draft minutes 17:59:13 I have made the request to generate https://www.w3.org/2017/12/11-pwg-minutes.html ivan