Meeting minutes
SMIL images
Susan Neuhaus: Hadrien Gardeur, do you want to tell us what is happening in this issue so far?
Hadrien Gardeur: Just a headsup that I opened another SMIL-related issue, not directly related but of interest
… SMIL for images is something we've discussed, I proposed this as I think it's a missing feature
… we lack the ability to reference an image or fragment of an image and link that to text or audio for that fragment
… and role, so we can identify the fragment
… I've shared examples, one from Bibliotheque Simon Roland(?), human recorded audio for the captions and speech bubbles of a comic
… they had to use the text element, wasn't ideal
… because they used text, they couldn't also provide the textual alternative
… audio equivalent of handwritten text
… it demonstrates what Brady might be concerned about, but if its possible today, it may not change things
… if they're doing it already today, it's as a way to make this work where there's a gap
… there is interest from other groups as well
… there is a paper published by a French university, where they generated a script for comics using computer vision, genAI, they can generate a description and extract the text
… create fragments, they generate text, then audio based on the text
… shows what more modern tools can do
… not everyone, there's huge interest from DAISY, and there's a technical conference after the DAISY meeting in June
… there's interest, but it's currently missing
… pointed out one way to do it, adding an existing SMIL feature to our subset
… discussion with Ivan Herman, do we put it in the spec and we're not sure if it gets adopted
… MO is not well supported across the board, but it could also be a missed opportunity
… where there are gaps, people will invent their own formats
… we could consider writing a note or just allowing EPUBCheck to not flag it
Hadrien Gardeur: there are many ways to do something about it, doing nothing would be a waste
Ivan Herman: I will also repeat a bit of what was discussed on the issue, I don't think it is worth spending our time on the technical value and usefulness
… as far as I'm concerned, this is a useful feature
… that's not a question, in my memory, Brady raised issues that are not necessarily technical problems, but what do we do with a feature that wasn't in the charter, which came in and we have no idea whether big publishers will be interested
… how will it distort the market?
Ivan Herman: This is what we need to discuss
… it's not about the technical value, it's an easy extension
… there's no disagreement there, the bigger question is the "market"
Brady Duga: To elaborate more on my concern, we have an existing ecosystem of children's books using SMIL, the way that wordflow works is taking an image-only book, add a text layer, get word by work highlighting
Brady Duga: If we add this, it's a new flow for generating children's books
… it's true you can make bad content, you can avoid putting text in the divs you're highlighting, there's a lot of features built into the text layer, it works.
… we're saying that by making this change you can just do images with attached audio
… most of the children's books aren't good for accessibility for other reasons
… my worry is we're saying you can do either audio or text, and someone comes to the spec and sees two options
… an author can come along and see "oh I can do this with images only", but platforms like Play Books won't support that
… we should at least be upfront about the new way of doing the books, is that something you want to see in this version
… I'm not disagreeing that this is a good feature, but we have a method, and an ecosystem built around that method, there could be an impact
<Susan Neuhaus> ack: Hadrien Gardeur
Hadrien Gardeur: Going back to Ivan Herman's question and Brady, we focus way too much on a few players, and the ecosystem is much bigger than just a few companies
… we have orgs moving off DAISY and going to EPUB with MO
… reflow files with MO, which isn't even supported in Apple Books.
… focusing on just a few players that don't do these things, and missing that there are players that are doing this work, and making these advances
… we are seeing passionate users building tools and platforms that support these new things
… instead of focusing on big players, should we also support the more specialized libraries, specialized use cases
Wendy Reid: We need to start having some discussions about who are we concerned with?
… there are more niche or smaller players in the EPub market that want advancement of the spec
… using web technologies. They do not have the same use cases
… that we have been focusing on. Because we are primarily focused on larger vendors
… most of the innovation is coming from smaller platforms and specialized libraries
… including regional use cases, like web comics
… we need to look more closely at these smaller players
… even if we don't expect the bigger players to adopt it quickly
… if there is a reading system, say in Sweden, that would benefit from this we should do it
<Ivan Herman> s/ack Wendy Reid//
Wendy Reid: to @Brady Duga 's point, we do need to reach out and create more best practices around it
ack: Matt Garrish
Matt Garrish: It's important to take everyone's concerns, my concern has been expressed by Ivan Herman and Brady, we might be squeezing this in right before CR
… yes it's part of SMIL, there's a number of details to work out, it's not that this doesn't have value, but is this the right time
… or is this a case where we do this through EPUBCheck and notes, so bigger players have a chance to voice this
… this wasn't in the charter, there was no "notice" of this change, everyone agrees this is good, are we doing it the right way
Hadrien Gardeur: I'd have to read the charter again, but I think we had accessibility and comics, so this might fit, the work on annotations is bigger than this
… I'm not advocating to push this in the spec, we can do a note, a future revision, as long as it doesn't get flagged in EPUBCheck
… it raises questions about how we handle revisions, we don't know if there will be a charter after this one
… the window for doing anything feels narrow, sometimes we know things in advance, and other times we talk to people and learn something bring those things back to the spec
<Ivan Herman> quoting from the charter: "Finally, the Working Group will also incubate issues without necessarily aiming at the creation of final Recommendations during the lifetime of this charter. "
Dale Rogers: I'm listening to this and it makes me wonder, what is the purpose of a spec? I guess it goes back to the charter
… I take it as we said we'd do this, and we're telling people "this is how you should do it" not that "you must do this"
Matt Garrish: Don't want to veer too far off course, when we do revisions, we need to be sure up front what we're doing. We should talk to people, but we need to do it more in advance, we need some guardrails
… we're already looking at doing horizontal reviews, but now we're looking at a significant change, we need a plan for these things
… it's not a critique of bringing this up, just that this always seems to happen and we try to accommodate where we want, but we need some organization in the future
Ivan Herman: Putting on my staff contact hat, I was looking at the charter, we do these things, but we also incubate things without necessarily committing them to the final version of the rec
… we gave ourselves an escape hatch
… I would personally, staff contact hat off, I'd be happy to add it with a warning, I agree it's not a major work, not like the layout issue
… we can put it in as at risk, it doesn't mean it has to be implemented, we use the remaining year to reach out to learn about the community's reaction to it
… if we get positive feedback, we leave it in, if we don't, we can remove it.
… that's do-able, we have the ability to roll back
Susan Neuhaus: People see the utility of this, concerns about process, whether this is in scope, the current proposal are to add this to the spec with a warning, removeable if needed, or just add a note and change EPUBCheck to allow this.
Ivan Herman: What I think is to produce a separate note describing this feature
Hadrien Gardeur: Correct, a separate document
Ivan Herman: If the feedback from the community comes out negative, we can remove from the spec and create a note, so it doesn't disappear
Hadrien Gardeur: This sounds like a good process to me
Proposed: We will add SMIL in images to EPUB 3,4 spec as at risk, and then move it to a note if it comes out of the final spec?
<Wendy Reid> +1
<Susan Neuhaus> +1
<Hadrien Gardeur> +1
<Grigorily Manucharian> +1
<Toshiaki Koike> +1
<Gautier Chomel_> +1
<Dale Rogers> +1
<Shinya Takami> 0
<Brady Duga> 0
<Masakazu Kitahara> +1
<Ivan Herman> +
<Abe Jellinek> +1
<Ivan Herman> +1
RESOLUTION: We will add SMIL in images to EPUB 3,4 spec as at risk, and then move it to a note if it comes out of the final spec
Ivan Herman: No good thing goes unpunished, it would be good if you produced the PR to add this into the document
Hadrien Gardeur: Each element has its own subsection, so one for images?
Ivan Herman: Yes, and we'll support editorially
Brady Duga: And the RS spec for behaviour
Hadrien Gardeur: I'll look it up and figure out where things need to go
Closing issues
https://
Susan Neuhaus: We wanted to discuss some issues to propose closing
Matt Garrish: Ivan Herman marked these as propose closing, I just created the link
w3c/epub-specs#2879
Susan Neuhaus: One is an issue on the section on encryption files being too brief
… does anyone want to keep this issue open?
Matt Garrish: Do we need a recap? Briefly, it was questioned about the XML encryption standard is much bigger, does everything apply or should we provide a subset, I don't think it's critical for us to define something
… Ivan Herman and I discussed this with the original requester, no one has raised this as an issue. If people are encrypting, it's the vendor and they know what they are doing
… I don't think it's worth us wading into
Ivan Herman: I would even say it more strongly, we don't have the knowledge or experience or contact to relevant communities to comment on encryption, so we should not touch it
Shinya Takami: In Japan, each reading system has its own DRM for encryption, so we shouldn't define anything
w3c/epub-specs#2828
Susan Neuhaus: Clarifying multiple renditions, can anyone summarize that one?
Ivan Herman: An evergreen, always there issue
… let's put it this way, we've decided to push it aside as a note, there's been no new evidence that requires us to take another look at it
<Gautier Chomel_> +1
Matt Garrish: We took it out as not implemented, this is a request to pull it back in, but there is no desire to have multiple renditions in this form, we can move on
Gautier Chomel_: I don't disagree, I did want to mention that the problem of having two contents that are similar and need to be displayed together, the problem is still here, but multiple renditions is not the way
… educational publishers are trying to do this in strange ways, the documentation doesn't have information on how to handle this case, but it needs to be investigated further
… I agree we can close this, but I would like to see a discussion on parallel content being taken seriously
Ivan Herman: At this moment, this is typically the kind of issue that should be done as incubation, as part of the CG, it's look at the whole problem again, knowing that multiple rendition didn't work, understanding why, taking a fresh look
… it's not something the WG is chartered for, the CG can explore and raise it in a future charter
… and I want to see this happen, but we need that incubation
Hadrien Gardeur: I agree with Ivan Herman, this needs incubation, I would like to look into it, but I'm lacking in time, I'm already opening issues for fun. I think it's possible with what is in the spec but underused
… I don't know how much would need to come from multiple renditions, but it's probably possible to use things that have been previously under-utilized to achieve what we want
… it means no addition to the spec, but things that haven't been used or implemented properly
… not sure how to feel about it. Incubation is the right term, even if it doesn't result in normative changes
Susan Neuhaus: This is not the place to look at this issue now, we want to refer it back to the community group
… would our next move be to tell the original poster, and ask if they want to present it to the community group
… just closing it doesn't reflect our feelings on it
Ivan Herman: The minutes will tell, but we can also add an additional comment on incubation
… I can do that before closing
Gautier Chomel_: I think it's been back and forth between the groups, the reality is that there hasn't been a response, a player will do it themselves, so they don't care about standardization
… brings me to the question at the beginning of the meeting, what is possible in the charter
… I'm concerned about too many things not being considered, so they do it on their own
Wendy Reid: I am also concerned, we hear about these things
… the people who need this feature aren't coming to us
… we would love it if they came to us with a use case, and a problem
… we get posts with new ideas, but not use cases
… we don't want people going off and doing their own thing
… but we don't always get to hear about what people want to do
… if people have things they want they can reach out to us anytime
… we do sometimes rush things at the end because something comes up
… and we want to be seen as responsive
Hadrien Gardeur: We kind of underestimate how intimidating it is to interact with us, not that we are scary, but the idea of influencing a specification inspires fear, and we encourage people and they are nervous
… it's not easy to get feedback
Hadrien Gardeur: I keep an eye on things, and I make the case to people, and our efforts have changed minds in the community
… it takes a lot of work
… maybe we need to do more community outreach, but changing people's minds is difficult
… they can't imagine they have the technical capability to change any of this
Matt Garrish: There's great value to incubation, we don't spend time on it as much as we should, we should engage more earlier. In IDPF, the most successful extension was FXL, but many of the other specs never went anywhere, if we don't have a foundation before implementing it fails
… I think this is why people go off too, it feels like things are set in stone in the standard when we are really open to revision, but we also need to get an idea of what is wanted before we get there is much more helpful
Matt Garrish +1
Matt Garrish: having implementation before we add to the spec instead of trying to get adoption
Ivan Herman: Along the same lines as Matt, when IDPF merged with W3C, we formed the BG, CG, and WG, the idea that the BG would collect and react on business needs, the CG would incubate, and the WG comes in when the ideas are clear and can be implemented
… they can dot the i's and cross the t's. This is what happened with roll, I don't remember when we began to discuss, but it took place over a long time.
… the multiple renditions stuff has been whispered about, we have gotten feedback, but we hear "just figure it out" and that's not what we do
… we've had many examples of WGs did all the technical work on rough ideas, and the standard then didn't go anywhere, IDPF did the same, that's why we talk about incubation
Susan Neuhaus: Close this issue, start a discussion about process
Gautier Chomel_: Close the issue, and discussion about parallel content needs to be moved to the CG.