Digital Publishing Interest Group Teleconference

<mgylling> http://www.w3.org/2015/11/09-DPUB-minutes.html

Markus: "Minutes from last week? Comments or objections, voice them now."

...: "Approved. Next up. New agenda item. Next week is 'Thanksgiving' in the US. Should we have a meeting?"

Call Next Week? (US Thanksgiving)

<clapierre1> -1

<dauwhe> +1
<jeff_xu> +1

<clapierre1> +1 changed my mind :) forgot I will be here on monday :)
...: "Ok - meeting next week!"

Reminder: volunteers needed for CSS examples

...: "Don't know how many were here last week - but we're repeating the message. We are trying to kick off a new CSS group collecting detailed elaborations on CSS topics."

<jeff_xu> count me in
...: "We need bitmaps for explanations of layouts."

Dave: "Such as complex table layouts, with decimals, and different information in different rows."

Markus: "We said we'd start on table alignment. But are there are layout topics that concern you more, you can work on that as well."

Markus: "There is no end date, so it's an endless pit of potential work. But we need to be careful to finish one item at a time. Such as table decimal alignment."

Nick: "I want to help out, but cannot right now."

Markus: "If you have people in your organization who would be interested in working on this, let us know."

Paul: "Pearson should be able to provide some samples."

Markus: "Is there a contact person?"

Paul: "I will reach out and follow up."

Dave: "I'm happy as pearson is the motherload of such tables."

CFC for DPUB AAM

<mgylling> https://rawgit.com/w3c/aria/dc8a9400ccd15b67e6660d48279aa5cc09cc527e/dpub-aam/dpub-aam.html

Markus: "CFC/DPUB/AAM. Consensus to go ahead with 2nd working draft of the epub ARIA roles. That's moving along. ARIA group has been made aware. They're doing their own stuff now. It'll soon be live on w3.org. This doc has a companion which is the DPUB AAM. Which has the accessibility module.
...: "This is a map of how the various roles should map to different platforms. The linked document is the last version of it. It has been authored by Rich Shortfinger of IBM. It wasn't available publicly before, what we're hoping to do is publish it in a first public working draft state - next to the main role document."
... "Some of you have followed it's development. Some of you have not. What we need to do, as requested from the ARIA group, is to make a call for concensus and moving ahead with the first public working draft of this. My question to all is : 'if - perhaps ivan - should we do an email CFC or a vote here?'"

Ivan: "Formally speaking we are free to choose what we feel is OK - as it is not published by this interest group. It's published from the ARIA working group. If we record a resolution on this call, that's fine."

<ivan> +1

Markus: "Please +1 or -1 or 0 if abstain."

<mgylling> +1

+1

<dauwhe> +1. Publish early and often

<pkra> why does it say SVG in many places?

<laudrain> +0

<pkra> +q

<Bill_Kasdorf> +1

Charles: "We decided instead of DPUB- it's now 'DOC-'? Was there consesus on that?"

Markus: "Yes."

<clapierre1> +1

Peter: "There are some typos. There's an SVG-AAM... Can we please typo/copy-paste check."

<pkra> +1 anyway

Markus: "I'll take the action item to send those copy/paste issues to Rich."

<pbelfanti> +1

Markus: "Any other questions or comments?"
... "OK - the vote is passed - consensus on CFC for DPUB AAM

<jeff_xu> thnx

Resolution: Vote passed for publishing working draft of CFC for DPUB AAM upon change of typos/copy-paste issues

PWP

<mgylling> http://www.w3.org/TR/2015/WD-pwp-20151015/

Markus: "Ivan, in order to get people on the same page, can you do a brief update on the changes to the document over the last month?"

<ivan> https://rawgit.com/w3c/dpub-pwp/post-2015-tpac/index.html

Ivan: "The version you put was the officially published one. The one I just posted is the GIT unpublished branch."
...: "What I did was look at the discussion from TPAC and bring back the results there. there are some minor points that made. There were some issues noted with service workers and issues accessing local files - which may or may not be a problem later, but it needed to be recorded later."
... "another thing is that it's pretty clear that the manifest is something we'll have to deal with for metadata or identifier, although that was already part of the document. I reinforced that a bit. It's really made for web applications, but at least we can base what we're doing on it."

<ivan> http://w3c.github.io/dpub/f2f-2015-identifiers/index.html : Ivan's slides for Sapporo in identifiers
...: "Who those who were not in Sapporo, we had a discussion on identifiers. Let me put the pointers in chat."

<ivan> http://www.w3.org/2015/10/29-dpub-minutes.html#item02 : discussion minutes
...: "The discussion minutes are there - so I tried to extract the most important parts. The most important part - as we go a long way in describing all the issues, the question is 'what is the URI of Shakespeare's hamlet, VS my personal copy of Hamlet. As the discussion goes, it's something we have to simply keep away from once and for all."
... "There were some similar issues with the semantic web work that caused issues."

...: "We would need 2 identifiers in FTWP - A generic stable ID - and ISBN, DOI, etc. It has to be stable and that's all. Separately, we need a URL - an HTTP URI - and these 2 should go hand in hand. If I make a copy for my own usage..."

<pkra> yep

Ivan: "At some point in time we can add metadata. I put the essentials of that in the document."

Bill: "Am I right that you have 1 and only one URL and then multiple URN?"

Ivan: "There is a URN that identifies the document, and a URL that identifies it on the web. They can both be the same, but there are two concepts."

Bill: "Can the spec allow more than one URN to associate with a document? Publishers may need that..."

Ivan: "Sure, there could be more, but lets flag it for an issue as I don't have an answer for that now."

Markus: "The URL is required, but it could be 'only' that. That's ok, correct?"

Ivan: "The Identifier and the URL can be distinct. "

ivan: "If a publication consists of many documents, is there a canonical way of accessing that. Because it's on the web, each of those documents may have their own URL. Some are on my domain, and some others... "

Markus: "In terms of referencing resources within the publication - we have the main URL - which serves as the ID of the whole thing. Then we want to reference individual entities that live within the document. In webapps it's called a "scope URL"..."

<mgylling> http://example/com/2/

<mgylling> http://example/com/2/index.html
...: "So everything is interpreted with the scope URL as the base..."
... "Is that all fine and dandy. Not sure we can verbatim copy this URL notation, but is that the simpler way to identify that."

Ivan: "This is one of the options I listed. The only problem we have is that if the document is physically on your domain, you need to understand the scope, otherwise how can you find it. The other option we discussed was to have some sort of a mapping table that is part of the manifest. So the publication always sees the resources with the scope URL as you call it. The mapping has to be done by the manifest, which means the scoping is done by the document."

Ivan: "I realize I stepped over one question - which is in the document - if I dereference the cannonical URL (make an HTTP GET) what do I get back?"
...: "There are several answers that are not exclusive. One is that what I get back is the manifest file with the right media type. Or I get back an HTML file with a link element set to the manifest file. Or I get back something and a link Header that leads to the manifest file. The manifest file will represent the document as a whole. In this approach, it has this kind of role instead. "

<Bill_Kasdorf> +1 to this
...: "This means that the only way we use fragment identifiers is for the individual resources. This allows us to use all the fragment identifiers that we've already pointed out. These were the main points that we put into this document. What I'd like is this: 1) Look at the document - the GITHUB version - and provide comments. Once I've collected the comments, lets publish a new version.

Publish often and publish a lot, keep document up to date. 2) Question: IDPF work and how this relates to that..."

Markus: "#2 is a separate agenda item."

Tim: "The issue of scope (or context) has come up in annotations in a different way. Here we keep the URL's separate. There is a special kind of selector. If we're noting an image on site A or B, we note each URL to keep track."
...: "I just want to make sure that was there in the current version."

<pkra> yes please!

Ivan: "What the annotation people do - is not use a fragment identifier directly, but make a combination of different needs. I can use an xpath selector, then another selector for the end of the range. It's not a URI, it's a structure in the JSON that is used for the annotation. What I think is doable - and what the annotation group is working on. That we should be able to express the same thing with fragments as well

Tim: "What it does it allow you to talk about two different URLs - especially when one is contained in another. Such as an image that is located in a different region that the page it's located in."
... "The idea of putting the two URLs together does seem dicey."

Markus: "Setting fragment identification aside for the moment - as it is a separate beast - I'm just thinking about PWP identity discussion from earlier. Epub 3.1 revision is ongoing - until next autumn. We hope to stop making changes to the draft. One ambition with 3.1 is a future migration from EPUB 3 into PWP. We want things to be more forward compatible with PWP. The question is: should we ask DPUB to become an advisory entity for IDPF for potnetially making identifiers in EPUB?"

Nick: "What's the downside?"

Markus: "From IDPF there is no downside, they need it. From DPUB perspective, the downside is that we're not entirely sure that the PWP outline is mature. We may end up doing changes in epub that aren't what PWP uses. "
...: "Focusing on this in a practical implementation will help PWP as well. So that is a good thing for PWP."

Bill: "First, I'm on both groups and support this idea. What does it constitute exactly?"

Markus: "IDPF would reach out to DPUB and say: 'Help me DPUB-IG, you're my only hope.'"
...: "Then we'd provide our input. We'd be a sub-group working on one particular issue."

Bill: "The issue is timing. DPUB wouldn't be able to provide anything mature now, but being on both sides benefits both groups."

Markus: "The burning question - in the scope of 12 months, could something become mature enough to put it in Epub 3.1?"

Bill: "By formalizing the relationship, it would make it more likely to succeed."

Markus: "We're committing to try."

Markus: "Due to technical issues, I think we'll end now."
...: "The IDPF and DPUB chairs will do some discussion and come back next week with a clearer picture."
... "I've noted support for the idea, and we'll investigate further. We'll have a firm approach for vetting next week."