See also: IRC log
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
... 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?
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
... 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
... designers just accept the current situation
jeff_xu: we need to involve more creators
... who work with css, vertical writing mode etc.
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
... 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
... 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?
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
... 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
... look of people involved in ebook development
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?
... not sure about details
... in that community
karen: what about annotations?
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
... 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: Tokyo international bookfair
<tzviya> London book fair, Frankfurt Book Fair
murakami: largest event in japan
murakami: then there is paige event, of the print industry assoication
<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
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: 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
... 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
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
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
... 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
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?
… 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
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
... 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
<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
... 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
... 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
... 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
... 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
... 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
... 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
... 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.
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
... 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
... 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
... 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
... 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.
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?
tzviya: Next up - wrap up and action items for the DPUB
... DPUB-ARIA will have a meeting this coming week and discuss publication of the draft
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