Publishing Working Group Telco — Minutes

Date: 2017-12-11

See also the Agenda and the IRC Log

Attendees

Present: Tzviya Siegman, Wolfgang Schindler, Rachel Comerford, Nick Ruffilo, Ivan Herman, Jeff Buehler, Matt Garrish, Avneesh Singh, Benjamin Young, Luc Audrain, Peter Krautzberger, Dave Cramer, Baldur Bjarnason, Toshiaki Koike, Romain Deltour, Jun Gamou, Lillian Sullam, Mateus Teixeira, Joshua Pyle, Laurent Le Meur, Heather Flanagan, George Kerscher, Chris Maden, Deborah Kaplan, Ben Schroeter, Ric Wright, Marisa DeMeglio, Hadrien Gardeur, Reinaldo Ferraz, Brady Duga, Tim Cole

Regrets: Ivan Herman, Garth Conboy

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo

Content:

Tzviya Siegman: “Agenda got an update - are there new members on the call today?”

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

Tzviya Siegman: Minutes from last week - Any comments?

1. last week’s minutes

Resolution #1: meeting minutes approved

Tzviya Siegman: Minutes approved.

2. PWP as a FPWD

Tzviya Siegman: https://w3c.github.io/pwpub/

Tzviya Siegman: Lets take a look at the drafts for PWP. Dave Wood sent them around over the weekend.
… Comments?
… This is about looking at packaging already in WP.

Dave Cramer: 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.
… A large portion is issues and editor’s notes

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

Nick Ruffilo: 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.

Dave Cramer: There are cultural differences across different parts of the W3C where some places editors drafts are more final documents.

Ivan Herman: That’s true - it is different for different groups.

George Kerscher: From my reading - there was two options - the option for packaging where people could define their own rules and individually make up their own packaging - are we wanting to say that in a public draft that they can roll their own?

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

Tzviya Siegman: 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?

Proposed resolution: Publish the PWP as a FPWD, with the short name pwpub, expected publishing date 4th of January (Ivan Herman)

Deborah Kaplan: +1

Ivan Herman: +1

Chris Maden: +1

Jeff Buehler: +1

Wolfgang Schindler: +1

Luc Audrain: +1

Benjamin Young: +1

Joshua Pyle: +1

Mateus Teixeira: +1

Rachel Comerford: +1

Lillian Sullam: +1

Tzviya Siegman: +1

Ric Wright: +1

Heather Flanagan: +1

Nick Ruffilo: +1

Matt Garrish: +1

Marisa DeMeglio: +1

Dave Cramer: 0

Laurent Le Meur: 0

Baldur Bjarnason: 0

Peter Krautzberger: 0

George Kerscher: +1

Ben Schroeter: +1

Hadrien Gardeur: 0

Romain Deltour: 0

Laurent Le Meur: 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.
… Just keep it on the side until there is more meat to put inside.

Ivan Herman: The biggest meat would be the packaging format itself… And we know that in 1 month nothing will change.

Laurent Le Meur: maybe you are right…

Brady Duga: +1

Ivan Herman: We’re dependent on external movement - which is the biggest challenge.

Laurent Le Meur: 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.

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

Tzviya Siegman: It would be good to specifically state we are awaiting information from the packaging

Peter Krautzberger: Since I don’t have a working microphone: I don’t understand it well enough to make an informed decision; thus neutral.

Nick Ruffilo: What about an intro that provided reading context - into why we are publishing and what readers are expected to get

Baldur Bjarnason: 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

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

Ivan Herman: 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 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 publishing like that makes sense.

Laurent Le Meur: +1 to Ivan/Nick proposal

Rachel Comerford: +1 dkaplan3

Deborah Kaplan: 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 perfection and making it real

Ric Wright: +1

Proposed resolution: 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 (Ivan Herman)

Tzviya Siegman: +1

Deborah Kaplan: +1

Wolfgang Schindler: +1

Ivan Herman: +1

Mateus Teixeira: +1

Laurent Le Meur: +1

Joshua Pyle: +1

Nick Ruffilo: +1

Lillian Sullam: +1

Luc Audrain: +1

Baldur Bjarnason: +0 still. Doesn’t address my concern that this spec is fundamentally waiting on the packaging issue.

Jeff Buehler: +1

Heather Flanagan: +1

Chris Maden: +1

Ric Wright: +1

Benjamin Young: +1

Marisa DeMeglio: +1

Brady Duga: +1

Dave Cramer: +0

Hadrien Gardeur: +0

Peter Krautzberger: 0

Peter Krautzberger: as before, my limitation more than the spec.

Resolution #2: 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

3. Revisiting the locator FPWD

Tzviya Siegman: https://rawgit.com/w3c/publ-loc/new-things-only/index.html#

The URL above is not valid any more; the relevant branch has been merged into the main branch, and the “new-things-only” branch got deleted. The new version is now at https://w3c.github.io/publ-loc/. (Comment on the minutes by Ivan Herman, on 2017-12-12.)

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

Tim Cole: 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. So we wanted to rely on the references instead. There were some last minute changes to the introductions.

Ivan Herman: 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 inherited - I took them out. The document now essentially contains the parts that are normative. It is much clearer. As a 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 upon. It’s not our goal, and per charter - we are not allow to go back and change an existing recommendation.

Tim Cole: 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.

Ivan Herman: 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 version here, and we use that as the FPWD - then we can have a much more concentrated discussion.

Tzviya Siegman: I envision this becoming a bigger discussion - about something expanding multiple DOMs is one of the biggest discussion we will have.

Ivan Herman: the only point we have is that we’re taking out things that are unnecessary to have.

Benjamin Young: Locators is always confused to me - I know the locators term is probably inherited 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 annotationy

Tim Cole: I think it had to do with locating resources

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

Benjamin Young: +1 to ivan

Wolfgang Schindler: 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 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.

Ivan Herman: 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 harm than good. At some point in time, we would have some accompanying document - best practice or something - which we will clearly have to have. In that case, at that place - when we are technically done - we’ll have to do a separate note that describes that, or add all the inherited things - but all that should be later, when we are ‘done’

Tzviya Siegman: What do newer members things about this?

Benjamin Young: 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 doesn’t come with implicit actions.

Wolfgang Schindler: I see locators as a much broader concept than “web annotation”, e.g. think of cross-references

Tzviya Siegman: In my life as a spec writer - we do a lot to avoid duplication. I really want to just point - and we can say ‘if you need the addendum, stay here.

Deborah Kaplan: +1 Tzviya: Hyperlinks++

Baldur Bjarnason: 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 again. 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 don’t know what the package looks like. The second - anything that spans 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 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…
… 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.
… 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.

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

Baldur Bjarnason: The fragment identifier is meaningless outside of packaged publications.

Tzviya Siegman: 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?

Jeff Buehler: 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.

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

Tzviya Siegman: Maybe i’ve heard too much about web-annotations, so i’m more about using the name web-annotations in it.

Nick Ruffilo: What about ‘Extending web-annotations in Web Publications’

Ivan Herman: We have all the arguments around it, but not sure we have an agreement…

Tzviya Siegman: ‘Lets circle back to the name. Do we agree on publishing the shortened version?

Proposed resolution: Use the short format (https://rawgit.com/w3c/publ-loc/new-things-only/index.html#) as an alternative to the FPWD document for Locators (Ivan Herman)

Benjamin Young: +1

Tzviya Siegman: +1

Mateus Teixeira: +1

Jeff Buehler: +1

Ivan Herman: +1

Lillian Sullam: +1

Nick Ruffilo: +1

Matt Garrish: +1

Baldur Bjarnason: +1 shortened version is less harmful than the longer one.

Luc Audrain: +1

Wolfgang Schindler: 0

Joshua Pyle: +1

Dave Cramer: +1 (avoiding duplication is good)

Chris Maden: +1

Romain Deltour: +1

Deborah Kaplan: +1

Ric Wright: +1

Wolfgang Schindler: The reasons I gave earlier - I prefer the full version

Rachel Comerford: 0 (no objection - I don’t understand the elements of the arguments or the alternatives so can’t weigh in)

Wolfgang Schindler: It would be better to put more pointers to the existing annotations spec. If we make things more explicit, as to the use, i think we could use that information in the document

Resolution #3: Use the short format (https://rawgit.com/w3c/publ-loc/new-things-only/index.html#) as an alternative to the FPWD document for Locators

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

Joshua Pyle: +1 to Nick

Joshua Pyle: Indeed, the title is very important.

Nick Ruffilo: I feel it is important to at least discuss ‘locator’ vs web-annotation in the title.

Jeff Buehler: I agree - once a term is out, we can’t get it back. If we try to change it later, it will be confusing.

Tim Cole: Can I suggest that - by thursday, people submit names, and we vote next week?

Tzviya Siegman: That should be OK. Ivan?

Ivan Herman: I am considering the practicalities of changing things. Thursday should be the LAST day for submission…

Tzviya Siegman: Let’s say Wednesday - the prize for winning is the knowledge of contributing.

Tzviya Siegman: 280 character limit

Tzviya Siegman: We will resolve Monday. Any other business?

Mateus Teixeira: Thanks!

4. Resolutions