Digital Publishing Interest Group Teleconference

<trackbot> Date: 22 June 2015

<ivan> present dave_cramer

<Julie> + julie morris

<ivan> scribenick: dauwhe

<tzviya> chair: tzviya

<tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0076.html

tzviya: let's get started

<tzviya> http://www.w3.org/2015/06/15-dpub-minutes.html

tzviya: last week's minutes
... any comments?
... minutes approved

Aria's described-at attribute

<tzviya> https://lists.w3.org/Archives/Public/public-pfwg/2015Jun/0091.html

tzviya: PF has asked the publishing community to look at aria-described-at
... it's at risk and might be removed
... Rich has asked us to send comments
... we discussed this on friday

dkaplan3: described-at is very valuable for digital publishing a11y
... some of the concerns about longdesc are addressed by this
... some concerns are not addressed, but we still think it's valuable
... very powerful: any element can reference something further away
... we think it would be good for dpub

tzviya: right now publishing is embracing a11y, but it's in early stages
... took me 18mo to get my company to use alt text
... we're a slow moving industry

<Bill_Kasdorf> +1 to Tzviya

tzviya: we like a11y and want to support it
... but it's tricky to say if we don't use this right away, it will be removed

dkaplan3: the publishers want us to tell them what to do
... they will adopt them at glacial speed, along with reading tools
... must be supported by user agents
... they want us to say "here is what you can use"

Bill_Kasdorf: quick question
... is the key point that longdesc and described-at are not the same thing
... some folks who hate longdesc also hate described-at
... sometimes for the same reasons

dkaplan3: we want both

ivan: I was not part of this discussion
... what is the problem with the attribute? Why is it questioned?

dkaplan3: when you are talking about offline reading, having an attribute referencing content that's not packaged is a concern
... is it worth addressing? We think so.

ivan: one thing we want to achieve is making offline/online distinction secondary
... content may be offline now, but may be online in two hours or two minutes

Bill_Kasdorf: that reinforces argument that we need both

tzviya: we have lots to do

dkaplan3: a good thing from dpub would be
... use cases showing how these descriptions are really big or really frequent
... and so they do need to be linked from somewhere else

<tmichel> rrsagaent, draft minutes

clapierre1: longdesc is not an a11y attribute, aria is
... because it's an a11y attribute, it should be something else, so it can be used for anything

tzviya: next steps for this group
... dkapan3, could you write up a few sentences to send to Rich and friends
... it's important, we may not be able to embrace immediately, but we're coming

ivan: I can read it

tzviya: this is where our role as liason to BISG would come in

Julie: we can also mention that in a bulletin

<pkra> stem

tzviya: as soon as I find the agenda I'll talk about what's next

STEM Survey

pkra: update
... we're still working on survey
... making progress
... some tech difficulties which have been resolved
... vacations have been resolved ;)
... we had summary from w3c form system
... generated the source data
... Nick pushed it into an SQL database so we could query

<ayla_stein> fire alarm, have to leave

pkra: we have this database, and Tim has explored
... can get advanced slices of data
... now we can slice up data based on background of respondents

<TimCole> I am on the call.

pkra: people who are publishers point to lack of w3c standards
... but authors didn't mention this
... so we get useful information
... next steps?
... planning a meeting of task force soon
... jump right in to writing the note
... based on survey structure
... and we can create better queries
... the more you look at survey the more it becomes clear it's limited in it's usefulness
... not a representative sample
... 2nd problem is responses have limited quality
... which is the fault of the survey
... there aren't actually many obvious patterns
... which could further the work of task force
... people are unhappy with lack of MathML support in browsers
... but this is not a surprise
... we will see some interesting snippets
... we're working on it, we're making progress
... the bigger question is what we can do next
... the survey has not been super-helpful
... I now have more ideas on MathML

Karen: what kind of people do we want on this task force, and what deliverables are short and long term possibilities?
... what are we inviting them to work on?
... that's a q for peter and wider group

pkra: work on whatever they work on, which may sound ridiculous
... we have the example of chemistry where there's a strong xml standard
... but there's nothing that ties into w3c work
... we need to find people to bring the right kind of abilities
... and here I'm not the expert

tzviya: we've had more feedback on workflow than tech issues
... people hack it
... chemistry, physics, any sciences
... we don't want to create work for ourselves
... if it's not immediate we have enough to do

TimCole: we need to do human reading of data

<Bill_Kasdorf> +1 to Tim

TimCole: and come up with more succinct survey, that could be filled out by larger group

<Karen> +1 focused quantitative survey built on top of qualitative work Peter did

TimCole: many answers said, "we should have asked this"
... interesting dichotomies
... particular content types could benefit from standardization, but list was divergent

ivan: putting on my w3c hat
... an interesting question would be
... are there formats like mathml that need standardization
... and can be done at w3c
... this kind of input would be useful
... there are a number of formats out there that are created for different purposes

<Bill_Kasdorf> Re Ivan's question, I'd suggest chemistry and 3D

ivan: do we know what they are, how mature, do they need a home?
... chemistry, 3d, probably others
... I told you about Doug and I bringing in MusicML
... knowing about the needs would be valuable for w3c management

pkra: another example
... the jupiter notebook format, a computational document format
... there's an opportunity, but it's very early on
... both the iPython people and publishers see that this could be standardized
... but it's too soon
... i don't know which of these things fit well with mission of w3c
... it's very application specific right now
... but could be more general purpose in 3 or 5 or ten years

<Bill_Kasdorf> One way to pose the question to publishers would be "what formats would it be useful for browsers to natively understand?"

tzviya: we have full agenda
... it's a work in progress, we'll know more in a few weeks, and task force will be drafting a note
... sounds like you need more human-power

pkra: we have enough people but not enough time

tzviya: we'll takl about timelines. when do you expect draft will get started

pkra: will be started at next TF meeting, this week or next week

tzviya: we have timeline in our charter
... let's talk about timelines offline

<tzviya> http://www.w3.org/2015/06/mathmlpas.html

tzviya: Karen emailed about ISO standardization of MathML and how they need support statements

<pkra> +1

Karen: send them to me. Quote, org name, attribution, title

DPUB-ARIA

<tzviya> https://rawgit.com/w3c/aria/master/aria/dpub.html

tzviya: the digital publishing module of ARIA
... biggest change is a note
... mentioning that we're formally requesting feedback from publishing, and specifically IDPF
... "don't use this until we resolve confusion w/ EPUB structural semantics vocab"

mgylling: you got it all

CSS Priority Use case

<tzviya> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0075.html

tzviya: some additions to css priorities use cases on cjk

murakami: I received a comment from chinese layout task force
... bopomofo is listed ???

<murakami> http://dev.w3.org/csswg/css-ruby-1/#valdef-ruby-position-inter-character

murakami: bopomofo should be listed in CSS priority list

<tzviya> marakami: chinese layout TF said bopofomo should be listed in these requirements

murakami: Chinese needs this

ivan: two things
... Bobby told us about this before, it's important for traditional chinese
... my problem is not with what murakami added
... we know that css modules do deal with ruby
... also try to take care of bopomofo
... we know that's happening
... but what are things that are needed but are not happening in CSS
... how to distinguish between what's important but being taken care of
... and what isn't being taken care of
... we need priorities here

tzviya: murakami, can you take care of that?

murakami: yes
... i have to find the priority

<tzviya> https://www.w3.org/dpub/IG/wiki/CSS_Priorities_for_the_Digital_Publishing_Community#CJK

<tzviya> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0001.html

Web Publications

tzviya: with fifteen minutes left, we get to today's discussion topic
... talking about packages and how to identify them
... at F2F we talked about packages, fragment identifiers, and primary identifiers
... and whether we need a package
... I'll turn it over to markus and ivan

mgylling: ivan, can you give us a summary?

ivan: i can try
... we discussed at F2F and later
... whether we need packaging, what format, etc
... and we talked about identification of package
... on the mailing list we had vague conclusion
... what we need is an abstract concept
... i don't want to use the word package
... a web document which is not the same as a web page
... which contains all the dependencies in one place
... along with pages that are logically included
... if it's offline it's in a package
... if it's online there's no real term
... bill was pushing for word publication
... more a conceptual thing than technical thing
... helps keep our mind focused
... can be tightly bound to web manifest

<Bill_Kasdorf> A publication can contain many documents, and it can be packaged or not packaged.

<tzviya> +1

ivan: which is equiv of package file in epub

<tzviya> +1 to web manifest. that is

ivan: epubweb talks about these web publications which have offline and online manifestation
... the whole addressing may become much easier
... because it's closely bound to what happens online
... maybe we don't need anything special
... but we need to address all media and fragments in media
... bill and markus?

mgylling: I'm happy to take over the mumbling
... the core issue is that addressing a publication with a primary identifier should be transparent to online/offline status
... the mechanism has to be the same
... you touched upon it, it might not be that difficult
... let the online version be canonical
... so when a publication goes offline
... all it needs to do is carry with it that original url
... so incoming references can be dealt with
... in short, one can say
... either pub lives at url or it doesn't, but it has that URL as it's most basic identifier
... this wouldn't prevent at all the more luxurious things like DOI

Bill_Kasdorf: speaking as one who is participating in a sickening number of groups on identifiers
... i like this approach
... becasue it's identifier-agnostic
... if we try to mandate something, it won't fly
... book industry has a problem 'cause of no work identifier
... it simplifies whole thing
... express the url however you want, here's how you handle it when publication goes offline
... but use whatever identifier you want in the url
... the simplicity is powerful and practical

ivan: continuing what you said
... what you have here is an operational description
... an identifier points to something on the web
... if I make a GET request what I get is either a package or a specialized web manifest
... in a future architecture, when I get a package it will be handled by service workers
... so what's important is the manifest

<Bill_Kasdorf> Also +1 to web manifest

ivan: the internals of the package falls back to what is usual ...
... I don't know if the fragments per se need to be dealt with for publications
... we just need to deal with the various media types
... we should NOT define our own fragment identifiers

<Bill_Kasdorf> +1

ivan: what we should do is work out some examples of what happens in various situations
... and how the procedures, the http protocols work, when a publication is here or there
... and how it's done in internal vs external reference
... we should go through these exercises

shepazu: the notion of anchoring is taken up by web annotations WG
... with notion of rangefinder API; a fpwd will be published in next few weeks

tzviya: cool
... the idea of using any fragment id is nice and flexible, it loses some of the things we're striving for
... the degradation of URLs with citations
... if annotations support that we're good
... we want to make sure all the things we talked about in epubweb are supported

ivan: we need to work out some scenarios
... how would these things works, where are those devils who are in the details
... but we have a whole new charter to tell us how to do this :)

tzviya: any more comments?
... thanks everyone