Re: [Minutes] PMWG 2025-05-08

This discussion helps defining questions to ask to reading system
developers. Reading systems are certainly the hardest part of the chain for
 managing evolutions because they are so many and they have historically
not been the part the IDPF was considering most (RS guidelines are a new
thing).

The real issue is about « old » RS, badly written and quasi unmaintained,
which won’t look at any flag we may specify (mime type or dc:format). And
the issue is not only for html support, but for any evolution where
graceful degradation is not historically supported by all (?) RS.

Either we consider that some of them are obsolete and cannot pretend
supporting EPUB3 anymore, or EPUB3 is frozen, apart from cosmetic
additions.

L

Le sam. 10 mai 2025 à 13:23, <matt.garrish@gmail.com> a écrit :

> I’d argue that adding html is much more fundamental than the changes
> you’ve cited, which is why it may need special attention. There’s no
> graceful degradation for an html epub except to reproduce everything in
> html in xhtml, which defeats the purpose of using the other syntax. We
> don’t want epub to become the carnival show of content where you get to
> step right up and see if anything displays at all after giving away your
> money.
>
>
>
> It strikes me as a kind of reversal of previous discussions we’ve had
> about profiling reading systems so that users can figure out the
> capabilities. But that’s shifting a technical burden onto users that they
> don’t want to know or care about. The vast majority of users have no idea
> what an epub is under the hood and probably little more knowledge of what
> their reading system supports. Telling them they’re about to download an
> “EPUB 3+” will probably grab more attention, as Eric says, than listing
> what the publication needs for support when you go to purchase, or having
> to warn about all the features that probably won’t work before they can
> fully experience the book.
>
>
>
> But I promised not to argue, and this is an issue we probably shouldn’t
> try to solve at this stage, and not by email. It would be good if we can
> get this logged in the issue tracker so it stays on the radar.
>
>
>
> Matt
>
>
>
> *From:* Ivan Herman <ivan@w3.org>
> *Sent:* May 10, 2025 2:49 AM
> *To:* Matt Garrish <matt.garrish@gmail.com>
> *Cc:* Laurent Le Meur <laurent.lemeur@edrlab.org>; W3C PM Working Group <
> public-pm-wg@w3.org>; Eric Hellman <eric@hellman.net>
> *Subject:* Re: [Minutes] PMWG 2025-05-08
>
>
>
> Looking at the thread, isn't it correct that the same set of arguments may
> be valid for any technical additions to EPUB 3.3? Say, if we reinforce the
> usage of WebVTT, add new features for Webtoons, or add heic as a valid
> image format? We are concentrating on HTML here, but it is not in a unique
> situation (though probably the most prominent). In other words, any
> technical addition to EPUB 3.3 might end up at the same place.
>
>
>
> Ideally, we would communicate the changes with the official version
> number, but that we cannot. Calling this EPUB 4 might be disastrous as
> well, insofar as no publishers would even look at it (that was the
> discussion we had on the version numbering which led to the restriction in
> the charter). That is a dead end.
>
>
>
> I jump on the idea of Matt about the usage of dc:format (or equivalent) in
> the package document, which I like. dc:format[1] is fairly open, in the
> sense that it can also be string. What if we define some sort of
> mini-syntax for that value, which lists some "features" with pre-defined
> names? Authors MAY list the extra features they use in a publication;
> reading systems may look at this, and they may warn the reader if the
> publication relies on a feature they do not implement. Such a property may
> also be useful for older, but less implemented features of EPUB 3.3 (e.g.,
> whether javascript may be used in a publication or not).
>
>
>
> Ivan
>
>
>
>
>
> [1]
> https://www.dublincore.org/resources/userguide/publishing_metadata/#dc:format
>
>
>
>
>
> On 10 May 2025, at 01:13, matt.garrish@gmail.com wrote:
>
>
>
> > If not, I see no possible warning as long as we keep package/@version =
> a static "3.0".
>
>
>
> For reading systems with no awareness of the changes and for users that
> have obtained the publication without it being identified as not your
> regular EPUB 3, sure. A new version is the only universal way that a
> reading system will know it can’t handle what it’s getting.
>
>
>
> But we’re not necessarily out of options for flagging the content for
> distributors or reading systems simply because the version has to stay the
> same. Like I mentioned earlier, we could require dc:format with a
> designator for html-containing publications. Epubcheck would easily be able
> to check the media types and ensure the flag is set, for example.
>
>
>
> We could also add a new attribute to the package element to flag these
> publications. That might be a bit more controversial approach, but it seems
> unlikely that a new attribute will cause any issue processing package
> documents (we had similar worries about adding the collection element and
> it went ignored by everyone with no use for it, which was kind of everyone
> in the end sadly).
>
>
>
> Anyway, that’s just a couple of quick ideas that came to mind. There may
> be other ways of handling it, too, like in the container.xml file. But this
> is useful to consider more if we go ahead with the change.
>
>
>
> Matt
>
>
>
> *From:* Laurent Le Meur <laurent.lemeur@edrlab.org>
> *Sent:* May 9, 2025 1:44 PM
> *To:* W3C PM Working Group <public-pm-wg@w3.org>
> *Cc:* matt.garrish@gmail.com; Eric Hellman <eric@hellman.net>
> *Subject:* Re: [Minutes] PMWG 2025-05-08
>
>
>
> HI,
>
>
>
> I understand what Eric means. Without a strong flag in the "pure HTML"
> EPUBs (especially if not well-formed), some (many?) reading systems will
> open such a publication but will display it badly.
>
>
>
> A good question is: Do EPUB reading systems in the wild test the OPF
> package/manifest/item/@media-type before accepting a publication? If yes,
> the presence of "application/html" will be a strong warning that there is
> something special here. If not, I see no possible warning as long as we
> keep package/@version = a static "3.0".
>
>
>
> Laurent
>
>
>
>
>
>
> Le 9 mai 2025 à 19:28, Eric Hellman <eric@hellman.net> a écrit :
>
>
>
> More the former rather than the latter, but mostly I'm arguing for a new
> label. Sometimes an author comes up with a great title first, and the story
> then just writes itself.
>
>
>
>
>
>
> On May 9, 2025, at 1:16 PM, <matt.garrish@gmail.com> <
> matt.garrish@gmail.com> wrote:
>
>
>
> Sure, that’s a fair point. I’d prefer to hear everyone’s opinions on this
> so I don’t think it’s productive to argue for or against any of the
> feedback we get. I was just curious from that comment if there was a
> technical solution within EPUB 3 that you envisaged so that users could be
> alerted to the type of EPUB 3 publication that they were getting or if you
> are arguing for a brand new format of EPUB.
>
>
>
> Matt
>
>
>
> *From:* Eric Hellman <eric@hellman.net>
> *Sent:* May 9, 2025 11:58 AM
> *To:* matt.garrish@gmail.com
> *Cc:* Ivan Herman <ivan@w3.org>; W3C PM Working Group <public-pm-wg@w3.org
> >
> *Subject:* Re: [Minutes] PMWG 2025-05-08
>
>
>
> I'm asking for more consideration of end users who would have no way of
> knowing whether EPUB3 files will work on the reading systems they use.
> These are not people who do not know what XML syntax is!
>
>
>
> I would love that have an EPUBish format that packaged HTML files. but
> dont give it a label that creates angry end users!
>
>
>
>
>
> On May 9, 2025, at 10:35 AM, <matt.garrish@gmail.com> <
> matt.garrish@gmail.com> wrote:
>
>
>
> 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> 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
>
>
>
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> mobile: +33 6 52 46 00 43
>
>
>