Meeting minutes
Overview of TPAC
wendyreid: we had really good sessions on annotations and a lot of the ground work is done so now we need to start a draft proposal
… expect to see that in the next few weeks
… a lot of time was spent on fixed layouts and comics
… made good progress on what to do with the problematic rendition fxl properties
… we are not going to add the html syntax - I am working on a blog post on this
… we're still working on what to do about submissions to iso
… got an update on Japanese publishing
… we have some info on the iso transition but the issue is the european commission and iso coordination
ivan: I had some disagreement about submission at the meeting but it seems that iso requires a document to be done as iso
… the wcag group tried to convince them that this is not useful to do for wcag and iso accepted it
… iso accepted their argument and wcag was submitted
… I have asked for the argument on how to make this case for epub
ivan: we also discussed images in the spine at tpac
wendyreid: we intend to leave the spec requirements for this as they are
Parallel Content - https://github.com/w3c/epub-specs/discussions/2829
wendyreid: https://github.com/w3c/epub-specs/issues/2670, https://github.com/w3c/epub-specs/issues/2825, https://github.com/w3c/epub-specs/issues/2773, https://github.com/w3c/epub-specs/issues/2806
wendyreid: we've had use cases for multiple versions of the content and tried to solve with multiple renditions
… parallel content is where there are two or more parts that appear in conjunction with each other
… content in translation is an example where you might have a poem in two different languages on facing pages so you can review each line in each language
… it also comes up in accessibility issues
gautierchomel: currently there are different problematics like translated content, fixed and reflow, audio and text
<wendyreid> https://
gautierchomel: up until now there have been separate discussions and proposals for each but we should try to find one way for all
… I don't have a preferred option for how to address this technically
ivan: it is an important use case and multiple renditions covers at least some of it
… we don't have a technical solution yet so this group probably can't do it - it likely needs to be incubated in the community group
… I expect the solution will be complicated and needs incubation to figure out what will work
Hadrien: multiple renditions does have a mapping document to jump between the renditions - it's a lot like a navigation document
… we need to be careful not to force everything together if they don't work well together
… I think if we modify multiple renditions we could do some interesting use cases like magazines with fixed and reflowable layouts
… we shouldn't reject all of multiple renditions but I agree we do need to look into it more
… the way multiple renditions was defined was not ideal
wendyreid: I agree we need incubation - we have bits and pieces of what we need
… if I'm reading a book where one page is one language and another in another language you wouldn't want two separate documents but we don't have multiple reading orders
… same is true for audio where the transcript might be in the same file
… but reflow and fxl probably are always going to require separate documents
Hadrien: I think another option for multiple reading orders than multiple renditions and all it entails - a separate publication - we also have collections for alternate reading order
… we wouldn't need to introduce anything new - is worth exploring
<MURATA> Unfortunately, multiple renditions were never really used. Right?
Hadrien: I had this in mind at tpac but we didn't have time to discuss - once we're done with comics I'd like to explore it
… we should consider a task force since we're in a revision cycle right now
ivan: I have practical problems, namely whatever we do if we want to put it in the epub standard we need two implementations
… I get that it's not multiple renditions and it has not been picked up - that's why we took it out and made it a note
<MURATA> If my memory is correct, I think that it is too difficult to use multiple publication documents per zip file.
ivan: I'm worried about putting something into the standard again before we know that there will be adoption
wendyreid: if we are to undertake this a big question is what stopped adoption of multiple renditions - there are some implementations but they are really platform base
… I have a feeling I know why - people didn't know what to do with what we gave them
Hadrien: what if we create a task force that does not attempt to introduce new things in the spec
… based on the result of that task force we see whether there is any interest and then decide where to go
… if that fails then we can move it over to the CG to look into further
gpellegrino: we shouldn't work in the past but whether it is needed now - EAA is requiring publishers to now produce both fxl and reflow in the same package
shiestyle: I wonder if there is enough interest or demand for this - I think it needs more incubation
ivan: the working group is getting thin and we have existing task forces with a lot of work to do - we should be getting to CR within half a year - so I'm worried about this taking more time away from the revision
Hadrien: there is demand for textbooks and it is common for magazines - they are lacking the format to do it
… there is scale now that didn't exist when we did multiple renditions
… the interest is specialized though
… and I agree with Ivan that we shouldn't do too many things at the same time - there is still work for comics but not as much as for annotations
… I can't see doing both in parallel but if we can close comics soon and we get interest in this from other participants then we should at least explore what we can do
<ivan> +1 to Hadrien
Hadrien: and if we can't add anything to the spec than it still leaves people with some ideas to work on
gautierchomel: scholarly publishing does do multiple renditions but in a closed environment - they need to provide interoperable content
… I understand the time and resource issues but this problem has been around for a long time and should be a priority to finally address
… other solutions are being implemented and it makes it harder to standardize
wendyreid: we need to do some outreach to find out who is interested before we get to a task force
… it's easy to start a task force but we don't want to find out later that the work won't be implemented
gautierchomel: I think it would be good to have this in the CG because we have more people with interest in this area
<AvneeshSingh> +1, anyone can join CG
Hadrien: we also have interest in EDRLab but they are not represented in this group
wendyreid: for a next step we should start the conversation in the CG
… nothing stops us from promoting the work into the WG later
… doesn't require more work from this group to get it started
gautierchomel: I can try by mid-January to have a call in the CG to start a task force
Scheduling - https://github.com/w3c/epub-specs/discussions/2834
wendyreid: only other thing is meeting scheduling
wendyreid: I've already seen some responses, but we had a question about our meeting scheduling because our one time slot is not ideal for the west coast of US, too early, or too late for those in Japan
… wanted to find out if we could go back to a rotating schedule
… no interest so far in starting even earlier but nothing negative about a rotating meeting time
ivan: I've done the rotating schedule here and in other groups and it never works well - it divides the community
… it's always been abandoned after a while
AvneeshSingh: do we have enough agenda items to fill up four or five meetings a month or should we consider dropping the schedule from every week
wendyreid: if you haven't had a chance to respond please think about it and add a comment
test suite changes - w3c/epub-tests#309
ivan: I made some changes to the test suite after the tpac meeting because we deprecated a property
… (I still need a full list of what we'll deprecated, as an aside)
… there is a pull request for the tests to separate the tests that are deprecated - new labelling like required vs. recommended
… the other thing is more controversial - if someone currently creates a test they are expected to create a new zipped epub file
… this forces the tester to test the book they've created
… but this has become a pain when you need to go back and make minor changes to existing tests
… the PR adds a github action to auto-generate all the epubs
… is this okay or should we keep people generating the epubs manually?
Hadrien: I will get back to you soon about the other properties to deprecate
gautierchomel: if all the epub files are updated then you lose some information about when they were last changed
ivan: yes, but the metadata in the epub file will still be the same about the last modification date
gautierchomel: might be a problem for sorting, but not sure how big
ivan: for reporting the date of the packaged epub is not used
… only the unpacked files are used
wendyreid: the last modification date only changes if you actually modify the test
ivan: if you have a lot of tests to work on then generating each one becomes a pain to do
… I considered adding epubcheck validation but I'm not sure how to do that
gautierchomel: I can send you an example of how to call it into your workflow
wendyreid: could have epubcheck as an action
ivan: but a lot of tests that epubcheck would have to be started up and run on
… is it okay if I merge as it is now?
wendyreid: yes
gautierchomel: yes
Ways to identify inferred metadata - w3c/epub-specs/discussions/2830
<wendyreid> w3c/
gautierchomel: I have questions about ways to infer metadata
… people are starting to update their epubs and that comes with a lot of AI generated content
gautierchomel: if we cannot differentiate what has been auto-answered it will become problematic
Hadrien: I raised this during tpac - there could be legal reasons for identifying what is AI generated
… might not be in our scope to do this for html
… if there is work going on in this area it would be helpful to know where
ivan: w3c is still trying to find out what can be done about AI - there is a new interest group but not answer at this time
… even if we are talking metadata this is not just an epub issue
… coming up with our own metadata in isolation is not a good idea
wendyreid: we might be overthinking the question - this is only epub metadata and what is generated automatically
<Hadrien> https://
wendyreid: how can you tell if a book contains AI-generated metadata
… could we use something like the refines attribute to make statements about resources
… all we are doing is putting an asterisk on resouce essentially
Hadrien: I think ivan's point still stands that we don't have the metadata to say anything - we're lacking the vocabulary and it's not in our scope to define that
… could be schema.org or dublin core or someone else to define the metadata
wendyreid: if I have a million epubs in my database and some are quite old and I want to add accessibility metadata then I can try to infer things like whether they support some textual reading
… but there should be a way to say that this metadata was automated so it is not compeletely trustworthy
gautierchomel: the problem is bigger, but yes, that is what we need to capture first