<dauwhe> https://twitter.com/WAWilsonIV/status/929512808412200960

<scribe> scribenick: nickruffilo

approval of minutes

<tzviya> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-13-minutes.html

Tzviya: Approving last weeks minutes - any comments?

<tzviya> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-06-minutes.html

RESOLUTION: las week minutes' approved
...: Comments/questions on TPAC minutes

<tzviya> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-11-07-minutes.html
...: Any comments on 2nd day of TPAC.

RESOLUTION: TPAC F2F Meeting minutes approved

<laudrain> too late

tzviya: 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 :)

Open issues

...: 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> https://github.com/w3c/wpub/issues/103
...: 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: Why JSON at all?

Matt: 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.

<laudrain> yes

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

<laudrain> yes

tzviya: We are calling the 'manifest' a 'waybill' to not confuse with other manifests
... 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: 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: 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: 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> +1 to Tzviya

Tzviya: 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.'

<dauwhe> +1

<laudrain> +1

<josh> +1 to including within the publication (tzviya)

Hadrien: 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?

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> +1 to what NickRuffilo just said

<laudrain> Nick: I would like it to be a super marketing page and it could be part of the WP like the jacket in real world

<laudrain> … constantly changing, having it in the WP would be beneficial

Tim: This dichotimy 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

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.

<josh> +1 tzviya

Tzviya: 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.

Ivan: 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: 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> +1 dauwhe

<ivan> +1 dauwhe

<Hadrien> +1 to what dauwhe said too

Brady: 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: 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> please take a look at the opening comment in https://github.com/w3c/wpub/issues/94

Ivan: 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: 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?

<josh> That sounded circular

<Bill_Kasdorf> rather than thinking of it as circular, it's also a sort of handshake

<duga> Shaking your own hand :)

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

<josh> :-)

Ivan: 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: do we feel we can close the github issue yet?

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

tzviya: we can change it...

<Bill_Kasdorf> by "document" you mean "publication" correct?

Hadrien: 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: I'm not sure your concerns, and why you expect it to get errors

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

Ivan: 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 what to put there. But not the best name.

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

Ivan: 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: 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.

<timCole> Right now at least 1 Address is required in manifest, Canonical URL is SHOULD

Tzviya: 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.

<laudrain> Nick: which side of tha wall: should be made public

<laudrain> … 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: 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.

tzivya: 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: I have the impression - and matt should tell me if i'm right - we gave an alterior 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: Yes, that was what was done.

Ivan: The resolution: Matt did it right

Tzviya: We have pull request 101.

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

<tzviya> https://github.com/w3c/wpub/pull/101

Getting to FPWD

Tzviya: 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: what i would like is review - everyone does a full readthrough of this. Make sure everything reflects the latest opinions. Plus there are still some sections outstanding - privacy and security for example.

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

Dave: 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: 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: I feel like it's hard to have a first public working draft without a hello world.

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

Nick: Why can't we just hello world?

Ivan: 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: 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: 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: Remind ourselves - we have to have a similar vote on two other documents - and all before end of year.

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

Tzviya: 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: What about the locator document? Tim what do you need from us?

Tim: 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: did you hear back from CFI comments?

Tim: 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: not a discusssion we need to have now...

Tzviya: Worth looking at the accessibility OM

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

Ivan: The formalities - what happens is that 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: I'll follow up with David.

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

<dauwhe> December 13, 1200Z: Deadline for publication requests before moratorium

<wolfgang> Is there any PWP document yet accessible for us?

Ivan: Not yet

<dauwhe> https://lists.w3.org/Archives/Member/chairs/2017OctDec/0026.html

Ivan: 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: OK - sounds hopeful. Hopefully Dave Wood will be able to work on something this week. I'll see if we can talk today

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

Ivan: 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: We had a holiday schedules agenda. One minute left. Any other business?
...: talk to everyone next week

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Way Bill/waybill/
Succeeded: s/obf/of/
Succeeded: s/Garth/Brady/
Succeeded: s/engien/engine:/
Succeeded: s/metadat/metadata/
Succeeded: s/seque/segue/
Succeeded: s/woo/Wood/
Succeeded: s/proceedures/procedures/
Present: ivan tzviya wolfgang Avneesh Luc rachel baldurbjarnason pkra wendyreid dauwhe dkaplan3 gpellegrino toshiakikoike JunGamo mattg lsullam George jpyle Bill_Kasdorf gamou NickRuffilo mateus evan marisa Takeshi_Kanai Chris_Maden rdeltour duga BenSchroeter david_stroup Hadrien
Regrets: clapierre daniel_weck Garth bigbluehat
Found ScribeNick: nickruffilo
Inferring Scribes: nickruffilo
Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2017Nov/0018.html
WARNING: Could not parse date.  Unknown month name "11": 2017-11-20
Format should be like "Date: 31 Jan 2004"

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)