W3C

- DRAFT -

PWG Weekly Telco

08 Jul 2019

Attendees

Present
tzviya, wendyreid, dauwhe, George, rkwright, JunGamo, franco, BenSchroeter, gpellegrino, Garth, romain, Avneesh, duga, mgarrish, josh, laurent, dkaplan3, bigbluehat
Regrets
Ivan_Herman, Tim_Cole, Luc_Audrain, Rachel_Comerford
Chair
wendyreid
Scribe
NickRuffilo

Contents


<wendyreid> present_

Scribe+ NickRuffilo

<scribe> ScribeNick: NickRuffilo

<wendyreid> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-07-01-pwg

Wendy: Minutes from last week - any comments, questions, or suggestions?
...: Minutes approved
... The first agenda item - regarding the UCR document. We spent some time clearing up most of the issues, it is time to talk again. We wanted to raise it again.

Tzviya: Even though we're changing directions, it will still live on...

Wendy: We should still keep things up to date and accurate

<franco> A Web Publication should be able to express the access control and write protections of the publication.

Franco: We have one outstanding issue - it's a pull request - rephrasing the language for issue #213 - Essentially the previous requirement was (pasted into IRC)

<franco> A Web Publication should allow for the application of access control and write protections of the publication.

Franco: It has been updated to (pasted into IRC)

<wendyreid> scribe+

<wendyreid> NickRuffilo: Minor, "should allow for access control"? Feels a bit awkward but might be misreading

<wendyreid> ... I was reading application as Web app not "apply this to", should we review this?

"should allow for application of access control..."

<franco> A Web Publication should allow for application of access control and write protections of the publication.

<George> +1

<tzviya> +1

<laurent_> +1

<garth> +1

Wendy: Everyone OK with merging that revision and accepting?

<geoffjukes> +1

+1

<josh> +1

<gpellegrino> +1

<BenSchroeter> +1

<franco> +1

RESOLUTION: Merge PR #225 of the UCR document.

Wendy: Pull request 225...

<wendyreid> Proposal: Publish the latest draft of the UCR Document

<wendyreid> +1

<josh> +1

<dkaplan3> +1

<franco> +1

<tzviya> +1

Wendy: The proposal is to publish the latest draft because it hasn't been done in a month or so. This is a vote +1s in chat

+1

<garth> +1

<geoffjukes> +1

<duga> +1

<romain> +1

Tzviya: Ralph said he's be able to work on this to publish it in Ivan's absense.

<JunGamo> +1

RESOLUTION: Publish the latest draft of the UCR document.

Wendy: Resolved. We will contact Ralph and get that ball rolling. The next agenda item is to have a quick update on... We had a discussion last week with the business group about the direction we discussed - audiobook will move forward...
... the one thing we were thinking is separating out the web publication manifest as the contents of the note and publish that as a note for hopefully future implementation. Then take what we need to take out of web publications and put it into audiobooks as a formal specification for that format. What we are also going to be doing with the business group is have a meeting soon...

<George> +1

Wendy: to talk about the future of publishing activity - what we're going to do with epub and what might web publications might turn into. Still up in the air.

Tzviya: I want to add to that. One thing we want to leave open and wasn't clear - is that future profiles (even though i don't like the word) we are still leaving the opportunity to have new profiles...
... we have heard interest within scholarly and manga to build off the work we did in audiobooks. Assuming the manifest stays in place, there's still room to work off that. We can work with things like canonical ID which we haven't really determined how it will work...
... so we're leaving it open in the future. We're preventing cutting it off directly and preventing future work from being done. The meeting wendy is refering to is mostly with the steering committee that exists because we realize that...
... there's alot of discussion around epub that we haven't discussed yet. There is eagerness in some groups to move forward, but we need to figure out what happens next.

George: I want to clarify that when we pull out from the manifest what we need for audio publications, the audio publications are intended to become a rec. The note which may change - be picked up as rec later in the future - does that conflict with what we pulled out for audiobook?
... I'm trying to understand that relationship between the audiobook rec and what we might make in the future?

Wendy: It shouldn't conflict - we're trying not to create any conflict and I think we've done a good job of it, but we're trying not to conflict...

Dave: Do we need to make this decision before the steering committee meets and talks about the big picture? It feels unsettled if we want to split the web publication spec into just a manifest that can be used by audiobooks or other profiles...
... it sounds like we're still discussing or are we further along than I realized?

Avneesh: I think one of the questions is - if we have audiobooks specification based on something from web publications - can it go to rec track when it's based on a WG note?
... If it cannot, then it would be better to come up with a plan to pull out things from WP on which audiobook is based... That's one thing to think about. I'm concerned about Dave's question...
... What is the depth of the decision we are making today? Moving ahead on the spec, or moving ahead with the PR?

Wendy; I'll answer one thing - YES, the audiobook can be based on a note. I believe that was answered last week by Ralph.

<Zakim> tzviya, you wanted to answer dauwhe

Tzviya: I don't think we're making a decision today - it's the beginning of a discussion. The business group continued the discussion and it will continue. We are not moving forward with work - we're not moving forward yet, just continuing the discussion...
... I agree with dave that it's not good to move forward until the steering committee meets. We do want your input. This is your opportunity. Tim Cole did send me an email with his opinions, so you can do it that way as well...

Wendy: We want your input. I wasn't proposing this as a decision today - it's big and a lot of work.

Tzviya: Our takeaway last week was that there was some misunderstanding - so if you have questions, please tell us.

<Avneesh> It was CR not PR

Laurent: I don't think that we can base the audiobook rec on web publications notes - I don't think we need it to work. The discussion was to extract from the web publication what works and include it in the spec as a rec...
... I see a problem with that, as i don't see what we could remove from the web publication spec as it is to fit into the audiobook spec. If there is something missing from the web publication spec that could make it a rec, I don't see how it would be able to make it as a rec for audiobooks.
... maybe it's just the distributed resources, but as you spoke about canonical ID - is it mandatory? Optional? It's the same for audiobooks. I agree that web publications as it is - it's difficult to make it a rec becuase it's generic and some metadata is missing for real life use...
... but still, we will have difficulties and have to work hard to export from the web publication some subset that is OK for audiobooks.

Wendy: Some of the work for audiobooks will involve closing off the references. Almost every section is a reference to web publications spec, so we'd have to close that loop a bit. There are some discussions about processing and what we take from WP to make it work.
... I dont' think the problem is that WP couldn't be a rec track doc. We just need to take from it what audiobooks would need to be full.

Tzviya: My thinking was that - and Ivan's thinking as well - part 2 of the current web publications document is mostly about the lifecycle and processing model - that would be the part that we would freeze.
... that would be different for different types of publications. We wouldn't talk about conformance of a note - or primary entry page in a note... That issue would live within the audiobook rec.
... processing the manifest would not be relevant in the note - we don't deal with processing in a note. The processing model needs to be defined for audiobooks, but not the WP note...

Laurent: I think this way - by reorganizing the documents, we still need to have documents split in some parts - and maybe we will be able to do it. We could export the processing model and put it in the audiobook, that could make it work.

Tzviya: We have a theoretical concept of an identifier, but we didn't specify. Relative URLs, etc. Packaging is external to all of these, and it was proposed to be a note in itself - maybe we want something specific for audiobooks, but we haven't discussed or resolved.

Laurent: I don't htink we should make anything specific for audiobooks when it comes to packaging, as it should be generic that can be used and shared between recommendations later...

Tzviya: And that's something we can discuss later - we don't have a resolution...

<Avneesh> Not right now. The devil is in details.

Wendy: The next agenda item: Ivan mentioned that we are not using the Echidna (sp) ... he would like us to add it to our process. Does anyone have any concerns?

<tzviya> proposal: use echidna automatic publishing for audiobooks

<wendyreid> s/Akidna/Echidna/

<wendyreid> NickRuffilo: Is there a downside?

Dave: CSS uses it, it works, go for it

Tzviya: We use it for web publications - it's the process

Matt: It's administrative thing, we have to agree, but i don't see why we shouldn't. It means we automate it and it goes to a branch, then goes into the ether - i would say it's 'lets do it'

<wendyreid> Proposal: Use echidna process for publishing audiobooks specification (like WP)

+1

<tzviya> +1

<romain> +1

<geoffjukes> +1

<duga> +1

<mgarrish> +1

<dkaplan3> +1

<bigbluehat> +1

<josh> +1

<BenSchroeter> +1

<gpellegrino> +1

RESOLUTION: Use echidna process for publishing audiobooks specification (like WP)

<wendyreid> https://github.com/w3c/wpub/labels/topic%3Aaudio

Wendy: I want to point to the open Audio issues. We have 5 open issues, one of which is TAG review. The one with the most discussion to have is about the REL attributes for extra resources - please think about that.
... It's logged against audiobooks, but we did get our first piece of feedback from colibrio when it comes to zip compression for storing media files. That is probably going to be pushed to packaging...
... if you know anyone who wants to give feedback on audiobooks, have them log issues against the github - but I'm sure there are more people with feelings and comments

<rkwright> Echidna is a spiny anteater, no? Can somebody point me to the spec or explanation of what the echidna process is?

Wendy: next week we will discuss in more depth.
... the last thing for today is about the ping survey for audiobooks - just like for WP - we have to do a privacy, security (privacy interest group) someone - we're looking for a volunteer for filling out the survery for audiobooks... Anyone?

<tzviya> https://www.w3.org/TR/security-privacy-questionnaire/

Tzviya: they will work with you, and you'll learn many new things about privacy and security...

Brady: I think I volunteered (or was voluntold...) for WP - but is that still a thing? Will we need to do that?

Tzviya: I think we're not going to do the WP survey just yet because it doesn't make sense. if you're offering to do it for audiobooks I think it's good idea...

Brady: My recommendation is to move the 3 volunteers for WP and move them to Audiobooks if they would agree to be shifted as they already volunteered
... I will take the action item of finding out who the people were. If I can convince the other 2 to do the work, i'll join in as well.

Tzviya: I don't think it's that time consuming, and we have committment from the PING people to help you out..;.

Wendy: Next week we'll talk about audiobooks. Agenda will be sent on time.
... enjoy some extra time - talk next week! Have a good afternoon!

Summary of Action Items

Summary of Resolutions

  1. Merge PR #225 of the UCR document.
  2. Publish the latest draft of the UCR document.
  3. Use echidna process for publishing audiobooks specification (like WP)
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/07/08 16:39:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/Akidna/Echidna/
FAILED: s/Akidna/Echidna/
Present: tzviya wendyreid dauwhe George rkwright JunGamo franco BenSchroeter gpellegrino Garth romain Avneesh duga mgarrish josh laurent dkaplan3 bigbluehat
Regrets: Ivan_Herman Tim_Cole Luc_Audrain Rachel_Comerford
Found ScribeNick: NickRuffilo
Inferring Scribes: NickRuffilo

WARNING: No "Topic:" lines found.

WARNING: Could not parse date.  Unknown month name "07": 2019-07-8
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: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


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.)


[End of scribe.perl diagnostic output]