See also: IRC log
<tzviya> http://www.w3.org/2015/08/03-dpub-minutes.html
Tzviya: new member this week, Leonard from Adobe, will introduce himself when he joins
Nick: Karen had to send regrets
… we are slightly behind or original schedule, but expect to get caught up within the next two weeks. We have made connections with publishing media outlutes: publishers weekly, DBW and publishing perspectives
… on a high level, publishing perspectives is getting broad topics and potentially internationally relevant stuff, DBW will be getting presentations and we will be tapping them to do speaking arrangements, publishers weekly are getting think pieces
… turning a Jeff Jaffe's presentation on publishing on the web into prose, this will be a feature
… they want two or three pieces from us: 1) what is W3C, how is it related to IDPF 2) W3C membership importance for business users, 3) W3C membership importance for technical users
<pbelfanti> Business users in general or in context of publishing?
… the news outlets are very excited
Tzviya: would you remind us about the timeline?
Nick: new timeline’s same as original
<pbelfanti> We should leverage BISG as well for webinars, etc.
… by august first, solidify complete topic schedule, 1) explain W3C, 2) explain differences and joint goal with IDPF, 3)explain to business users technical users and existing users what the value of participation is.
… hope to run first webinar by september 1st, lineup not solidified yet
Ivan: who would be involved, what do you expect from us?
Nick: at this moment trying to keep participation to a minimum because its easier, most writing will be Karen and I, we will put it out for comments
… would want help when writing articles on new specs that we are working on
Bill_Kasdorf: wanted to reinforce the concept of Nick doing the writing
Nick: anything I write for external
consumption is not a formal W3C document
... after Jeff article we plan a news piece, the next big thing we’re
working on is the presentation run through DBW, meant to be the intro to
W3C
… we have a lineup of Pierre Danet and hopefully Bill McCoy
Ivan: one practical thing we have to be careful about: I expect lots of difficult scheduling to happen for each of these steps, but it is also true for people on this group, we should be careful that schedules and deadline not interfere with this groups schedule
Nick: the outreach committee is completely reactive, if we publish something we will go to the appropriate outlet and ask if they can post it
… so I would never say lets hold off, my schedule is conceptual
… we are not PR, we are not trying to latch on to trends
Nick: we have a very good relationship with the news publishers
Tzviya: at 12:30 EST
<NickRuffilo> scribenick: NickRuffilo
Tzviya: "What is the objective of the ARIA
taskforce meeting? We have been asked by the ARIA taskforce of the use
and support for described-at. Our taskforce put together a document
because 'we need this because X, Y, Z' with tons of examples. In advance
of this meeting - there was a response saying: 'those can be
accomplished by Alpha, Beta, Gamma..."
...: "What I need is a list of requirements that publishing needs - not
necessarily described-at, but things that include lists, links, or any
number of things. This can be accomplished by described-at but also
other things. This isn't necessarily going to be accomplished at the
meeting, but it will be discussed. If you're of the technical bent, read
the response from apple's formal objecting and the W3C response."
Ivan: "The formal objection was not on described-at"
<tzviya> objection https://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html
<tzviya> response: https://lists.w3.org/Archives/Public/public-html-admin/2014Oct/0099.html
Tzviya: "Links above..."
Ivan: "There was a formal exception on a CSS attribute that was long-desc. That was the subject of the formal objection. That has been formally overruled by the director of the W3C. The links were provided was almost 2 years ago. We do not have a formal objection on described-at however described-at can be thought of JUST like long-desc but it can be on any element (unlike long-desc which is image-only). Given this group's list of explanations, apple pointed to the objection, but didn't say they would object necessarily."
...: "Problem is that they claim there are other
existing means in HTML to provide the same set of functionality (or
richer functionality) elsewhere in HTML. They want to limit
attributes/elements when one set can handle the goal. The main one they
refer to is the element that was discussed 2 years ago in HTML but did
NOT make it to HTML 5.0 but it is in 5.1 -> the details element. It
can be added as a sub-element to anything, and in that details element
you can add additional details on the specific thing. The user-agent by
default does NOT display that element. By default it's meant to be in
the background. That is what Apple prefers. The biggest pros and cons is
that long-desc and described-at is here - we can use it now, whereas
details is not yet supported - so we're not sure how to utilize it."
...: "Markus - was that at least correct?"
Markus: "Yes."
Tzviya: "One thing we'll be involved in is
looking at the features that will exist - such as web annotations - can
support this functionality."
...: "It's something that will be on the agenda in the future"
Ivan: "These kinds of formal objections are very touchy - very legalize in text, and require lots of care - so we should never think of writing an article."
Tzviya: "If you wish to join the meeting, contact me for information"
Leonard: "I'm the PDF Architect for Adobe Systems, but I chair an org inside Adobe - technical council of file formats. I do lots of co-ordination of the file-formats that Adobe is involved in. That's why I'm here today. I have a long background and history in this area. I've been working with PDF and Document formats for 20 years."
Tzviya: "Leonard - you made some comments on the Prioritization. Can you comment further?"
<tzviya> https://www.w3.org/dpub/IG/wiki/Requirements_for_Web_Publication_and_Packaging
Leonard: "Key issue that I feel strong about - what exactly the group is trying to accomplish with respect to packaging and delivery of Open Web Paltform content in a non-online matter. Ivan's document (the last version that got published). Coming from a software background - i love having actual user requirements, use cases. It was very well laid out. A name where technology was already chosen. 'I have a hammer, so everything is a nail.' I don't see any sort of detailed technical analysis that shows a comparison or GAP analaysis for the package technologies that are around. I'm not convinced that epub is the right solution for the packaging requirements.'
...: "What i'm asking is - can we back off from technology choices - until we do a check on all the available options. What features are/aren't available. using that information to make a decision. Maybe there is something else out there that solves the harder issues. I haven't done the evaluation eithers. "
Ivan: "The epub + web document - is not yet an official document of the interest group - it has had lots of input, but we're working on a re-chartering of this group. That new charter refers to that document as being the guiding document for the work. For all goods and purposes, you can regard it as being part of this group's work. For the other thing, I think there is one issue that we should be very careful about - "
...: "Epub 3 today is out there and has a business usage, it has been a long road to get it accepted by publishers but it now works. We don't want to get into the situation where we get rid of it and try to push something new. We don't want to do something that has no chance for an uptake. We start from epub (3 or 3.1) and if we go towards epub+web - yes there will be points here and there where we may not be backwards compatible... If we move to the web, the role of XML within epub may change, but underlying the work, there is a need to minimize the changes where it is really necessary, otherwise the standards are a paper exercise"
...: "I don't know if markus or paul or people from the publishing side have a different perspective."
Leonard: "If backwards compatibility were 100%, then I agree. Then i would support that. 'In order to address technical requirements you have to break backwards compatibility with epub' Because you're breaking backwards compatibility, then there is no compatibility. If they aren't going to work in the new world - then they need to be open in the new world."
Tzviya: "Not sure anyone is disagreeing. If you read epub+web, we always say we don't love the name. if you take the word "epub" out of the title, I think you're complaint will go away."
Ivan: "if you look at the structure of epub. The major stuff that is there, and the workflows that get people to publish. And the workflows that publishers are using - and the administrative layer. The content itself. The usage of HTML5, CSS, etc. That has to be backwards compatible."
Leonard: "So epub X is not a file that can be consumed or produced by existing tools. If all the tools break - small or large - why not look for a tool chain change that benefits them?"
Paul: "I think that - as Ivan just stated - at the end of the day - is that epub 3 is a packaging spec for open-web standards. I don't think we should assume too much right now. It has to be backwards compatible and practical. Even though epub 3 is a standard today - one of the big issues is that there is a lack of support right now for all the epub 3 features to allow us to support the types of content we want to publish."
Bill: "I am just pointing out that there are 2 orgs. One is W3C. Other is IDPF. IDPF is epub. W3C is the standards upon which epub is built on."
Tzviya: "epub is not something we talk about all too often, but we talk about addressing standards that can support what we can called "epub-web" but will likely have a name-change soon"