See also: IRC log
<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
<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
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
<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
<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
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