Digital Publishing Interest Group, F2F Second day

<ivan> trackbot, start telcon

<ivan> sccribenick: laudrain

<laudrain> Tzviya : presentation round table

<laudrain> Tzviya : meeting with POE

<laudrain> POE

<ivan> scribenick: laudrain

POE presentation

by Renato Ianella

Slides (in PDF) are available online

History of ODRL

Context of Rights Expression Languages (REL)

W3C ODRL Community Group

Formaly W3C WG in 2016

POE WG Scope

Deliverables, end of 2017

POE UCR Note and ODRL Information model

<glazou> s/azulojes/azulejos

ODRL Vocabulary and Expression

These are the 3 documents published today

Potential new NOTES

<tzviya> existing POE-UCR: https://www.w3.org/TR/poe-ucr/

<scribe> New use cases

ODRL Information Model

ODRL Vocabulary

ODRL Expression

ODRL Profiles

RightsML Implementations

Flatirons DAM

RightsPro - Media store

OMA Profile

Monegraph - ODRL on the BlockChain

TPAC Agenda for POE WG

https://www.w3.org/2016/poe/wiki/Meetings:TPAC2016

Questions?

Tzviya: some people may not be familiar with ODRL, can you describe for trade or text book publisher?

Renato: the creator is involved and need a simple way to express his/her rights

ODRL is a technical language, big challenge

You need to know if you can republish, take less risk

the language is the system

in music companies want to use the BC as a system to store the rights

Ivan: publishers put metadata somewhere with some expression of rights

is ti a richer expression than ONIX?

would it be included in ONIX?

<Zakim> rick, you wanted to ask a question

BillK: BISG use cases in POE UCR

Quick examples for Publishing industry: BISG created a vocabulary for book rights

Magazine industry did something similar

they concluded the level of granularity too complicated

they made it sure so that it maos to ODRL

focus of books industry is to express at a very granular level

Ivan: less complex through profiles, but different islands?

Can we help the ODRL WG to achieve a global view?

BillK: industries have to do the mappings

Ivan: does EDItEUR needs help?

Leonard: RDF/XML is compatible with XMP?

Renato: it is XML, probably

Leonard: XMP is a metadata asset format, ODRL embedded in the asset?

Ivan: RDF graph can be mapped to XMP

vocabulary defined and then serialized

David_Wood IPTC easily embedded in XMP

Tziya: action items?

BiilK: In a particular sector, there are metadata expressed in specific

ODRL is much richer

mappings should be done by each industry

<david_wood> See http://www.slideshare.net/smyles/iptc-rights-working-party-summer-2016

Renato: generic solution, and then industry use profiles

BillK: with the vocabulary they already use

Starting from BISG use cases, and then talk to EDItEUR

<scribe> ACTION: item to BillK and Luc to contact Graham Bell [recorded in http://www.w3.org/2016/09/20-dpub-minutes.html#action01]

<trackbot> Error finding 'item'. You can review and register nicknames at <http://www.w3.org/dpub/IG/track/users>.

<scribe> ACTION: Tzviya to touch journal publishers on POE [recorded in http://www.w3.org/2016/09/20-dpub-minutes.html#action02]

<trackbot> Created ACTION-63 - Touch journal publishers on poe [on Tzviya Siegman - due 2016-09-27].

<ivan> scribenick: pkra

Outreach materials for Frankfurt Bookfair

Karen: we can be at Frankfurt Bookfair
... drop by with your W3C hat!
... we can talk about the collaboration.
... looking for a simple message for flyer (etc) for reaching out in Frankfurt
... [flyer example on projector]
... "Create New Business Opportunities for Publishing on the web"
... "Bring the unique requirements of publishers to the OWP"
... [backside of flyer example with info on Portable Web Publications]
... is it too soon to introduce PWP at Bookfair?

leonard: is this just for Frankfurt?

Karen: yes but might be useful afterwards.

Rick: Frankfurt is about getting into a market and getting rights.
... not the right crowd to introduce new format

George: for Frankfurt: epub is what you can do today. What DPUB is doing the direction forward.
... should provide more avenues to market their products.

tzviya: call for volunteers who will be at Frankfurt

Garth: Frankfurt is not a very technical venue. PWP will easily scare people.

Leslie Frankfurt has presidents, publishers etc. They might have epub in their head, if you say "taking epub further", that should be enough.

Bill: And tell them W3C is very much interested in the publishing problems.

tzviya: next item: PWP Use case document

Garth: IDPF board meeting yesterday and we are continuing the process towards a possible collaboration.

PWP-UCR Fundamentals

Ivan: on https://github.com/w3c/dpub-pwp-ucr/wiki/Jotting-down-ideas-for-the-discussions-@-TPAC-F2F-on-%3F%3F-Web-Publications
... discussion items that came up yesterday across the day
... Issue: a clear separation of certain parts, not just ucr but also the work of the community.
... a) web publication. it seems other communities are looking into similar things (e.g., games)

Ivan: identifier should be a URL, not excluding other identifiers (ISBN, DOI etc)
... since a URL, we have eventually say what a server returns.
... URL should return "all the information"
... issues that came up:
... offline/oline
... constituent resources
... constituent resources
... TOC / "rendition information" (epub terminology)
... incl. several renditions (reading order, audio/sync etc)
... additional metadata needs to be attachable
... somewhat orthogonal: the processing model for a "WP processor"
... not clear if extension or add-on.
... hoping in the long run, the browsers do it all

Garth: the world of reading systems is 1) (separate app). How does that fit?

Ivan: I was referring to rendition in browser.

part b): "packaged" (note: not using "portable"

Ivan: there is interest in such formats
... clear: if "unpacked", then identical to WP.
... clearly: learning from existing formats
... especially security

Bill: re "packaged", you expect the web publication is agnostic to the package.

Ivan: yes.

Bill: do you mean "single file"?

Ivan: Probably yes.

Leonard: [slides will be made public]
... [slide 1] 3 things: maybe a different definition (we might agree on)
... * one or more resources in web standards formats

* organized in a uniquely identifiable grouping

Ivan: * organized in a uniquely identifiable grouping
... * can be distributed in any manner
... [slide 2] organized in unique group
... * identifier(s)
... * must be possible to obtain using identifier
... * PWP can be resource in another PWP (e.g., "collection")
... * must be possible to obtain all resources for the PWP
... [slide 3]: can be distributed
... * off the web (all resources in some container)
... * on the web: stored "online"
... * on&off the web, e.g., a) container could be online as a single unit b) container does not have all resources (some are online only)
... [slide 4] BIG question: How much do we rely on browsers doing this without additional software
... [slide 5] if we agree to the definition
... Need to define "list of all resource"
... (might not the same onweb/offweb)
... offweb needs extended security model.
... [slide 6] what we do not need to...
... specify how a "processor" moves a PWP on/offweb
... specify the file format for the container

Garth: if we look at epub today, 100% is about package and interchange
... eventually that won't be the model for PWP. But if there are more than one form of package, we do need to define it.

Ralph: "file-format compatible package", could you specify?

Leonard: something that could be stored as a single entity. E.g., attachable (email, ftp).
... but something to work through.

Bill: suggestion: why I asked "Is a WP is agnostic to the type of packaging?". I could imagine that epub is a profile of WP because publication workflows need its properties in the ecosystem.

Ivan: I think the interesting problems are Web Publication. The packaging is simpler.
... I don't want to talk about packaging without having figured out Web Publications.

<mgylling> +1

Bill: against one package b/c we have evolution of the ecosystem.

Tzivya: we've bee circling around words for too long. We need to figure out how to put stuff on the web.

<ivan> ls

Tzivya: we can put 1 HTML file on the web. How do we put 2 closely related files on the web together?

avneesh: regarding onweb/offweb, do we have a confirmation that publishers are interest in moving in this direction?

<lrosenth> my presentation: https://www.dropbox.com/s/sxcapkx0iq8jl5a/What%20is%20a%20PWP.pdf?dl=0

avneesh: what are high priority features? Can we collect them to check if we need the Web model?
... from DAISY experienced, this would be well advised.

Luc: date of publication is important. Before that, there is no publication.
... how can we pass that information down the publishing chain so vendors know this.
... related: revisions, editions etc.
... related: archiving.
... may exist in some websites, but not as important as in the publishing industry

Leonard: focus on web publication makes sense. Defining a package is relatively simple because we've done it before. But the security model is not.
... I think it will require extensions of the web's security model.

<dauwhe> pkra: even in off web use case

<dauwhe> ... do people think a web publication will not be loaded from a web server instance

<dauwhe> ... readium for android loads from a web site

<dauwhe> ivan: you can open a local file

<dauwhe> pkra: the security problems seem to come from not using the web

<dauwhe> ... 2nd q: I don't don't understand the idea of portability vs the URI... how do these fit together.

<dauwhe> ... if i move it from the origin, how does the URI work?

<ivan> scribenick: bigbluehat

boris_anthony: I'm going to ask a question about something that came up earlier
... and restrict this to books
... there is no further technology required to read the books in a physical library
... there is no one here representing the value of non-technical human bengs
... someone should represent the users in our conversation--to balance this with the publishers
... it's a fundamental principle of the web also
... I feel like I've finally gotten some clarity in the last 20 minutes around addressibility, permissions, etc.
... how do we point to the constituent parts
... that seems to be our highest priority and does not yet have a model on the Web currently

ivan: that kind of issue is something we've looked at--likely not addressed perfectly
... at a very high level, many of these questions are answered using how we do it now via URI/Ls
... we should not invent new ones unless we are really really really forced

boris_anthony: so why not use them?

ivan: we do.

boris_anthony: then I think we continue to leverage them in the space of packaging

takeshi: there are many publisher who are doing Web publishing
... for instance, news paper companies publish articles on the web
... when I read the current use cases, I couldn't find key value for those publishers
... on the other hand, I couldn't find any reason the publishers could not adapt to the Web model
... if I need offline reading, there are known ways to read offline Web content
... I would like to focus in on those particular use cases

laudrain: use cases are being used to present the broadest cases
... but I can't imagine books and such to be published as a text book

ivan: why not?

laudrain: ...because of offline, because of qality
... we don't expect to build applications when we create books
... I don't see publishing on the web to be building applications

<boris_anthony> human’s want to own things, live with them.

Markus: isn't it true that these are proprietary?

room: no there are other options: RSS, Atom, NewsML, etc.

lrosenth: there are lots of other things legal proceedings, etc.
... I agree with boris_anthony about the reader statements
... and I want to reiterate that this is not about "just" books
... we shouldn't say "offline" we should say "off the web content"
... it's the potential of the author/publisher to distribute it any way they want
... Peter to your comment about serving off local host, you still have all the same security issues.

<Zakim> MikeSmith, you wanted to comment about why you’re not going to define a new security model

lrosenth: Ivan already commented about locators...which I think will be very important to us

<boris_anthony> olivier++

MikeSmith: to follow boris_anthony's example and speak at a high level
... our concerns are around the restrictions of "the Web"
... web video was one of them
... Flash is gone now and replaced by HTML Video
... so. as a thought experiment, let's say "you can do anything with The Web"
... because you will be able to eventually
... if you read "Weaving the Web" TimBL designed the Web to contain all other systems
... the Web is evolving to consume those systems even today
... user experiences that have been taking places off the web are shifting too the Web
... I'd like everyone to use their imaginations, and things that we assume are not possible now can/will/may be possible
... I'd like also like to say we are not going to come up with a new security model
... what we have now is a feature of the Web
... the Same Origin Policy and the runtime/execution security model
... you can give up on using JavaScript and even CSS
... what you'll be talking is static HTML where you don't have to worry about security at all
... using the Web as we use it now via HTTP and even as Markos has commented even if we come up with new features, we're also probably going to be talking about TLS/HTTPS
... we are also going to have in all 4 major browsers support for ServiceWorkers
... so you can be optimistic about when it lands in all of them
... within the time frame of this group
... in the same way you can assume HTML, CSS, and JS to build on, you can also begin to assume that ServiceWorkers can be part of that foundation
... judging by the issues, I believe we can begin to focus on everything starting on the Web and distributed from it
... at the point where you're actually downloading, it can automatically pre-fetch and catch all the things
... the last thing I wanted to mention, was that in having conversations with browser vendors
... in terms of the DOM representation we need create something that's even "higher" than the DOM--a collection of documents
... a sequence of documents, perhaps
... which is quite different than typical Web.
... and someone will say that books and book like things can be graphs
... but for the typical case, it's an ordered sequence of documents
... if we have a way to represent that in the DOM, then we can begin to build that direction
... when I look at problems, I think about them programmatically
... how do I do this with JavaScript
... btw, Marcos and I did not conspire to bomb you all with this information

<glazou> tzviya: I only 48 hours-long days and it'll ready soon

MikeSmith: one of the things Marcos mentioned to me is to do full text search across a collection of documents
... another one that's been mentioned is the ability to do ToC's
... we unfortunately added these structural elements <article> etc.
... you can now no longer pull out the structure of the documents by just pulling out the h1-h6
... there is an algorithm for generating outlines
... which no one other than me in the validator has implemented yet

<glazou> wait, having an OM and having high-level manipulation APIs *is*different

MikeSmith: if you give it a body element, it pulls out the outline of it
... but we want to find out if something we should pursue
... so that we can programmatically pursue

<Zakim> olivier, you wanted to ask about "off the web"

<boris_anthony> MikeSmith ++

olivier: my comment will echo some of what MikeSmith said
... I'm mostly confused by the "off the Web" conversation
... I asked on IRC if there was a definition of that
... and there doesn't seem to be one
... my definition would be if you're using Web technology + identifiers, then you are *on* the Web

lrosenth: I'm only concerned about "offline" not "off the Web"
... when you say Web, I'm assuming yo mean the "public internet"

<boris_anthony> and now we debate “what does “web” mean?”…

lrosenth: and I want to talk about things that are not on the "public internet"

<Rebeca> Actually HTML 5.1 pulled out the h1 only recommendation: "Authors might prefer the former style for its terseness, or the latter style for its convenience in the face of heavy editing; which is best is purely an issue of preferred authoring style."

<Rebeca> Authors can be attached to h1 + section or to h1 - h6

olivier: I've heard that before, and it should not have any bearing on the specs

lrosenth: the next conversation I want to have is the security model, and I want to discuss it offline
... and my last comment is about "you will eventually be able to do something on the Web"
... it is entirely dictated by 3 specific companies interests
... and publishers want to do things that these companies do not

ivan: so 2 things that I want to follow-up on MikeSmith's comment
... I have no interest in touching the security model of the Web--I'm assuming we're working inside of it
... in many ways, the publishing companies are dealing with it already
... but I disagree with lrosenth very clearly that we cannot address it here, and should plan to work within it
... when you move the issue of multiple resources into the realm of the DOM, there are 2 things I don't really understand
... a) when we have a Web publication made of all the resources of it, they cannot all be represented in the DOM
... and those documents (CSV, etc) are not representable in the DOM
... another question is when I as a publisher product that, I do not think in a single document
... I think there's a bridge between what you, MikeSmith, describe, and an additional definition--outside of the DOM--for defining the collection of content

dauwhe: I wanted to say that when I've been thinking of this, that this collection of documents seems to lie at the heart of the problem for me
... describing them in the language of the Web seems to be the key issue

Bill_Kasdorf: what i took away from MikeSmith's comments were design principles
... design for the future, not for the past
... but then you also have to adapt to the present
... so we should design in a world where ServiceWorkers are immanent
... so that, when we have a more highly evolved DOM or DOM+ so that what we create now will work in that new/future environment

<Zakim> tzviya, you wanted to discuss POM, outline and HTML

Bill_Kasdorf: but to always design with the future in mind--as much as that is possible within the present

tzviya: about a year ago, we discussed a Packaging Object Model

glazou: I came here to talk about the POM
... in Sapporo I made a proposal for POM, which I think is crucial for epub documents of the future
... to hide the complexity of the publication from the editors, viewers, etc.
... right now, we're all reimplementing things
... and we all have to implement our own library for doing each thing
... and we end up with incompatibilities--and then we have to re-engineer to support each others content
... what if we had a publication package/manifest that allowed things to point to a "publication" who's contents may move, change, etc.
... in the DOM, we can point to certain things--even files--but it is very limited
... it is still very complex to make a stylesheet for these things
... you guys are the only ones to provide this necessary input
... but even when we make this, it won't do everything
... implementing this is not easy, you have to do it character by character

<garth> Kumbaya coming soon, I'm sure!

glazou: you then have to do this in a cross-platform/browser method--via polyfill
... just one word about the name: POM -- Publication Object Model
... after some work on my document...making something that is format agnostic is not do-able
... if you are interested and able to help me with POM, you are very welcome

garth: it's been an interested and wide ranging discussion of everyones opinions here
... I'd like to propose that--especially with MikeSmith in the room
... I'd like to find out if browser would become interested in the web publications with or without the package format we may propose
... we do have potentially an entire industry interested in EPUB
... and they may eventually transition to a completely online world
... if we take a single piece of this puzzle, the packaged Web publication, that is something that would enable what exists today to move to the Web more easily and we need to support that
... and would love the browser vendor's support
... and we should consider reformulating the use cases around the notions of offline/online conversations

<glazou> bigbluehat: nope, unfortunately

garth: that is a potential Kumbaya moment.

MikeSmith: ivan and Ralph and I are good friends, and even when we disagree on things, we're still here to solve problems
... I am here to help this group get its goals achieved and get better representation in this room from browser vendors

ivan: Markos is not here, but I would like to get him involved in this group

MikeSmith: be careful what you hope for ;)

ivan: seriously

MikeSmith: for better or worse you can count on his continued attention

tzviya: thank you

<dauwhe> scribenick: dauwhe

Towards a working group

garth: we're scheduled for two hours

<ivan> scribenick: dauwhe

garth: if we have time, we can circle back to pwp-ucr
... people in the room are familiar with EPUB (well, except for THAT person)
... Markus can talk about epub current and next

mgylling: what did we want to cover?

<tzviya> https://www.w3.org/dpub/IG/wiki/Detailed_TPAC_2016_Agenda#Toward_a_WG

mgylling: I'll give a brief status update on EPUB

garth: a bit on what we deferred from 3.1 to EPUB3+

lrosenth: what does an update on epub have to do with "towards a working group"

garth: the section after is billm talking about the merger, and the path forward

mgylling: all y'all know 'bout epub
... recent history:
... 3.1 revision was started in October 2015
... was intended to be a major revision
... there were lots of projects under the 3.1 umbrella, including BFF
... we wanted the HTML serialization, and the death of the NCX
... but we decided 3.1 would be a moderate revision which would not break compat or introduce many new features
... the herculean effort became quite moderate
... so we could pave the way for PWP to deal with the larger issues
... 3.1 was all about non-intrusiveness and backward compat
... this is an ecosystem that moves very slowly
... the web progresses via polyfills, etc. but the epub industry doesn't work that way
... the EPUB WG will have to face this problem... how do we make progress?
... we can't leave the current ecosystem behind
... Avneesh was asking this morning about what the business incentive of this work would be

Bill_Kasdorf: do you want to mention the satellite specs, like a11y and EDUPUB, distributable objects, etc

mgylling: the a11y spec which is part of 3.1 is a separate spec on purpose, so it can apply to past, present, and future versions
... Avneesh and Charles drove this effort, which we're very proud of
... this, together with new tooling, will help make content accessible
... there's epub for education, a profile of epub
... this was initiated by pearson and o'reilly
... they are still in draft form
... haven't been updated for 3.1 yet
... lots of what is in EPUB for Education is in the a11y spec, so when updated it will be shorter
... we need to have a strategy pre and post (possible) merger
... we have some other specs, including multiple renditions
... please, ignore renditions for at least the next ten or twenty years, or perhaps forever

<tzviya> +100

mgylling: if we don't end up with unscripted reading systems, the thing becomes useless
... there are a number of small things associated with edupub
... edupub and satellites need a pre- and post- strategy

garth: this is the perfect time to review 3.1, and folks here would be ideal reviewers

<tzviya> http://idpf.org/news/call-for-review-public-draft-of-epub-31

george: the multiple renditions...
... fixed vs reflowable
... and a11y
... it's easier for a camel to get through the eye of the needle than to make FXL a11y

tzviya: I can talk later about this

billmccoy: it's premature to talk about the death of FXL

garth: the next item on the agenda is idpf+w3c

billmccoy: let's do it together (to Ralph)

[bill and ralph embrace warmly]

billmccoy: as we announced in may
... we have been talking about combining
... exploration has ripened into a MOU
... the ink is not quite dry
... but soon.
... it's up this group on guiding us towards a working group
... so there will be a publishing publishing group
... like a publishing branch of w3c
... it's not just "digital" publishing, because css is used for print etc
... dauwhe will be talking about that on Thursday
... there will likely be a publishing working group
... and an epub3 community group for the maintenance of epub3
... does this group become the wg? will there be more than one wg?
... there was talk this morning about odrl
... won't be easy to figure this out
... let's not settle on a charter this minute
... epub3 maintenance will happen in w3c, but will not be a REC of w3c

Ralph: that was pretty complete
... in terms of ideas for a wg charter
... it will be this group who will advise us
... combining the core web technologies for the purposes of publishing
... which could be done in a pub wg, but there may be more
... the core web tech are distributed across many working groups
... deciding what work gets done in which groups involves magic (or at least Ivan)
... the web platform wg is working on some of these issues

Bill_Kasdorf: what about w3c restructuring

Ralph: I'll have a new title, "Technical & Architecture manager"
... Wendy will be strategy manager
... we used to have domain leads
... so now plh, wendy, and I will work on this

billmccoy: question about whether this group wants to take on the existing ecosystem
... epub maintenance will not cease
... but that might not be part of the wg charter
... but we'll still need a bigger room

lrosenth: question to bill and ralph
... which i asked in Chicago
... what about the IPR definitions
... that wasn't an issue, because epub would stay on one side with old policy

<ralph> ... new work would be new ipr policy

lrosenth: how are you resolving differences in ipr

billmccoy: it will become more clear when the MOU is public
... there will be a epub3 cg
... it would not be under w3c ipr
... revisions would be member submissions
... would be covered under the CG process
... there are devils in the details

<tzviya> dauwhe: Can CGs publish? Is it a member submission?

Ralph: they publish in a different area of the site

billmccoy: it doesn't make sense for a global spec to come out under a different license/method
... there should possibly be more models for publishing under w3c

Karen: would you be able to outline the chartering process?
... and a quick snapshot of the four types of groups

Ralph: REC track stuff is from Working Groups
... they can get input from Interest Groups
... some of what this IG has done is WGish
... more recently, we've created community groups, where any five random people can form a group
... they have an individual ipr commitment, anyone can participate, there's some infrastructure
... the idea is a low threshold for people to incubate an idea
... we envisioned them to be short-lived
... they publish reports
... some reports are specs
... that's another source of input
... for the web platform wg, they look to the web platform CG to be the only source of input
... the fourth group is the business group
... WG, IG, and CG are mostly tech-oriented
... but we want a forum for businessfolk
... business strategists
... so those people can help us to identify strategies
... eventually a wg charter gets approved by The Director after input from the membership
... something new you will see in the MOU
... there's a publishing business group
... there's a fee, unlike community groups
... we're going to have a steering committe, to advise the director, select chairs, etc

billmccoy: the MOU has been silent about the future of DPUB
... that's this group's job to figure out
... DPUB might mutate into the new WG, but there might be other paths
... but that's for y'all to figure out

Ralph: we hope all of you will be in the WG

glazou: what would be the patent commitment of EPUB3 when it enters the wg for epub4

Ralph: w3c says that cg contributions can be used in wgs

duga: what if w3c wants to use an idpf spec?

Ralph: there can be a member submission

Bill McCoy: we want to maximize reuse

scribe: but we won't directly transmit member commitments
... so member submission will be the way to transfer IP

Rick_Johnson: you talked about the short life cycle of CGs
... you didn't mention a time frame for BG

Ralph: there's no assumed life cycle for BG
... there are very few BGs, we don't have a lot of history

Rick_Johnson: the incentives for the pub community... what are your hopes or aspirations for that?

Bill McCoy: each BG is unique

scribe: we have an offer to IDPF members, we hope that non-idpf members will join
... we don't know how it will create a value proposition
... if this gets stuff into the web platform, people will be happy
... the publishing business could have a high impact on the web platform

<HeatherF> scribenick: HeatherF

bill: there is a higher power than W3C, and that's ISO for EPUB
... ISO has committed to continue the liaison, and their ad hoc group

<lrosenth> EPUB as ISO spec - ISO/IEC TS 30135

bill: whether EPUB 3.1 should continue through an ISO TF is the right thing is still TBD

<lrosenth> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63567

bill: that would make successive updates to EPUB 3.1 a different process

george: with EPUB accessibility conformance spec, concepts from there should be able to flow into WAI and the Publishing WG?

Ralph: yes, that's the responsibility of the member submission

garth: next thing on the agenda is chartering and the PWP
...: but we've had enough PWP for the day

<Karen> scribenick: Karen

Ivan: for chartering

…it's a fairly long process to develop, especially in case of Working Group

…it keeps track of what they are allowed and not allowed to develop

…so a lot of thinking has to go into a charter

…to envisage what is necessary

…it may happen during the life a Working Group to change the charter

…then it goes through hoopala but people try to avoid this

…The main way to do a charter

…not sure if a habit or part of process

…but when we start work on a charter, we notify the whole membership that the process has started

…and we put the drafts in public

…The last time I developed a charter

…we used GitHub for everything, to get issues

…so we know that process

…How long this cycle of development takes depends upon the charter

…We always get feedback and remarks in this informal period

…the more comments the better

…We end this process when we feel there is consensus

…In our case, the discussions of today, last week are the kinds of discussions that are absolutely necessary

…This will help us to have a charter that would work better

…Obviously the job of those responsible for the charter, in this case the whole Interest Group

…to get wide spread comments

…Which means we would actively seek input from the publishing community, and other providers

…It may be a long process

…some of you may remember that we did chartering for this group twice

…Once we get to that point and it is done, it becomes more formal

…Formally speaking, a charter has to get reviewed and approved by W3M [management]

…formal review by two W3M members

…some of the reviewers can be pretty tough

…sometimes tougher than from the community

…if we get through that then a charter proposal goes to the whole membership of W3C

…the membership is expected to review and to vote

…We have the rule that five percent of the membership should respond positively to the charter

…If we get "all A's" and then some no's then that does not pass

…We need between 20-25 members providing comments

…In practice that means we have to reach out actively to members to get their input

…Members can object; they can propose some changes

…they can object in the sense that you have to make changes or we will oppose

…or they may say it's unacceptable

…Then it's a negotiation with who is objecting

…at the end of the process is W3M and then the Director who decides yay or nay

…Process takes easily three or four months

…In this case I would expect more time because of the cooperation

…not sure how the voting procedure will take place with the new IDPF members coming in

…I expect a pretty long process

…and we have to take into account the [to be formed] Business Group's input into this charter; so I would like to see these groups be actively involved in the development of the charter

…There are times set for recommendation, etc.

…Working Groups sometimes slip here and there with deadlines

…but good to use to refer to

…We can usually go ahead and publish a document; but in WG they can only be published as defined in the charter

…and reviewed by the whole of the membership

…One thing that I believe differs from IDPF process for 3.1

…for a document to get through the candidate recommendation phase

…there are clear rules

…it has to be proven that whatever we send out can be implemented without major problems

…and this has to be proven with at least two implementations

…I don't think IDPF has that

…That is the formal side

…The experience is…based on other groups

<chaals> [correction, it does *not* have to be proven with two implementations, that's just a common way to do so]

…need to look at testing, implementation

…groups usually push it

…CR phase then they look for implementations

…that is very often what happens

…Here I would like to see what other WGs have done

…to have ideally from the first day, groups in the WG who are doing experimental implementations as we go along

…some features may disappear as we change course

…For example, in RDF WG I had to update an implementation several times

<david_wood> Independent implementations are very helpful, and always a good idea. Chaals is (of course) right, though.

…but our CR period was only 2-3 weeks because we already had implementations ready

…It may be a prototype, but it's there and it can, business interest, etc., turned into a real recommendation

…Who can play this kind of experimentation role all along is too early to say, but it would be good to look at this from the start

…I see David Wood remembering the RDF experience; this is something to avoid

…I was looking at Laurent

…Readium for me is possibly one of the groups that could play this role

…that is only one

Tzviya: Leonard has been waiting on the queue

lrosenth: Ivan, as you pointed out

…the process for getting a Working Group charter will be long

…I would expect then

…that this group would continue; a question/expectation

scribe: until some time when all this work transitions into the WG

…no expectation that we stop and wait

Ivan: This group is formally chartered until October next year

…I would regard it as a problem if we don't have a WG before then

…There are obviously all the things we have done around PWP that would migrate into a WG

…but there is other work as well, such as the ARIA work

…whether they continue into WG or if they remain with those few issues

…that should be part of the chartering discussion

Leonard: Is there any reason should we choose

…that this IG could not charter multiple Working Groups?

Ivan: Absolutely no reason we could not charter multiple groups

…We had in SemWeb Activity 5-6 WGs

…which was hard to coordinate

…Now we have the Web Platform WG, kind of a giant; formerly would have been ten

…With more WGs, there is different IPR

<glazou> tzviya: staff contact time is money

Leonard: or it might be a good thing

Tzviya: One thing that most WG have is task forces

George: Is there a duration?

Ivan: It's usually two or three years

…at end of charter groups have to ask again for an extension

…For example Annotation WG just got extended by five months.

…We are in Candidate Recommendation phase to publish a document

…Otherwise at end of three years, you make the changes and go through same process

George: in the exit criteria, are there any accessibility requirements?

Ivan: Each WG decides what the exit criteria area

…there is no general rule

…that WG coming up may decide that these and these Access criteria

Daniel: usually there is horizontal review by Accessibility

Ivan: There is one point

…there is an extra procedure at W3C which we call Horizontal Reviews

…which means special expert areas review the documents we have done from specific points of view to see if we have made any mistakes

…At the moment there is an Accessibility review; same on Internationalization, Security and Privacy

…and sometimes there is a TAG review on architecture issues

…they come in and when we go to Director, we have to prove that these reviews have happened and we can answer all the issues that were raised

Bill: Can WG have Task Forces

…and that TF work would be of more general use

…so it could spawn another WG

Ivan: This may happen

…creation of a TF is under entire control of the WG

…not official process, it's our internal organization

…regardless of the TF

…if one of the Rec comes out to be more general

…then everyone would likely say hoorah

…a charter is good enough, then these things are settled

Tzviya: Queue is complete

Ivan: carried once, twice

Garth: We have discussion topics

…a couple of them here

…I probably put my name

…or maybe encourage Dave to put his name

…As we don't have lots of time for issues on the GitHub

…maybe get through these

ivan: I don't think we'll have time to take specific issues
... we should find time to take issues on the UCR however

garth: we could focus on those--since we don't have time to tackle the charter

ivan: it always improves the value of the charter, if there's some sort of prior work or art that can be referred to
... it proves that these things didn't come out of the blue
... that's why I was pushing for the UCR
... this UCR document will become one of the main entries for the Charter
... I would like to have (if possible) some sort of write-up about the EPUB3.1 browser friendly work
... to add as input for the Charter
... I think it's important to have that on the list

lrosenth: I'd like to use this opportunity to go through in detail a few things I've mentioned over the last couple days
... desires from myself, my company, and our customers--which I represent
... a group that is somewhat heavily focused on professional publishing
... and focus specifically on "ad hoc" publications
... I'm going to use PDF as the example
... there are 2.2 million on the public web
... Dropbox has 2.x billion
... and gets close to 2.x million every day
... [other places] have [lots and lots] of PDFs in their various content repositories
... these are numbers we should think about
... we've been spending a lot of time at my company talking to customers
... and I'd like to share these thoughts about what documents are and what they should be
... I'll make these slides available for you to take with you
... customers want documents--just as with publications--they want them to be touch-friendly, responsive
... they want docs that are not just text--have images--they should be rich
... they should be easy to produce
... you guys can laugh about this, but we have a customer who spends $$$ to produce an interactive PDF document
... we hope to use Web technology to make all this easier
... there's an opportunity where scripting should combine with documents
... I really want to point out that we should focus on documents and not just publications

ivan: where is this not the case?

lrosenth: i think the devils in the details
... especially as we consider the charter
... we need to make sure it's wider than it might not otherwise be
... I just want everyone on the same page

garth: EPUB 3.1 -- assuming the Kumbaya--will be covered in the CG
... and if this discussion continues, there will be lots of discussion about EPUB 4
... this is the harder part (disagreeing with ivan) of what we're doing

ivan: comparitively harder

garth: I'll agree with that
... dauwhe could you say a bit about BFF

dauwhe: BFF...some people love use case...
... and then there's me

<tzviya> BFF = Browser Friendly Format

dauwhe: I think by building things
... BFF is build on that desire to answer "what can I build today that provides reading in a browser" what are the pieces, etc.
... as we're thinking about Web packaging, unzipped publications, etc.
... my other participants in the project have more hopes of getting it all specified
... right now BFF covers a lot of what PWP covers
... but I still believe it provides a very interesting set of information

ivan: and it MUST be used as input to the charter

tzviya: and there are examples that are very helpful

ivan: yes. please do demo that
... insert agenda (re)hashing...

garth: if people are up for it, let's cover deliverables at 4 pm here in this room
... and touch on UCR's again

ivan: 3-4 pm is an AC meeting

Plans for coming months

leonard: I looked over the toc of the UC&R
... try to map what I though the general organization should be, to be more palatable
... broke it down in 5 sections
... 1st: use of the OWP
... incl. going offline (as it works in the OWP)
... 2: publishing needs
... is it fully addressed by the OWP today?
... 3: Permissions and obligations
... applies to both on the web and off the web
... 4.Discoverability
... 4. Working off the web
... 2 things that I suggest to remove, or find another way of talking about
... online/offline and state changing
... suggest to remove Version Control

ivan: thanks
... meta statement: I think we should seriously trim the doc
... 50 reqs is way too much
... either remove or merge reqs, it's already a source of issues
... based on previous discussion, I would put "use of OWP" and "Publishing Needs" in one big section
... for instance "Web Publications"
... would prefer to use "Package" for "Working off the web"
... not sure about Discoverability, could be in the web publications level

leonard: I was just reading at the UC as they are written today

ivan: having essentially 3 top level sections would make the message much clearer

tzviya: we need to clarify what we mean by Permissions and Obligations

ivan: source of confusion is the existence of a WG on POE

leonard: OK

rick: here as an observer
... knowing that the WG will inherit the work on EPUB
... it's not being referenced here

ivan: we tried to be as technology neutral as possible
... I would rather put that into ???
... at some point in time, we have to look at the current PWP draft
... making the bridge between EPUB and what is there is important
... I would prefer to put it as a separate work item, not mix it with the UCR

heather: my concern is that by being technology neutral we're loading terms
... is there a compromise where we could say "we're talking about SW or similar tech"

dave: we did want to do some work from the ground up
... w emay get back to a similar place but we may not
... we all have assumptions

<Zakim> bigbluehat, you wanted to ask about using "User Story" style

dave: it's valuable to spend some time avoiding mention of previous, especially EPUB solutions

benjamin: web anno WG had mapping between technologies
... could be an appendix
... I wanted to ask about the user stories format

leonard: my feeling is mixed on talking about specifics
... we learned that, at least in the web publication section, referring to existing web technologies will save us trouble
... I don't think anyone will object to referencing SW, as links
... at least people will see that we read these specs

ivan: I think the idea of putting references to EPUB work out of the main text might be a good approach, in an appendix
... there as a short reference
... PWP doc can have more details
... another thing. annotations and SW are not in the same category
... SW will be integral part of the browser world, just like HTML and CSS
... the Anno spec is, for the foreseeable future, will not be implemented by browsers
... may be implem by external tools (like hypothes.is), but not part of the core architecture
... it makes a big difference
... I fully agree that we make a ref to the Anno spec
... but for SW, I would almost remove the online/offline UC
... we live in an environment were we do have HTML, CSS, online/offline with SW

leonard: linked to another big question
... it's a big stake in the ground for future directions
... not sure the group is 100% on board with that stake

ivan: I think the idea is that the development is to be applications part of the fundamental web architecture, which will include SW

leanoard: I'm totally on board

billk: a clarification on anno: are we talking about the Anno spec as a whole, or just aspects of it?
... a UC linked to components of an anno, and access to these anno

benjamin: you specify a vocabulary model and a protocol
... we created a spec to put the anno data, not how to use it or render it

billk: I was talking about identifying that stuff

ivan: I don't see any problem referring the anno work, including the selectors model
... the selector part will be published as a separate note, to make references easier

tzviya: we have a lot to do, but no assignments
... would like to spend the next minutes discussing how to make the changes
... we have a new proposal for the structure of the doc

<lrosenth> Leonard’s Proposal http://drops.pdfsages.com/1jGKq

tzviya: Heather did a terrific job on editting
... we're talking about trimming the doc

leonard: I'm ready to volunteer to find duplications

ivan: I suggest that 1st we don't do anything before the reorg of the structure

<HeatherF> But there's no pressure

ivan: I think we can div up the doc in several sections, and assign per-sections

leonard: the duplications are accross the sections
... I think we should do the de-dupe first, then per-section review

heather: I agree with leonard
... easier if no dupes
... I'd also like to resolve the first issues I put to github

tzviya: I will take the action item to assign the issues
... leonard and heather can do the deduplication
... will use brady's assignmenet algorithm

ivan: once we've done that, it becomes more touchy

<tzviya> action tzviya to figure out who needs to work in issues that HFlanagan wrote

<trackbot> Created ACTION-64 - Figure out who needs to work in issues that hflanagan wrote [on Tzviya Siegman - due 2016-09-27].

ivan: once we have the new structure, dedupe, reformulation, we have to go back to marcos's issues, corss-check them

<tzviya> action lrosenth to dedpupe PWP-UCR

ivan: make proposals
... it comes at the end, but we have to properly close all these issues

<tzviya> action HeatherF to reorg PWP-UCR

heather: when do we need to do that?

tzviya: can we re-org an dedupe in the next 2 weeks?

leonard: OK

<tzviya> action Duga to assign review assignments to DPUB IG members

<trackbot> Created ACTION-65 - Assign review assignments to dpub ig members [on Brady Duga - due 2016-09-27].

ivan: the next question will be "how does this affect the PWP doc
... I already have a doc in a separate branch
... with simplifications (manifest combination)
... that branch is in a much better shape than the official draft
... what should be done in the PWP doc (the technical counter part of UCR)
... I suggest to put this branch in the master
... then once we have the new UCR, try to come up with a proposal on how the PWP doc s/b changed
... I'm happy to do it when we have the UCR doc

leonard: I agree we need to do sth
... given that we're not sure where the IG and WG are going,
... how to know what to put in the doc without knowing where we're going exactly?
... just concerned, I don't have an answer

ivan: I have the impression that when the UCR gets to the next state the rewriting of the PWP doc and the first draft of the charter may go hand-in-hand
... it's perfectly possible that the charter says: "this IG has identified this doc as a way forward"
... when do we think a new version of the UCR will be abailable on gh?

tzviya: de-dupe and reorg in 2 weeks, then heather does the major work

ivan: so we'd begin to look at the charter in early November
... there is a certain impatience to start the whole process, as it's a long process
... OK to look at this in early Nov

leonard: we may want to seriously consider 2 WGs, based on the separation we do in WP and Packages
... you can get a charter going sooner on WP if it doesn't include the Packaging aspect

ivan: there is a purely administrative reason why we shouldn't do that
... according to the MOU, transition members can join 1 WG

garth: the way to address that is with TF

leonard: OK noted, I wasn't aware of that detail

tzviya: we may have achieved the big kumbaya

ivan: where are we with the CSS WG?

dave: I have some action items, try to isolate the CSS issues

tzviya: can somebody help dave?

billk: is the MQ a done deal?

ivan: it's on the hand of florian

tzviya: there was a question about whether the latin req doc will be maintained
... can anyone help there?

leonard: I can contact people

romain: about the web publication and packaging issues, given that the separation will be even more clear in the UCR doc,
... would it make sense to reach out to the TAG?

ivan: it's almost like it's not a web architectural question

leonard: the issue is not the package itself, it's the web security model

benjamin: we can talk to people individually