DPUB IG F2F second day, 2015-10-30, Sapporo

Education and Outreach

karen presenting on education and outreach

karen: now more information on kodansha, one of the largest japanese publishers

junichi: there are about 25 japanese publishers sharing the market
... big publishing areas like books and mangas
... epub 3.0 did not work for manga publishing
... 3.01 helped with that
... but it is also a kind of headache since there are changes again
... there is lot of interested epubweb and related initatives
... have worked on publishing for a long time
... /me probably
... a great pleasure to be in this group and being able to discuss these items

karen: we made progress in meeting with editorial boards of major publishers in the US
... publishers weekly, publishers perspective, digital book world
... they all would like to hear from us and want content on a regular basis
... challenge is that we don't have enough people to have content
... wondering if any of you want to be an author for some of those publications
... we also have the w3c blog, the w3c digital publishing page
... and the IDPF would welcome shared information for some fo the work that we are doing together
... we might encourage participation today and find out topics your task forces would like to advance

heatherF: what type of content are you looking for?

karen: looking into introductory piece about the work w3c and ipdf do together
... then specific items on accessibility, stem etc. - the task forces
... not only the "what" but also the "why"
... they want to have a regular cadence on the issues we are working on
... small pieces are ok 500 words or less
... if more people are able to contribute on a regular basis we can have the w3c presence more often

<Zakim> tzviya, you wanted to talk about blogging publication

tzviya: ivan, karen and I spoke about this yesterday
... in some of the other groups, when there is a publication, there is the rule that there is a blog post
... that is somebody has to write it, and then you become comfortable with blog posts
... it seems like another task but we can put that together
... just created a draft post took 10 minutes
... minutes are important but we need more on the blog
... if we do something interesting let's talk about it
... did you play werewolf? write about it
... we are serious but we also have fun

duga: can write personal things in my blog post
... nothing I would have to clear with the company

tzviya: can talk about great meeting we had with i18n

karen: we are missing rest of the world - what are the other outlets that are valuable?
... where do you think we should reach out to that would be important for the publishing industry in japan
... are there publications or blogs that you read regularly?

jeff_xu: joined japanese meetup last Sunday
... we need to work on more communication
... we are a technical vendor
... we need to translate the publisher language to w3c language
... hope that we can build such a channel for publishers requirements
... we can broadcast then items to the broadcaster

karen: would you be willing to work with us on this?

jeff_xu: sure

karen: web sites, blogs, journals, ...

jeff_xu: I'll start from informal communication, then look into more official channel

takeshi: I have some concern to focus on publishers too much
... the publishers experience is based on printing
... most of the publishers will say: content will start from upper right
... but the web site will start from left up
... even if content is written vertical
... that is because the design is important for the web designers
... works for Japanese and translated web content
... there are no publication features designed both for Japanese layout and translated English content
... need to get the Japanese web designer on board!

tzviya: communication between web designers and publishers is very important

takeshi: web designers do what is available in web standards
... designers just accept the current situation

jeff_xu: we need to involve more creators
... who work with css, vertical writing mode etc.

<tzviya> http://ebpaj.jp/

baba: I posted URI of ebpaj in japan
... most of Japanese publishers like kodansha and others are member of this association

karen: so this would be a good way to reach developers?

baba: they make epub templates of Japanese publishing
... almost all publishers including small publishers use the templates used by ebpaj

<shigeya> EBPAJ = The Electric Book Publishers Association Japan

baba: they have some opinion on epub specs
... sometimes I talk to members of these association and they say: epub should do ...
... I am not member of this

junichi: Japanese publishing industry could adopt epub 3
... and standardize and "Japanese" spec to small and medium sized company
... various people do a great job of translating epub 3 spec for the Japanese book and printing industry
... but we need more production side people of Japanese industry
... publishers are so small and slized
... there is toppan insatsu, other big companies
... they are capable of taking up things
... we have to touch distribution and platform people and engage them in w3c
... epubweb is accceptable for me
... but publishers are concerned about backward compatibility
... if it is a guarntee that epub will stay back ward compatibly, and also a new version that would be great

tzviya: just to clarify: this group is not doing a new standardization of epub
... we are not addressing backward compatibility
... some of things that we are supporting is addressing IDPF
... e.g. in the area of identifiers
... the work we are doing here takes backward compatibility into account
... css layout is a great concern for vertical writing

ivan: EBPAJ is very important to fit another contact
... e.g. german börsenverein, german equivalent etc.
... page is kind of a blog
... it seems. my question: can Japanese colleagues at keio help to translate blog?
... that is to use the office and host network we have?
... would be quite challenging to do that on our own
... e.g. can sam or others can see if we can give blogs on side xyz?
... the blog we are talking about is for portable web application

<tzviya> some english info from EBPAJ: http://ebpaj.jp/counsel/guide

ivan: have that translated in japan

tzviya: we should expand our request to our membership

ivan: yes, for the people who are providing information to publishers

karen: we are working on building an infrastructure for dissemination
... working with our offices
... we have a platform, providing info about who to reach out to for what topic

fsasaki: maybe these organizations would like to do the translations themselves

ivan: agree, the offices or hosts can be a conduit to these organizations
... about what takeshi said - relationship between publishers and web designers is not only a Japanese issue
... publishers have long time experience of presenting
... sometimes wish that web sites would be as good layouted as publications
... believe me takeshi that this is not only a Japanese problem

tzviya: various organisations work around the world
... conversion houses, printers, ... these are the organisations producing ebooks around the world
... even amazon is using them!

karen: we have both technical information to distribute, but also business messages on trends, issues etc.

ivan: should this also be raised at next offices meeting?

karen: sure

ivan: I did not thing about that aspect previously, whether they are interested in more information

felix: think these organizations would love to distribute content

karen: we need to involve people in creating webinars
... we could do general, vision like, css, i18n, aria, accessibility etc.
... it takes some time including getting permission from your company
... others are doing marketing - we provide the content
... so is a webinar interesting for your to participate in?

tzviya: a first webinar can remind people that we exist
... who are we, what do we do, do you know w3c?
... then with more technical work we have done, css, esp. related to publishing
... talking about great tricks you can do to make your ebooks better
... we need to mindful about doing this jointly with IDPF
... we don't want to create a webinar about how to create an ebook

ivan: agree
... for this type of messaging a clear synchronization with IDPF is important
... we want to be clear that we will not take IDPFs place

charles: will be on panels
... on accessibility and MathML
... and will be on panel at CSUN on accessibility and mathML

tzviya: we should just touch base about what we do with karen

karen: yes, conferences is also another ecosystem we want to address

heather: I hate webinars
... I have a hard time to understand who are the target audiences
... one is the mgmt in publishing, more high level
... then there is more technical area, update on work that we are doing

... new resources, educational outreach for a more technical audience

tzviya: may be hard to get a c-level audience to watch a webinar

karen: no, would not be c- level publishing. for c- level we are looking into a c- level event, working with jeff and bill on that
... back to events - what are the events you think are important

charles: in march there is CSUN
... one of the biggest disability conferences, a week long conference on disability

karen: is that always in California?

charles: yes, in last 3-4 years has been in San Diego

ivan: the WAI team is always present

tzviya: there is ebook craft in Toronto, that is run by booknet Canada
... look of people involved in ebook development

<clapierre> http://www.csun.edu/cod/conference/2016/sessions/

ivan: local publishers association have their information

<clapierre> CSUN March 21-26 2016 in San Diego CA

<tzviya> ebookcraft http://www.booknetcanada.ca/ebookcraft/

ivan: probably somebody should be at these events - maybe not me; I then would be in the french event
... issue is sometimes to have the info

tzviya: IDPF had its event last year, doing it again this year

ivan: IDPF also wants to have an event in Paris

charles: do we have a twitter account?

karen: we have w3c account http://twitter.com/w3c
... using #dpub hashtag

ivan: I am twitter reader mostly

karen: what about library community?

lars: American libraries association event
... then IFLA conference, always in august
... between 3-4 thousand participants
... including c-level people from libaries
... having special sessions like accessibility, long term preservation, information technology (where I am in), preservation
... the next one is august 13-18 in Columbus, Ohio
... these are the two main events

ivan: what is profile of dublin core these days?

lars: metadata
... not sure about details
... in that community

karen: what about annotations?

<tzviya> http://www.sspnet.org/

ivan: may be hard for library community at the moment

tzviya: event in June, see link, we should be there

karen: in Asia? some large publishing events?

ivan: there is Chinese publishers event - I will find out next week
... there are big conferences
... problem is that Chinese publishers are in their own world
... there are very much in their own silo
... bill has been there several times, I'll go next week - we'll see
... India is next item - a lot of things happening here
... pryanka was at one of those events

karen: I'll check with her

<murakami> http://www.bookfair.jp/en/

murakami: Tokyo international bookfair

<tzviya> London book fair, Frankfurt Book Fair

murakami: largest event in japan

<Georg> +q

murakami: then there is paige event, of the print industry assoication

jagat

<tzviya> Rio de Janeiro International Book Fair

felix: jagat where main contact for doing the japanese layout requirements work

junichi: new law related to accessibility requirements

<clapierre> https://www.facebook.com/bookexpoamerica/

junichi: very hard for text book companies

<clapierre> BookExpo America (BEA) 2016 | Exhibits, Special Events, and Conferences: May 11 - May 13 | McCormick Place, Chicago

junichi: universities also must catch up
... next event or tokyo book fair must work on those fields

georg: interested in facts about the conferences you mention?

ivan: physical fair, in 90% of the cases, this is not the audience we are looking for
... many people listening to author and signing books
... for this group it is uninteresting
... this is only interesting if there is a side event around

[about page conference, see jagat site: http://www.jagat.or.jp/cat8 ]

ivan: frankfurt bookfair is a huge monster, we are not the ones that run the show

georg: we had an interesting experience
... in Berlin there was a conference on the industrial internet of things - different area
... the company organizes events that are very expensive to attend
... they want to get c- level people to the event
... speakers may be expensive but this is ok, since the tickets are expensive
... ticket around 3000 euro - we had Dave Raggett at the event talking about web of things
... we had a booth in the expose, had visibility
... that gave a great boost to web of things
... not if there is space in the company plannings - but it may make sense to organize events

tzviya: there was an event like that - books and browsers

tzviya: it was run by o'reilly
... the event stopped, o'reilly shifted to big data topic

georg: ok, more technical stuff

<tzviya> http://english.keris.or.kr/

tzviya: korea has event for educational content

karen: great, will pass this to Korean office

johannes: about frankfurt bookfair, I presented
... there are small sections with people interested
... you need to be in the right section

ivan: still it is an expensive exercise

tzviya: my impression in frankfurt was that there are mostly business people, no chance to discuss our topics

johannes: the smaller ones send technical people

<Zakim> LarsG, you wanted to offer to contact the relevant people at IFLA

johannes: was discussing with service companies

LarsG: want to reach out to IFLA, will be in touch with karen
... about ALA, talk to robert

heather: has connection to special libraries

felix: to johannes, your work is related to akep?

johannes: don't know them

<HeatherF> https://www.sla.org

felix: let's touch base and maybe join forces next year

karen: great conversation, this has been very helpful

ivan: what are the topics for the next weeks e.g. for blogs?

karen: announcement of portable web publications
... want something about TPAC
... open to see what is another milestone until the end of the year?

ivan: a blog post about css priorities that they have published about a month ago
... in CSS discussion, it became clear that the influence is different
... a blog on that would be interesting
... and aria vocabulary
... in an ideal world in which there is no discussion about the role of aria
... the presence of the vocabulary

karen: who would do the blogs?

ivan: maybe florian for CSS

tzviya: for CSS work with Rich Schwerdferger

charles: tpac blog, should we coordinate this?

ivan: we can also have several ones

karen: can also do both, coordinated and separate

tzviya: tpac snapshots, summaries, ...
... I always point people to the summaries written by ivan

[big thanks to ivan for that!]

karen: I'll put some items on the wiki and get that better organised

Identifiers

<ivan> Slides to start up the discussion

ivan: I have a lot of questions with no answers

… maybe some of you have answers, maybe it will take years to get answer

… What is PWP?

… fundamentally has a single URL for a collection

… of web resources

… And then we have potability, which is a little vague

… but essentially the entire entity can be moved around

… example of fonts - they may not be essential for displaying content because they are stylistic

… but sometimes they are fundamental (for example, for musical notes)

… also different ways to access the PWP (file vs protocol), but skipping over that for now

<scribe> … New browser features like service workers help with this

… acts as a network proxy

… Worked on an architecture that intercepts web requests that may used cached state

… or even access a package file

… and happens without the rendering engine knowing or caring where the data comes from

… Looks like it is always on the web

scribe: finally, the packaging structure (whatever it is) has a bunch of web resources (JS, html, etc)

… and some admin files (manifests, rights data, etc)

… which together form a PWP

… As we mentioned yesterday, there is ongoing EPUB 3.1 work

… The most important thing is 3.1 makes a commitment that it be backwards compatible

… but they are still looking at something similar to what we are, so we have to coordinate

… So, identification.

… Have one identifier the seamlessly works across all states

… Need to coordinate this with web workers

… also want identifiers that have fragments

… because we may want to reference inside the PWP

… BUT, don’t want to reinvent the wheel

… So, what is the URI?

… We have the magic of service workers. Is that good enough?

… There is one URI for the book, magic of service workers makes it look like it is always there

… Need to understand how it works with local content (for instance, file: protocol won’t work with service workers)

… Second, what does this really identify?

… A general book (Hamlet) or a specific book (SomePubs third edition of Hamlet in Japanese)

… Plus lots of versions (epub, pdf, kindle)

… Different domains have different habits and approaches to identifiers

… ISBN, DOI, etc

… Is it realistic at all to solve all the requirements by separate identifiers?

… Just asking questions!

… It is NOT W3C’s role to solve this

… but who the hell will do that?

… handled by libraries forever, and still not solved

… What does a GET return?

… Manifest file, HTML with link, a file with something in the header? All? None? Something else?

How do we get into a publication?

EPUB CFI has some cryptic method

… Maybe use ‘!’ as a separator

… Or mimic the file system and just use a slash

… slash is closest to the web

… CFI is hard to reuse, relies on xml

… and specifically the package file

… all of these assume a hierarchical structure

… but PWP doesn’t inherently imply that

… We could have a manifest file that has some sort of redirection

… RFC650 has some stuff about URL templates

… once in the document, we need to get into content

… Can use fragment identifiers

… This is how the web works, so may not be great, but it works today

… we may be able to influence ongoing work

… for example, the findText API in web annotations

… richer than just a search string

… will be expressible as a frag identifier

… How should the resources refer to each other?

… Do we need to restrict it?

… Maybe only relative URI?

… Seems sad, maybe we can solve this with service workers instead of restricting it?

… Need to define some scenarios about how the identifiers will work with all the states

… may guide us to some answers

<Zakim> liam, you wanted to remind us that URIs can be redirected, e.g. like an XML Catalogue, e.g. by a servant-worker

liam: Nice overview!

… We have similar problem with identifiers in xml

… we solve it with an xml catalog for fetching DTDs

… common practice rewriting the URI

… makes sense to have a service worker look in a manifest to get a DTD from somewhere else

… specifically on the syntax, you use a hash and slash, could also use ‘?’

ivan: I may not have emphasized enough

… a web pub is a collection of resources

… but each resource is on the web, so you want to access them directly

… the canonical URI should be the URI used, which pushes us to using path separators instead of ‘!’ or ‘?’

liam: OK, don’t need to get bogged down

SteveZ: I think almost all the issues are important

… but there is one red herring

… and that is what does the identifier identify

… what you point to is not something you need to answer in this case unless it effects the format

ivan: I would love it if you were right

… but if you look at our uses cases we need it

… for instance, you annotate some book

… then you take the book and move it locally

… then you push it back

… originally the book might be a public resource on the web

… when I make changes it because something different

… I may need a copy of the original which has a different ID

SteveZ: But that has to do with the format of the annotations on something than on what the something is

… it means the annotation format needs to reference the base thing

ivan: it may mean the same pub has several identifiers

… a canonical one

… with say the metadata from the pub

… another is one for my local one

… maybe we need two different ids

SteveZ: Yes, that’s what I am getting at

… the issue of what you are pointing at depends on how you are using it

brady_duga: you were talking about heirarchical nature of these
... epub-cfi doesn't require that, it already has aliasing
... it still requires a spine
... but things can live wherever
... you're not reaching things by URL, but by reference in manifest

takeshi: I was also thinking about the same approach

… but ran into some issues

… we have to remember ISSN

… mainly for periodicals

… and collections

… since they are collections, we can’t reach each issue

ivan: I don’t understand - why is an ISSN different than say DOI?

takeshi: ISSN has a title, but doesn’t have the physical content

… It may have “this is todays issue”, “this is yesterday’s”, etc

takeshi: But still virtual

ivan: But maybe that is the purest form of this identifier

… maybe they are all virtual

tzviya: DOI can include ISSN

…

LarsG: I think we are on the same page

… ISSN references a series of things that are published periodically

… I see you could make an ebook of everything that is reference by an ISSN

… but that is weird. An ISSN references the series itself, not the items in the series

… An ISSN isn’t appropriate for an ebook

tzviya: But we aren’t using it for that

… You would use ISSN + DOI for a specific article

ivan: Too deep in the weeds

Florian: While this topic is important for us, it is broader than this

… need some sort of identifier that doesn’t require an authority

… using a hash. Bert?

Bert: There is a system, in particular a system called Freenet, that uses a hash

… it’s the old URN idea with an actual implementation

ivan: Half of me says, let’s explore that, it’s exciting

… but difficult to go to publishers with it

… anything we come up with should be very down to earth

Florian: Don’t want to require this, but need to work with the rest of the web

… maybe it just works on http, and it ony works to identify on the web

… instead of specifying protocols, we have multiple pieces and we can implement all or part to get different levels of expression

johanneswilm: If we have some identifier for this, we should resolve larger issues we have with ISBN

… sometimes we have multiple ISBN, there is no control over reuse (done in practice), etc

ivan: This is my last bullet item - we will NOT solve it. We shouldn’t even try

… Industry needs to solve ISBN

tzviya: You say publishing industry, but it is not just one

Florian: Maybe it shouldn’t be one authority, it needs to be decentralized

ivan: I understand, but all we can say is a specific publications should have a unique ID

… But that is all. Saying exactly what the form is not up to us

johanneswilm: Let’s make it clear we are not depending on ISBN

ivan: agreed

Bert: What does it mean for the format to packed vs unpacked? How does it change?

ivan: Conceptually, it is the same publication that can appear as a package, or it can be on the web and you get a URI

baba: On the books store, we have 2 versions. Sample vs full

… The package document has different IDs

… but we want to share bookmarks

… so in this case the id should be the same

tzviya: I think this would help that

… Just use one id, but control access

… so it is just access

baba: Having the same id is a good id, but the indentifier is not a single string

… I don’t know what the ID is in that case

<fsasaki> file 1: <p id=p1> ... file 2: <p id=p1> ... uniqueness & scope issues for identifiers then assembling ebooks from distributed html content? see xliff fragment identiifers special purposed for "assembling content" scenarios http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#fragid

tzviya: Not dealing with access at the moment, but is important

fsasaki: Imagine existing content as above

… assembling existing content is a real use

… so a sub-resource was identified uniquely, but now isn't

… may need to consider scope issues. Have you considered it?

ivan: No.

… so the fragment is within only 1 html file

… fragment is unique inside the file

… could have collisions at the file level

… but that is problem for the person merging these

fsasaki: Wondering about sub-portions of a publication

… not a problem for file level

ivan: Not specific to us, can always happen

SteveZ: Asking about identity - can I tell if something else is the same thing as an ID I have

… But if you aren’t solving this, then why is it an identifier?

ivan: Correct, it is not an identifier in that sense, just in URI sense

… Not ISBN

… what we care about is something on the web, using it in the sense of URI

tzviya: Ted says offline we should be using URL, because we want a locator

<Zakim> LarsG, you wanted to talk about URI vs URL when it comes to location

ivan: Get’s into religious arguments about DOI being an identifier vs URI

LarsG: I don’t URN is appropriate in this case

… if I unpack the thing local (from a web address)

… then the location is not what the URI says

… so it isn’t about where the resource is

… DOI isn’t about location, since it can be multiple places

ivan: But when I use an http thing, I can udentify specific things (like myself), so there are arguments about these uses

… so we must clarify in the doc

<Bert1> (Another location-independent URI scheme is the Magnet-URI, a generalization of the Freenet scheme, and probably better known.)

plinss: This is just rehashing old TAG arguments

… Please don’t go there

… URL is a locator.

… If you give it magic meaning beyond that you will have a bad time

… let’s not resurrect the semantic web abuse of URLs

… what it means is the thing you get when you dereference the URL

… If I fetch a GIF off the net, even if it is in the cache it is still the same thing

… so they are equivalent. The URL doesn’t mean the image itself

takeshi: I think this doc needs IRI

ivan: That is another aspect, but yes

jeff_xu: For pubs, it is easy to identify, but for self pubs how does it work?

ivan: Don’t understand

jeff_xu: Is there a mechanism for self pubs to create an identifier?

ivan: By virtue of being on the web, it has a URL

… if I want I can use a service to create a stable URL that behnind the scenes redirects you

jeff_xu: If I put my book on a different store, it might have different identifiers

<johanneswilm> +q

ivan: Just like today, it will have two different identifiers

tzviya: This is a retail question and isn’t somethingwe can address

<Zakim> LarsG, you wanted to talk about what I annotate

LarsG: In that case we need to careful about what we are really identifying

… if I have a URL for something I can download, then download it they get different identifiers

ivan: If you downloaded because you are online

… then when you get online, it magically works when you are online

… different scenario, when you really duplicate, you made a different pub so has it’s own id

tzviya: Next steps

ivan: I would hate if starting tomorrow I was the only one thinking about it

… needs more common work

… need scenarios of usage

… so we can get to possible answers

… whether we uses hierarchy vs redirects for instance

… not writing a spec, just want to gather points and come to some sort of format

… not sure how far IDPF wants to go

tzviya: Yes
... Next step, talk to Luc

… how about this group?

ivan: Collect scenarios

… then see how these possibilities work with them

… indepentantly, I am not the first person who has thought about this

… so there may be others with at least partial answers

tzviya: Do we have insights from the visiting types?

… words of wisdom?

SteveZ: Deciding how to tear something apart before you know what is in it is a hard task

… probably want to know what the manifest is before you decide how to address pieces of it

LarsG: Talking about works vs editions

tzviya: Q: thing like “Shakespeare’s Hamlet” is out of scope. What about revisions?

… and versions

… publish a version with typo

scribe: fix it, repeat

… does the version and revision show up in the URL?

… like github?

dauwhe: Maybe leave something for the document itself

SteveZ: Don’t put metadata in the URL, since you won’t get it all

ivan: In some sense regardless of syntax, what are the info you need in the manifest

… You need something like a manifest, what is the required info for it.

brady_duga: Point versions, may need to point at a specific version

ivan: Yes, just like CSS versions of specs

Florian: Can we encode all this in the URL?

… It is very broad

… we can’t solve all of version control, unless we put the whole web in git

ivan: This requires lots more mail discussion

Meeting with the ARIA WG

tzviya: introductions

<tzviya> agenda: https://www.w3.org/dpub/IG/wiki/DPUB-ARIA_Agenda

tzviya: talked about extended descriptions. Michael Cooper put together information on the descriptions.
... our group offered feedback. ARIA (Michael Cooper) needs to review.

Michael: thought this was just input into the grid.

tzviya: some discussion on that list may be necessary in the future
... some of the things we want to update is where we stand with some of the elements

<tzviya> dpub feedback from DPUB on extended desc http://w3c.github.io/dpub-accessibility/extended-description-analysis.html

tzviya: do we want to even try to address that today?

MichaelC: what we want to get to is a ruling out of some approaches.
... of the approaches that don't get ruled out, which have issues with implementation or authoring complexity.
... You can start with the first table to rule out approaches. If use cases are important then any "no" in a use case steers it to being ruled out
... A couple of the figure and detail approaches ("describedat", etc) don't actually fly

??: if there is no disagreement, but also if there is no factual disagreement, then probably a reasonable next step will be to take the ones out that do not support what we need supported

scribe: That takes us down to just a few.

ivan: which would stay?

MichaelC: figures with detail source and role attribute meets most of the use cases; ariadescribedat meets all of them; web components proposal might meet all of them;
... web annotations might meet all of them. Those are the four we should look at most closely.
... We are therefore ruling out people's pet solutions.

ivan: don't know if it is a good idea to rule them out all together at this point. If you take them out then there must be some trace that they were at least considered

MichaelC: table must provide data as to why we made decisions

liam: some of the "no's" we have in th euse cases are about what is, not what could be

tzviya: some of the "yes's" almost exist (e.g., web annotations). We need to talk about what works today, tomorrow, or next year.
... not sure the column reflects today, but we think work is being done towards something.

jason: in the comment on the draft posted to the list, pointed out issues with details element. It doesn't reflect the proposal made by James Craig.
... whether extended descriptions are even wanted; could be used to hide content from people who don't want to see details.
... The whole media query idea is not captured in the document.
... and the details element, most of the people discussing it did not like the idea of adding an additional source element.
... The live proposals are not the same as the proposals in the table.

MichaelC: the table was an attempt to collect data non-judgementally

liam: table is fabulous to inspire discussion
... the first "no" is not restricted to images (e.g., longdesk). We have somewhere else in the table where solution is not widely used, but the proposal is for a solution that no one is using.
... This could be improved by being more fine-grained with the yes's and no's

MichaelC: The first table is a description of the approaches; we could add data there. It is a seven-dimensional table.
... we can't rule something out only because there are no's in this one column in the table.
... One of the lower down table tries to get into whether things are, or are likely, to be implemented in use agents. That's a proxy for whether people do/don't like the approach.
... If something passes the use cases but fails the likely-to-be-implemented, we need further discussion on why
... Table after that is an attempt to get to that (e.g., is this easy/hard to implement?)

ivan: looking at a table, would put the web annotation column in a slightly different format. It is different from the others.
... it is an abstract model, so it feels like comparing apples and oranges.

MichaelC: Figure with details is another mechanism being proposed.

ivan: but this has nothing to do with markup. Maybe we will have markup for webannotation, but that has not been decided. We also have no idea if any browser will implement it.

MichaelC: that's why subsequent tables say "not likely to be implemented in the future". We shouldn't put too much weight on this table; it's a discussion exercise not a decision

tzviya: there are a few things here that can be considered generic elements.
... Instead of walking through different elements and seeing what works/doesn't today, we should talk about how we want to proceed.
... DPUB has given ARIA a bunch of information; what else would you like?

MichaelC: Haven't gotten feedback from other groups. This is the only feedback that hasn't been incorporated yet into the ARIA table.
... Not looking for more input specifically from DPUB.
... We aren't yet at the point to make decisions. This is now a heavy discussion phase.
... Pick 3-4 of the approaches most likely to succeed, and then start having discussion with stakeholders specifically on those.
... We will ask them to provide details about how their specific implementation might meet the use cases, if they argue for their position.

tzviya: Hoping Mark can give an overview on what he's been doing.

Mark: Am with ETS, doing educational assessments. We author and produce educational tests for K-12 to university entrance exams and workforce exams.
... Much of the work comes out of the IMS Global Consortium
... In almost all cases, the assessments are delivered via web technologies and browsers.
... We are looking at how to use models out of the QTI world in the web world.
... We're motivated to do this because different testing orgs will implement the test items in all manner of HTML implementations, leaving poor interop and poor user experience
... Started to tackle something different in a prototyping effort: the need to provide extended/alternat descriptions for images.
... So, took a tool called diagrammer that include a variety of information that described an image.
... How do we get that into the HTML? We dont' have anything that is reliable for long descriptions, for example.

<tzviya> diagrammar: http://diagramcenter.org/standards-and-practices/content-model.html

Mark: So, took the diagrammar content model and tried to apply it to HTML. Could then build a prototype object.
... Allowed for some interesting UI development based on the existence of information in this model.
... next step is that IMS is looking at a new version of QTI and the custom element model is being actively considered as a part of that.

tzviya: are you translating APIP into ARIA?

Mark: APIP was not a well designed approach, so we are diligently trying to transform the best principles of APIP and transforming it for the next version of QTI.

ivan: At this moment, custom elements is something that is available in Chrome, but no other browser implements it.
... We are on very shaky ground with this.

 Janina: there are issues with custom elements being worked on, and there is progress being made. When will it be ready? who knows?

Mark: looking at a fallback using detail elements and scripting
... We do have a pressing need to solve this problem. Having every vendor of assessments coming up with their own approach will be a Bad Thing.

<tzviya> hober: the existing implementation that polymer is built on will probably be incopmatible

clapierre: Benetech is going to be working with mark's team to take the custom elements and take it to readium for a solution.

tzviya: In the DPU module of ARIA, we have several roles that have questions (e.g., *ref)
... there has been a suggestion to replace with rel* attributes or use something from the COGA (?) model

ivan: Talking about rel = " ", I have offered conflicting opinions. Current position is that it is not appropriate.

<tzviya> http://www.w3.org/TR/dpub-aria-1.0/

ivan: You can find yourself in a situation where a value used in the rel attribute can be misinterpreted by an RDFa processor, because the RDFa uses the value of a rel attribute under certain circumstances
... this is a consideration that cannot be ignored.
... Using rel for a possibly large number of additional values around ARIA may be a very dangerous proposition

MichaelC: we don't have consensus on that yet.

ivan: we discussed on the mailing list re: defining it, but that has more of a social aspect to it. My problem is more a purely technical situation.

tzviya: if we used rel, it would break things.

Janina:  COGA is not part of the picture. They worked their way into the conversation because part of their remit

scribe: As they were roadmapping and blue-skying, they were creating attributes. The conversation then went away from requirements, but whether this was an appropriate application of ARIA technology

Janina: we asked them a few days ago for clarification, and asked them to reset their examples that does not use ARIA
... i.e., just call it coga-[something]

<tzviya> COGA TF of WAI: http://www.w3.org/WAI/PF/cognitive-a11y-tf/

Janina: At least lay out the overall pictures of what the problems and opportunities are, so we as W3C can look collaboratively on how to extend the benefits of web technology to people with disabilities
... we haven't really served that community well to date

ivan: we get back to th original issue, which is what do we do with ref from the DPUB side

tzviya: A number of people rejected these roles, whereas people outside the W3C asked for these roles?

Janina: We tried to get to unanimity, but we don't always succeed. W3C does not require unanimity, it requires consensus.
... We have to decide at some point and move forward, and we do that on preponderance of opinion, not unanimity

tzviya: Yes. We are interested in doing this well. If there are reasons not to include those roles, we need to give it seirous thought.
... The rel thing sounded appealing, but if it causes more harm than good, then we shouldn't do it.

Janina: It got close exampination; if the facts were wrong, then we need to fix that. But if th efacts are right, then we need to move forward with aria-
... Due diligence is what the process requires, and that has been applied.

tzviya: While we're on the topic of the DPUB-ARIA module, we have a few outstanding issues (but nothing major aside from the API mappings)
... we have a timeline for a second public working draft. Is there anything standing in our way with that draft, modulo those few outstanding issues?

Janina: No, we should be able to go forward

hober: publishing working drafts more often than not is what we should be doing

ivan: since the prefix has changed, we need to get this out sooner rather than later

Mark: Have been looking at the spec, and playing with the aria- role description. It might be interesting to build some of those examples into the next draft.

tzviya: yes, the draft needs examples.

Mark: have examples to share.

ivan: there is a group in Bologna that are developing a profile for scholarly publishing. They use these terms with the latest prefix as structure in the article.

Mark: We were talking about our use of QTI; one of the reasons we asked for ARIA role descriptions is to help users by impacting the UI. e.g., make a question sound like a question
... So, existing aria role plus role description gets us most of the way there, rather than bringing in new roles

tzviya: the public review period ended over a month ago for this draft. Would love to look at Mark's examples and at various implementations, but we don't want to abuse aria
... if the whole vocabularly can be duplciated with role descriptions, and can convey the information for more than just the audio reader...

Mark: We have had the discussions on how to bring semantics of HTML back when we talked about DAISY. There must be a mechanism for bring semantics in, but still uncomfortable with overburdening roles.

<Zakim> MichaelC, you wanted to mention pub timeline

MichaelC: The likelihood on imminent feedback on one topic doesn't mean we shouldn't go ahead and publish. We can always do a third draft.
... the ARIA group is going to do a lot of work after TPAC, but it would be great to work with the revised draft.

tzviya: need to check with markus, and see mark's examples
... We are working on a revision of EPUB. We would like to incorporate this into the EPUB 3.1 revision. Hoping to have that finalized within the year.
... We have added an errata to 3.1 re: describedat, but we don't have anything to replace it with.

MichaelC: describedat is not entirely off the table, but it's not solidly on it either
... You would like us to resolve extended descriptions sooner rather than later to help with the EPUB 3.1 spec

Janina: Who would work on that?

tzviya: ARIA, not DPUB.

MichaelC: ARIA shouldn't do it by themselves.

Janina: This needs a home. APA's role is to make sure this happens, so we'll work on coordinating. But we need decisions.

MichaelC: We can only make good decisions based on information we have.

(sorry, tzviya)

Janina: we are trying to get more feedback and discussion, but we are reaching (have reached?) topic exhaustion

tzviya: That was what we had on the agenda.

Janina: Ted, you are ok with details?

hober: yes.

tzviya: Next up - wrap up and action items for the DPUB meeting
... DPUB-ARIA will have a meeting this coming week and discuss publication of the draft

Housekeeping

tzviya: Great turnout at this meeting.
... two years ago, that wouldn't have happened. But the amount of work has increased too
... some highlights: Dave now has friends from DPUB in CSS (e.g., Florian, Allen).
... we will clean up the priorities document and have more communciation with the CSS group
... will try to have more conversations with our math friends

ivan: the CSS WG needs very clear example of what typesetting means for publishers, and what can be achieved compared to that with current tools
... This kind of documentation as part of the prioritization is importnt

Florian: bringing the examples is important. The people who bring them will need to understand them very well, since CSS will ask very detailed questions about why things were designed the way they were

tzviya: We will be bringing examples at least in English and Japanese, and hopefully other languages.
... In the session with Daniel, we started a community group on the Publishing Object Model
... Daniel will work on creating sample files.
... That overlaps with the work happening in this group and the IGBF. There needs to be communication between these groups.

ivan: During the 3.1 discussion, there was one aspect that came up re: the analysis of 3.1 hope that the subgroup on browser friendly manifestation will abstract out what the manifest needs for more than just EPUB

tzviya: Jake came to talk about Service Workers, and discussed details. Explained to us that accessing the file may not be what Service Workers are going to do.
... We filed some issues on github on the portable web document. Jake offered to create some samples for us.

Florian: He proposed to create a pair of applications. One where you can go online and read online, and one where you read offline and can export. The second part of the application would be consuming it and preserving integrity.

ivan: if he does that, we owe him more than cookies

tzviya: In our session with Karen re: education and outreach, we all have action items to write, blog, inform.
... If you know of conferences or industry organizations, let Karen know

ivan: regarding identifiers, we have many questions.
... it seems to be unavoidable that for decent usage of portable publications, we need a manifest. So we need to know what a manifest should/must/may include.

tzviya: With ARIA, we will continue discussions.
... It was good to see everyone here and participating. But our mailing list doesn't reflect the energy and enthusiam. It takes someone frustrating us to get us active.
... You don't need to wait until the weekly calls to talk about issues. If you have a question/idea/thought/haiku about TPAC send it to the list.
... Let's get work done ON THE LIST.
... The work needs to be distributed to more participants.

ivan: One thing that came up yesterday. We have been using this time slot for calls for a few years, knowing that for people on the west coast that it's not ideal.
... Maybe it's time to look at the time again given the evolution of participants?
... The India office had a similar problem and tried to create a time convenient to them. We set up an infrastructure to support that, but it ended up not be used.
... We could try an east asian collection, but whether that would be successful or not not sure.
... This will require more thought and discussion

(ON THE LIST)

Florian: two meetings probably wouldn't work unless the core people attended both, which is not realistic

tzviya: May have a regular time and one alternate time a month. Will discuss ON THE LIST

<ivan> ---- adjurned