Publishing Working Group Telco — Minutes

Date: 2017-11-20

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Tzviya Siegman, Wolfgang Schindler, Avneesh Singh, Luc Audrain, Rachel Comerford, Baldur Bjarnason, Peter Krautzberger, Wendy Reid, Dave Cramer, Deborah Kaplan, Gregorio Pellegrino, Toshiaki Koike, JunGamo, Matt Garrish, George Kerscher, Lillian Sullam, Joshua Pyle, Bill Kasdorf, Jun Gamou, Nick Ruffilo, Mateus Teixeira, Evan Yamanishi, Marisa DeMeglio, Takeshi Kanai, Chris Maden, Romain Deltour, Brady Duga, Ben Schroeter, David Stroup, Hadrien Gardeur

Regrets: Charles LaPierre, Daniel Weck, Garth Conboy, Benjamin Young

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo

Content:

1. approval of minutes

Tzviya Siegman: Approving last weeks minutes - any comments?

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-13-minutes.html

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-06-minutes.html

Resolution #1: las week minutes’ approved

Tzviya Siegman: Comments/questions on TPAC minutes

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-07-minutes.html

Tzviya Siegman: Any comments on 2nd day of TPAC.

Resolution #2: TPAC F2F Meeting minutes approved

Tzviya Siegman: I did read through the minutes - thank you to all those who took minutes. You did wonderful jobs - you are now in the queue for future minutes :)

2. Open issue: #103

Tzviya Siegman: There are a number of open issues and pull requests. We don’t have any open pull requests - but there was a lot of confusion over the issues, so we wanted to go through them all to make sure people understood.

Tzviya Siegman: https://github.com/w3c/wpub/issues/103

Tzviya Siegman: The current issue that hasn’t been closed is 103 - which refers to 101 and 94. My brain is wonderful.
… This has been resolved to a certain extent with pull request 101 - what this fundamentally comes down to is what we’re trying to accomplish with the address of the web publication - we’re trying to come up with a dereferencable URL - and something to happen when the URL exists. We discussed at TPAC and issue 94… I need to know what happens when the User Agent comes up with a URL. A search engine - for example - doesn’t know what to do with the JSON. So we’ve discussed what it can and cannot be. We’ve been going back and forth between JSON or HTML, but we’ve established that it needs to be HTML.

Nick Ruffilo: Why JSON at all?

Matt Garrish: We have agreement on HTML but we needed to decide if HTML needed to be a resource in the publication or not.

Tzivya: The question is about if the HTML needs to be a required part of the resource.

Dave Cramer: Does the HTML contain a link to the waybill (manifest)

Luc Audrain: yes

Tzviya Siegman: We are calling the ‘manifest’ a ‘waybill’ to not confuse with other manifests

Tzviya Siegman: consensus 2: the entry point document points to the waybill
… The point that matt brought up - is whether the entry point needs to be within the WP

Tim Cole: I don’t want to rush past Nick’s concern - the Waybill as a standalone JSON would be required to align with web application - or the application manifest approach. But that may be a point 2a. That there has to be a separate JSON file? Is that the agreement from TPAC?

Tzviya Siegman: Yes - that was what we talked about at TPAC. That the landing page would point to the JSON waybill that is within the document.
… How we left things with web-app manifest is in the air, so we’re not sure.

Matt Garrish: This is an issue that the web-app manifest people did, so we’re piggy backing on that. I think it’s impossible to stop people from embedding it, but that is not something that we’re recognizing at this point, but that is just the background.

Wolfgang Schindler: +1 to Tzviya

Tzviya Siegman: the question under discussion is whether the entry point (html file) needs to be within the publication. My opinion is that if this is what we’re calling THE url, then it needs to be part of the publication, otherwise the URL of the publication is something external. Something else, so we get into circular logic ‘this is the identifier but it isn’t exactly the publication.’

Dave Cramer: +1

Luc Audrain: +1

Joshua Pyle: +1 to including within the publication (tzviya)

Hadrien Gardeur: I think the problem we have here is we don’t have a clear idea as to what to do with the document. The URL will identify the publication. Returning HTML is a way to ensure how to work with the open web, but everything beyond that is very very vague. We are taking multiple concepts without mashing them together. Is this a start page? Is this potentially pointing to something else?

Nick Ruffilo: Is this going to be serving a viewer? I’m not even sure we have a concept that is unique to publications? Besides identification and HTML - as a group, lets figure that out.

Hadrien Gardeur: +1 to what NickRuffilo just said

Nick Ruffilo: I would like it to be a super marketing page and it could be part of the WP like the jacket in real world constantly changing, having it in the WP would be beneficial

Tim Cole: This dichotomy is in the current text. Web publication is a collection of one-or-more resources organized in a manifest, with a single logical work. As nick was saying - the content of the book. In the section 1-2 ‘what is a web publication’ We talk about it as a discoverable piece of information. Sometimes we’re thinking about it as a manifest and the entry page - sometimes we’re thinking

Nick Ruffilo: of it as the chapters and everything in order. We need to decide - and I think including it is fine as long as we understand that it always has to be there. As Nick pointed out - that piece is more dynamic than the reading order sections.

Tzviya Siegman: I’m going to jump the queue to note we’re writing the spec for the publication and not what sells the publication. All of the things that sell are fine, but not what we’re working on. I can have buy links - or a URL for buying, but that won’t be the URL for the publication itself.

Joshua Pyle: +1 tzviya

Ivan Herman: Following on what you said Tzviya, I have the impression that we are arguing upside down. We’re looking at the usages for pages and extrapolating from there. My view is different. I start by the option or the thinking that we have a publication, I need an entry point. It’s part of the web publication because it’s the one that really identifies things. What various publishers do with it is besides the point. It’s a place where publishers may decide to put certain things - they may decide to have an empty page and it’s just to get the browsers going. it’s all beyond what we want and can specify. On the other hand, if we take a web publication and pull it offline, what we put offline are those resources that are listed in the publication - so not having the page that identifies that page is unnatural.

Dave Cramer: On the URL as an HTML page - I have no assumptions as to what it contains that it has to contain a link to the manifest. We need to get to the web publication goodness from it’s URL. I think of what might that page be used for - that’s the choice of the document author.

Tzviya Siegman: +1 dauwhe

Ivan Herman: +1 dauwhe

Hadrien Gardeur: +1 to what dauwhe said too

Brady Duga: We’ve been talking about this - and there’s resistence, but i’m curious that we’ve listed these requirements - but there could be more than one page that satisfies those requirements - are they both landing pages? Must a landing page be unique? Can there be multiple landing pages for a single publication? That could be table of contents, it could be chapters 1-20? How does a user or a search engine know that this is the canonical landing page of a document?
… If we don’t know, than maybe we just have one document that points back?

Hadrien Gardeur: I agree with Dave’s take about being minimal about what it does. Along the line of what Brady was actually explaining. In Readium, we have a similar manifest. We separate two concepts - identifier which is a URI, then we have a start-page. Identifying the start page is another. When you list the collection of documents, you can do that within or without the reading order. The reason we are having trouble is the difference between those concepts are. If we can do that, we’re in a good direction.

Tzviya Siegman: please take a look at the opening comment in https://github.com/w3c/wpub/issues/94

Ivan Herman: Back to Brady - yes, there could be several resources linking back to the manifest. The question came from the other way around. If I declare the entry point of the book, that’s what counts. Whether it is canonical or not, that’s something I can put into the list. The canonical identifier of the book - what happens if I dereference those…

Brady Duga: What you’re saying Ivan is that there will be a URL identifier that will be in the manifest - and that must be one of the pages. So we’ve defined the requirements of the landing page, which points to the manifest, which points to the landing page?

Joshua Pyle: That sounded circular

Bill Kasdorf: rather than thinking of it as circular, it’s also a sort of handshake

Brady Duga: Shaking your own hand :)

Tzviya Siegman: At a minimum the landing page HTML page points to the manifest.

Joshua Pyle: :-)

Ivan Herman: I think the only place where we don’t have 100% agreement is whether that page is part of the document. I have the impression is that - what the text says right now is that entry point SHOULD be part of the document. For the time being, lets leave it open if it’s a SHOULD or a MUST. We are repeating the arguments we had on github, and that’ll go on forever.

Tzviya Siegman: do we feel we can close the github issue yet?

Hadrien Gardeur: I don’t think we have a good term - entry point doesn’t work for me

Tzviya Siegman: we can change it…

Bill Kasdorf: by “document” you mean “publication” correct?

Ivan Herman: BillK, yes

Hadrien Gardeur: we can say it’s a temp term, but i am not happy with it. We might not always be able to reach that page or the manifest. I don’t think we can expect always to get a 200 OK for the page or the manifest. As long as we acknowledge that part, i’m OK with the rest.

Tzviya Siegman: I’m not sure your concerns, and why you expect it to get errors

Hadrien Gardeur: the manifest itself might be behind a paywall, so we might have a link to a page that we cannot access.

Ivan Herman: You’ve given an argument why that page must be part of the publication - because if there is a (pay)wall, then what I would expect is that page - together with a manifest, is behind a wall. If someone wants to get through, they need to get access - once they have access, they can get to the page. It should be the same access level…
… As for the name - I absolutely agree not the best name.

Hadrien Gardeur: Having access to the page but not the manifest is a bad idea.

Ivan Herman: You said something Tzviya - because we don’t have absolute agreement, we should close the issue. We should discuss it further within the issue. We should also see if others outside the group have an opinion

George Kerscher: I’m reading a document and want to make a bibliographic reference. I go to the manifest and get the canonical identifier. I have to have that information to make the reference - so I think that it’s essential to have the publication in the manifest.

Tim Cole: Right now at least 1 Address is required in manifest, Canonical URL is SHOULD

Tzviya Siegman: That might not be necessary as we’re still working through identifiers. But we’re talking about the landing page being referenced through the manifest. As Tim just noted, one address is required in the manifest.

Nick Ruffilo: which side of the wall: should be made public
… lot of value to be outside the wall for search engine to get metadata or information

Bill Kasdorf: the canonical URL can be part of a bibliographic reference (which also provides title, publisher, etc.), it is not the entire bibliographic reference in itself

Ivan Herman: I don’t think at this moment we don’t have expectations of that sort - or if this group should define it. As for the previous comment - we have to make a different about the page with information on the publication from the publication itself. If I dereference and hit a paywall, a decent publisher will lead me to a page that forces me to pay to get the information. These are two different functions and we should not mix them up. Again - we don’t define these processes.

Tzviya Siegman: when we write a best practices document - we can address these items.
… we need some decisions - ivan you noted we shouldn’t close, but we need to figure out what decision we want to put in the document.

Ivan Herman: I have the impression - and matt should tell me if i’m right - we gave an ulterior approval to one pull request that was already merged. The things are happening upside down but it made the discussion easier. That went into the document, and Matt pulled it into the main document. In a sense, what we seem to say is that what that merge says is fine with everyone. It tells what we say, keeps things on a SHOULD level and not a MUST - which is fine. we closed the discussion for the time being. Matt, am I right in what I said?”

Matt Garrish: Yes, that was what was done.

Ivan Herman: The resolution: Matt did it right

Resolution #3: (Ulterior) approval for the merge of #101

Tzviya Siegman: We have pull request 101.

Ivan Herman: please put a comment in 101 that it is closed.

Tzviya Siegman: https://github.com/w3c/wpub/pull/101

3. Getting to FPWD

Tzviya Siegman: That’s an excellent segue into getting to first working draft of Web Publications and Packaged Web Publications. Matt - what do you need from us?

Matt Garrish: what i would like is review - everyone does a full readt hrough of this. Make sure everything reflects the latest opinions. Plus there are still some sections outstanding - privacy and security for example.

Tzviya Siegman: David Wood said they would write something for the privacy section

Dave Cramer: I’m concerned about the current state of the draft. I would like us to be at the point where we could make a sample. The strawman has clothes, but no straw. Even if we’re still trying to work with web-app manifest, at least we should propose some extensions and write them down and make a sample with consequences. have something in the spec to say ‘this is a web publication’ and ‘this isn’t’

Ivan Herman: One memorable moments - you are putting the bar too high. I think it’s OK to publish it as-is. Having an experiment in a few weeks would be great, but the first published working draft doesn’t mean we are done. Yes we should review. Yes, we need to unify terminology issues. formally speaking is what I will need is a formal vote from the working group - on a call with an explicit 5 day call for consensus - i leave that to the chairs, but we have to have a clear call for votes. We should do that together with the two other documents to make things clearer and more unified.

Dave Cramer: I feel like it’s hard to have a first public working draft without a hello world.

Ivan Herman: I can show you many public working drafts without that. What we are doing is putting a stake in the ground.

Nick Ruffilo: Why can’t we just hello world?

Ivan Herman: We want something published before EOY. I don’t want that to hold things up. It could carry on for a long time, so we just need to push forward.

Tzviya Siegman: One thing we discussed was the ability to publish as often as a weekly draft. So don’t think it’s something frozen in time, we hope to start publishing frequently.

Hadrien Gardeur: I just wanted to say I agree with Ivan. I think it’s too early on the serialization. We’ve discussed exploring the web-app manifest to see if it’s a real option or not. Without some of the work on how we serialize the infoset, it would be very difficult to do a hello world. But we could use an existing serialization - hopefully one compatible with the the current working draft. But I think we need to do more work first.

Ivan Herman: Remind ourselves - we have to have a similar vote on two other documents - and all before end of year.

Baldur Bjarnason: Bear in mind that my interests are a bit focused - i am all about keeping things safe.

Tzviya Siegman: If you need help - be in touch with ivan, matt, etc. Remember for now, this is first public draft, it can be very skeletal
… PWP - David Wood in Australia - has set some time to get this going. He’s trying to work with times that aren’t insane for US and EU, but there are no times that work for all AUS, US, and EU. The first draft will be skeletal - we haven’t decided on what to do with packaging - so that will be very skeletal.

Ivan Herman: What about the locator document? Tim what do you need from us?

Tim Cole: It’s not in bad shape. I got delayed this week. I need some more editorial work. Hopefully Benjamin can help me edit. There is one more pull request - as what we need to do about fragment identifiers. Fragment identifiers only come into place if we define media type as WP or PWP, the later is very likely. They will only be fragment identifiers only with those media types, we won’t try to use generic HTML identifiers. I think the locators draft, once cleaned up a few items, should be ready to go to vote.

Tzviya Siegman: did you hear back from CFI comments?

Tim Cole: There are several issues that need resolve after the first public working draft. There’s also been an issue raised on the shadow DOM - how do you do locators in context of the shadow DOM.

Ivan Herman: not a discussion we need to have now…

Tzviya Siegman: Worth looking at the accessibility OM

Tim Cole: good enough to get a reaction from people - get reactions from outside the working group

Ivan Herman: The formalities - I need a formal vote for all three documents. The formal vote says that the group has a consensus with the short names in the document. I then submit to our management. It takes a few days from there. All documents need to get checked against the pub rule checker. That’s an obligatory thing to do. I then have to install all those documents. All-in-all I would think I need 1 week after the week before they are published. And work ends around 20 December, so we should head for publication by the 15th at latest - so everything should be closed in about 2 weeks from now. I am mostly worried about PWP.

Tzviya Siegman: I’ll follow up with David.

Ivan Herman: The locator document is in a completely different stage. I don’t worry about that one.

Wolfgang Schindler: Is there any PWP document yet accessible for us?

Ivan Herman: Not yet

Dave Cramer: December 13, 1200Z: Deadline for publication requests before moratorium

Dave Cramer: https://lists.w3.org/Archives/Member/chairs/2017OctDec/0026.html

Ivan Herman: OK - we have to hurry then - we should have the vote at least for Web Pub and locators next week. Hopefully we have something the week after.

Tzviya Siegman: OK - sounds hopeful. Hopefully Dave Wood will be able to work on something this week. I’ll see if we can talk today

Tim Cole: Ivan - in that regard, don’t we normally announce the vote and the results are in before the call?

Ivan Herman: Formally speaking - we can vote next week on the call - we announce it on the working group. Formally speaking, there is one week so people can object. That way I can start with the formal procedures.

Tzviya Siegman: We had a holiday schedules agenda. One minute left. Any other business?
… talk to everyone next week

4. Resolutions