Meeting minutes
SMIL TF?
wendyreid: Should there be a SMIL taskforce?
… SMIL needs attention but might need some room to breathe
Hadrien: since I made most of the issues, should I lead the task force?
wendyreid: we can invite members of the community group
… in this matter, there are people outside the group who have been implementing SMIL for years
Hadrien: I am OK to do this, we need to fix the spec, we cannot do what is currently in the spec
… how many people from this group would want to join?
… would we have good discussions on regular calls?
GeorgeK: What is the goal? Do we want to modify it and bring it forward?
… would we be updating the whole specification? or make a subset of SMIL?
ivan: I know we are not allowed to touch the original SMIL spec
… another group should be chartered to do that
… the SMIL spec we are referring to is a subset of the big SMIL set
… that is part of EPUB. We can change the subset
… I didn't see anything in what Hadrien said that would require changing the SMIL spec
Hadrien: like what @ivan said, our issues are more about how we use SMIL
… and not the specification itself
… the cross-resources issue might be an exception
… where text goes across the left/right of a spread or through a roll publication
… we should be fine not changing SMIL
wendyreid: If we don't have to change SMIL, it is just about EPUB
GeorgeK: Can we add video to what is in the [par?]
ivan: the original spec had a video element
Hadrien: and we have a PR for adding image support
… who in this group would like to participate in the TF?
LaurentLM: I would. I deal more with desktop Thorium, while Hadrien deals with mobile
… Hadrien is now discovering things we didn't work on with the desktop implementation
wendyreid: We may have to send out an email since some of the folks who might be interested are not here
duga: I don't see Google or Apple here, it would be interesting to reach out to them to participate
Hadrien: Outside of this group, people might be interested but may not have time to contribute
… we have the lead developer of Storyteller, who has experience with production and reading systems
… specialized libraries will have an interest in this topic
… there might be people in DAISY who are interested in this topic
… and people on larger platforms who are following our discussions
duga: If we don't form a joint task for with the working group, we guarantee that most of those people won't be involved.
… since they will have to join the community group
… it might be nice to get some new blood
ivan: at this point, a task force in the community group would be easy to set up
… it is a good workflow to have the community group incubate the ideas and then pass them to us
… we have enough people in this WG to complete the standards update
… we might end up with a whole series of invited experts and that could cause problems
… gautier has said he cannot join us because of schedule conflict
… this is a discussion we should have with him because he is co chair of the CG
Hadrien: some of this work is very central to the spec.
… some of these issues are not raising new features, but changing the spec
ivan: the CG is completely free to choose its own work
Hadrien: do we imagine the CG would create PRs?
ivan: the CG would develop work that should be put in the PR by someone who is also in this group
Hadrien: some of the issues have lots of dicussion, and people may not feel the need for more discussion.
… like text fragments. The people involved are ready to move to PR
… I should be the one to set up the PR
ivan: that is no problem because you are a member of the Working Group
wendyreid: We've made progress. It doesn't have to be a formal task force and it can run asynchronisly
Hadrien: I might just ask people to put things in writing on GitHub
F2F at TPAC?
wendyreid: and that's fine
<Hadrien> +1 for having a F2F meeting in Dublin
wendyreid: TPAC is in Dublin, easy for the European and East coast members, not so much for Asian and West coast members
ivan: the TPAC is the 26th of October
<ivan> +1 for a f2f
wendyreid: I'll keep an eye out for further information after the AC meeting
@ivan: @hadrien that did come up
wendyreid: maybe we can have a virtual face to face?
… I'm not sure any of us have the energy to plan a face to face before October
wendyreid: I
… I'll keep an eye out for when to ask for time at TPAC
Use JSON-LD keywords for language and direction - w3c/epub-specs#2950
<ivan> w3c/
wendyreid: ivan, can you explain this topic?
ivan: we have to talk about language and language direction in strings in annotations
<LaurentLM> link to the body language and textDirection: https://
ivan: the current draft has a field for text direction that has two problems.
… it is only for the body and doesn't solve other text, like titles and descriptions
… json LD now has a built-in feature to set language and direction
… my original issue is that we should use what we get in jsonLD
… and not duplicate things. It would solve the missing setting for other natural language text fields
… I've defined the solution and written a PR that we use JSON LD
… I described part of the JSON LD that are usable in my view in annotaitons
… i dont want to go into detail in the syntax
… if we set another block we can use JSON LD to set the language and direction
… it would then apply to everything in the tree underneath
… you can still have local overrides
… two open questions that need a decision
… there is a way in the JSON LD syntax to set the language and direction in a single text field
… which uses a different syntax and can be confusing
… we may not have to specify values for single strings
… I don't think we need to add this to the spec
… I would like some feedback on this
… is it a must to add language and direction?
… or is it a should? We should do the same for the annotations spec
… this has a slight effect on the vocabulary so we should make a decision
mgarrish: we don't have a requirement in the package document, but it is required for accessibility
… setting the language of the publication is required, but not setting the language of the HTML
ivan: in the pacakge doc, if we say it is a must to specify the DC language, the we should do the same for the annotations spec
LaurentLM: web annotations are based on JSON LD
… programmers work with JSON not JSON LD
… to go too far with JSON LD is dangerous for developers
… using language direction is a small improvement for annotaitons
… I would like to see that use case for adding language and language direction before we implement this
… we had this same discussion with web publications. The outcome was to
… web publication spec can give us some continuity
<LaurentLM> Readium Web Publications: https://
LaurentLM: readium web publications have chosen another path
… if you want multiple languages you use the language code, language is mapping to JSON LD
<LaurentLM> W3C WEb Publications: https://
LaurentLM: this seems easier to master than the example in the web publication W3C spec
ivan: I realized while doing this, that what we have in web publications is buggy
… you cannot use the alias within the context
LaurentLM: having the abilty specify language locally is important
… to have it at the top, and setting the direction, at the top makes sense
ivan: it is clear that we cannot use language and direction in the body that the way it is now
… it is not now the JSON LD specification, you cannot specify the language and have it be recognized
… the mapping you have in Readium is valid JSON LD and can be used
… but since it doesn't handle direction we might have problems with internationalization
… we rarely have a case where we want to express the same thing with 3 different languages
sueneu: Use cases are rare where you want to say things in different languages
… but I do this all the time
ivan: In general that is true, but the question is does this happen in annotations
sueneu: Absolutely. This could be very helpful
… you could have English annotations
ivan: that is not really what we are talking about. We need to specify the language you made the annotation in
@laurentLM it looks like this needs more discussion
@gman: I think there is a use case here, which could be annotation of a translation and discussion that could take place in two languages
wendyreid: this could be more about the accessiblity issue where if the language isn't marked up properly screen readers can lead to some interesting publications
… in theory, I could add a word in a second language within an annotation
ivan: which leads us to the discussion of HTML in annotations
… if we can use markdown in the body, like the markdown in github
… that does allow some HTML, so you could manually set a span with the correct language tag, it would cover that issue
… if we really what to mix the language inside the body, we could use multiple bodies
duga: Github technically doesn't support HTML but doesn't strip them out
… so it displays correctly in a browser
… I don't know if there is a version of Markdown that allows Ruby
… I'm not even sure markdown will make it through rec
@ivan: for those issues, we will have face an international review,
… if we cannot set the language and direction in the right place, we will not get the sign off
wendyreid: Let's leave it at that, we have more to do on the language question
… otherwise, thank you everyone for a great meeting. See you all next week