RE: [Minutes] PMWG 2025-05-08

Hi Eric,

 

> By contrast, a distinguishing label like  "EPUB+" for even this
technically modest change would encourage adoption by reading systems
developers, and by their customers.

 

Could you clarify what you mean by this? EPUB 3 is a continuous line with
all files being identified by version="3.0" in the package document. There
would be no reliable way to differentiate an "EPUB 3.3" file from an "EPUB
3.4" if they both use the XML syntax.

 

Are you asking for a version number change to make an "EPUB+", which would
put this out of scope for this revision, or are you just wanting us to find
a way to differentiate EPUB 3 files with the HTML syntax from EPUB 3 files
with the XML syntax without changing the version? (I think the latter could
be done, for example, using a dc:format tag with a required identifier.)

 

Matt

 

From: Eric Hellman <eric@hellman.net> 
Sent: May 9, 2025 10:08 AM
To: Ivan Herman <ivan@w3.org>
Cc: W3C PM Working Group <public-pm-wg@w3.org>
Subject: Re: [Minutes] PMWG 2025-05-08

 

I'd like to comment on allowing html syntax in EPUB 3.4.

 

While I understand the technical reasons behind the change, and agree with
them for the most part, allowing html syntax in EPUB 3.* would be a terrible
marketing decision. Because of this, Project Gutenberg would not implement
3.4 and I would counsel other organizations I advise not to implement any
support for it. We have touted our implementation of EPUB3 for over 75,000
titles despite its inconsitent implementation in reading systems. When
something doesn't work it causes support issues for us. We continue to
produce EPUB2 files because certain strongly desired functionalities don't
work in systems that claim to support EPUB3. (I'm looking at you, ADE.) It's
clear that there will be reading systems that just won't work with HTML
syntax, and users of those systems will have no way to know if the files
they acquire will work with the systems they use. Even if we were to produce
EPUB 3.4 files with XML syntax, we would struggle to communicate that to a
user who has experienced failures with other EPUB3 files. Those failures
would be black marks against the EPUB label or "brand".

 

Has anyone articulated a benefit to end users for this change?

 

By contrast, a distinguishing label like  "EPUB+" for even this technically
modest change would encourage adoption by reading systems developers, and by
their customers. For distributors like us, it would allow us to easily
communicate a modernization step without a lot of work on the backend.

 

 

Eric Hellman
President, Free Ebook Foundation

http://ebookfoundation.org

https://bsky.app/profile/gluejar.com

 

 





On May 8, 2025, at 10:20 AM, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org> >
wrote:

 

Minutes are here:

 

  https://w3c.github.io/pm-wg/minutes/2025-05-08.html

 

Ivan


----
Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43