Epub-specs: Question of version numbering: 3.0.2 versus 3.1.1

[RachelComerford]

The conversation thus far has been:

@murata2makoto: The EPUB 3.0.2 draft created by Dave is derived from 3.1 but intended to be backward compatible with 3.0.1. I think that we should admit our serious mistake. I think that the version number "3.1.1" hides the mistake and that "3.0.2" makes the mistake clear.

@mattgarrish: I don't disagree, and I don't see how any revision can avoid explaining the details of what it does. But I think we're compounding the mistake by trying to go back in time to patch into the 3.0.x line. As you say, 3.1 exists. The epub community all know about it. So let's fix it instead of trying to hide it away as a "do not use" specification. Trying to splice ourselves back into 3.0.x and hope people forget about 3.1 feels like no less of a dodge of responsibility.
If we could scrub 3.1 from existence, that would make 3.0.2 less problematic, but it seems unlikely given that it was a formally adopted specification of the IDPF.

And as @dauwhe has pointed out, what happens if we do need a major revision to add features, do we jump from 3.0.x to 3.2 because 3.1 is left in an unimplemented state? How awful would that be?

But that's my only bone of contention with this proposal, and I know you and Garth have a different opinion.

@murata2makoto: I think that abandoning XHTML2 and XML1.1 was a good decision. Sticking to them would have caused more problems. We should do the same thing. EPUB 3.1 is known and recognized as a failure. Sticking to it makes people doubt Publishing@W3C seriously.

I do not believe that we will create a major revision of 3.0.2 since the Publishing WG is doing something entirely different. I think your point here is purely theoretical.

@mattgarrish : Neither is a fair comparison, but there are lessons to learn. XHTML2 was abandoned before it was finished, so no one questions its status. XML 1.1 is a recommendation, and a source of confusion to this day. EPUB 3.1 is going to be much more like XML 1.1 than XHTML2.

What I'd rather hear than conjecture on who might think what about what, is what we can do to mitigate the problems of 3.1's existence if it's kept around in parallel. Hoping people forget about it does everyone a disservice.

@murata2makoto : I am quite sure that ISO/IEC does not care the version number. This is because ISO/IEC often has versions slightly older than the latest. I also think that we should tell the EPUB world not to use EPUB 3.1.

@mattgarrish: True, I agree with you on this, and 3.1 was far more of a subtractive revision than an additive one. It was trying to impose some measure of reality back on EPUB for past mistakes.

3.1 has problematic aspects, and is divisive. Let's leave it at that and look at how we can do better. We're underestimating the response to 3.0.2 if we think it's going to be widely loved, too.

That's why I also wonder if we can try to find a softer landing place than a wholesale dump of 3.0 features back into production. If there were a 3.0.2/3.1.1/3.2 "strict" profile, for example, that validates like 3.1 would have, that might be one way to avoid future divisions. I'm not sure what the best way to do that is, though.

@murata2makoto Makoto: Since 3.1 is merely a W3C member submission, it has no official status and thus cannot be withdrawn. But the EPUB CG and the Publishing Business Group might want to say that 3.1 should not be used. In ISO, I hope to see EPUB 3.0.2 as a collection of International Standards.

version number EPUB 3.1.X will invite skepticism from Japan. EPUB 3.0.2 has already received a number of hoorays from Japanese users.

[GarthConboy]

Note "3.0" version and rationale from original proposal.

Also relation to potential semantic versioning here.

[dauwhe]

I feel strongly that any revision of EPUB 3.1 should be called EPUB 3.1.1. EPUB 3.1 is a fact. It was approved by the IDPF membership, is a formal IDPF recommended specification, and exists as a member submission to W3C. Those things cannot be undone.

Describing this work as 3.1.1 is better from the point of view of the community group charter. It avoids confusion today. It avoids future confusion over what might come after 3.0.2. And it accurately describes what we're attempting to do—fix a few issues with 3.1 that influence backward compatibility.

More technically, any reasonable attempt to create what was outlined in the google doc requires that we use 3.1 as a starting point, and edit that. No one wants to go back to 3.0.1 and try to reorganize, clarify the language, completely replace the sections on HTML and CSS, etc.

EPUB 3.1 did many good things—the spec is much easier to understand. We made significant gains with web compatibility by adopting the new approach to HTML and CSS. We made a valiant attempt to remove features from EPUB which were not being used in the wild. Let's fix what we need to fix, but without the drama and confusion of "repudiating" a version and changing the direction of time :)

[laudrain]

Keeping 3.1 as version number may still be the first incompatibility with 3.0.x.
I agree we did good things in EPUB 3.1, but I don't see an issue to bring as much as possible of this work back in a 3.0.2 version, fully compatible with 3.0.1.

[dauwhe]

Luc, I'm talking about the spec version number, which is independent of the version attribute of the package file. I believe we have consensus to change the latter to 3.0, regardless of what the spec is called.

[GarthConboy]

Quoting me from another thread: "I, for many of the reasons Makoto stated, think 3.0.2 is a better (and more appropriate) moniker. But, as long as the package version reverts, and the changes (likely close to what's been proposed) get made and we're able to move pretty expeditiously, I'm not going to die on the hill of 3.0.2 versus 3.1.1. I view either version name as an edit of 3.1. "

3.0.2 implies backward compatibility with 3.0.1, which I do think is substantively important.

Also, while this is certainly an entertaining point of discussion... it's also clearly a bridge that can be burned later. :-)

[murata2makoto]

I am not going to repeat what I have already written before. But if there were no language barrier, there would have been a lot of strong supporters of "3.0.2" from Japan.

[llemeurfr]

In #984 we define backward(s) compatibility. In #983 we define a semantic versioning for all future versions of EPUB. Using the current proposals made in these issues, I'll propose here to use "3.2" as a identifier for the upcoming version, on the following grounds:

• EPUB 3.1 is not backward compatible with EPUB 3.01, which is a real issue (semantically and, more important, for practical deployments).
• In this evolution, some functionalities are added to EPUB 3.0.1 (especially the optional use of ARIA attributes), therefore 3.0.2 (i.e. a patch) does not fit, semantically speaking.
• This evolution is not a patch from 3.1 neither, because some functionalities are "reinstalled"; therefore 3.1.1 does not fit well.
• EPUB 3.2 fits well with the semantic versioning defined in #983, because:
  -- EPUB 3.2 supersedes EPUB 3.1.
  -- EPUB 3.2 is backward compatible with EPUB 3.01 (which will solve the issue of practical deployments around the world, and especially in Japan).
  (small note: it may even be forward compatible with EPUB 3.1, but nobody really cares).
• the EPUB 3.2 package document is specification is the same as in EPUB 3.01, therefore the version of the package document is still "3.0".

[GarthConboy]

Like I said, I hill I'm not willing to die on. Getting it done is more important than what we call it.

[GarthConboy]

And, of course, with a little thought, CSS comes to our rescue:

3<span style="text-decoration:line-through">.0</span>.2

Yielding:

3 .0 .2

🥇 Happy new year!

[llemeurfr]

We'll have to decide between semantic and politic(al) versioning...

[murata2makoto]

Like Garth, I think that a new spec using version="3.0" is most important. I can live with 3.2. I do not like 3.1.1.

[laudrain]

I think any version number above 3.0.x, like 3.1.x or 3.2, will lead us in problems with ISO standardisation.
As version="3.0" is the most important, why not 3.0.2 as spec version? Bringing back full 3.0.1 compatibility will make this version clearly a variant from it.
Much more easy to explain to the community.

[llemeurfr]

@laudrain, please also review #984 and #983.

[dauwhe]

After reading Laurent's arguments here and in #983, I support spec version number 3.2 and withdraw my support for 3.1.1. The change from 3.0.1 to what we're proposing is much more than bug fixes—we've changed the relationship between EPUB and HTML, CSS, and SVG. It fits very well with the SEMVAR minor version—a backward compatible addition of functionalities (those functionalities being, among other things, much of CSS).

[BillKasdorf]

I'm intrigued by Makoto's comment that he can live with 3.2, but not 3.1.1. That would be a significant factor to tilt me to 3.2 as well. Intellectually, 3.2 seems correct and responsible; 3.0.n seems to be blatant trickery. That's not to say that there are not arguments to go ahead and pull off that trick; but it feels shady to me. The main thing that still pulls me in that direction is that I don't want to pull the rug out from all the Japanese implementations. That's why Makoto's comment carries so much weight for me.

[clapierre]

I would have to agree with Bill here,
To be honest I never loved the idea of backtracking. That said having ISO adoption is important so whatever is required for that would be important to flesh out.

[GarthConboy]

As implied by previous comments, I can certainly live with 3.2 too.

[dauwhe]

Am I detecting an emerging consensus on 3.2?

I'm still confused about how the choice of version number would affect ISO standardization, and I suspect I'm not the only one. @laudrain, could you help us understand?

[laudrain]

@dauwhe we hope to have in the future an EPUB a11y standard that will be an ISO one. It will help the European Commission a11y act to be based on something international for ebooks.

But if I understand well, any ebook a11y standard would refer on ebook format that are ALSO ISO standards. This means that the latest version of EPUB spec will have to be an ISO std.

With 3.0.2, there is a chance.
With 3.2, we need first to standardize 3.1, then 3.2: no starter...

@murata2makoto, @GeorgeKerscher do you confirm my concern?

[GarthConboy]

Interested for Makoto to chime in -- given his above:

I think that a new spec using version="3.0" is most important. I can live with 3.2. I do not like 3.1.1.

I would expect he'd think we're (at least) okay on the ISO front with 3.2 (albeit with a backward compatible "3.0" package version).

[murata2makoto]

Agree on 3.2 as the spec version number as long as the value of the version attribute is "3.0".

[laudrain]

@murata2makoto how di you see the process if we have to bring this 3.2 spec version to ISO?

[murata2makoto]

In general, ISO/IEC standards do not have version numbers. The ISO/IEC system is more concerned about the publication year. Although the title of ISO/IEC TS 30135-1:2014 contains "EPUB3", this occurrence of 3 is not a version number but is just a substring. (Just like PL/1 does not mean version 1). So, I believe that SC34/JWG7 will not care.

[laudrain]

@murata2makoto thanks. My major concern with "3.2" is the weight it would put to any ISO process we would need to bring this new spec version to ISO. As I am far less experimented to ISO process, your comment gives me hope.

My minor concern with 3.2 is that it is IMO more difficult to explain/communicate than 3.0.2. I know we did a lot to bring 3.1 in place, but I don't care eating my hat to bring it back to full 3.0.1 compatibility, thus naming it 3.0.2.

My general feeling is that 3.1 was disturbed by the IDPF/W3C merging. This combination made it obsolete as it would be redefined in a more Web way in W3C (though we really tried, remember the first public draft of 3.1 in January 2016).

Then moving ahead from now, IMHO 3.0.2 would be an easier path for all.

[murata2makoto]

@laudrain Although I advocated the use of 3.0.2, I understand the concern that people will think 3.1 is newer.

[franciscave]

I agree with @murata2makoto that ISO/IEC won't care too much about the version number issue. There are plenty of cases where a consortium standard doesn't reach ISO/IEC until after several major and minor version changes. A familiar recent example would be UBL 2.1 (ISO/IEC 19845:2015). Remember that there is no ISO/IEC standard at present, only a Technical Specification. The Foreword to an ISO/IEC standard edition of EPUB 3.2 can explain that 3.1 was an evolutionary blind alley.

This is not my area of expertise, but in my opinion 3.2 might actually prove easier to explain than 3.0.2, because 3.2 builds on the improvements in 3.1 but restores the backwards-compatibility with 3.0 that was disrupted by 3.1. If it's a major improvement on both 3.0 and 3.1, 3.2 makes most sense.

[murata2makoto]

Folks, @franciscave is the new chair of ISO/IEC JTC1/SC34. I am the liaison from SC34 to W3C.

[laudrain]

Thank you @franciscave, excellent point.

[mattgarrish]

3.2 builds on the improvements in 3.1 but restores the backwards-compatibility with 3.0 that was disrupted by 3.1. If it's a major improvement on both 3.0 and 3.1, 3.2 makes most sense.

This is my view on this issue, too. If we were really going back to 3.0.1 (undoing the re-org and all the improvements in 3.1), 3.0.2 would probably make sense. But aside from the version number change, I haven't seen anyone suggesting that 3.1 was a bad thing. We're just looking to fix one problem with it, so the successor will have a lot more in common with 3.1 than 3.0.1. A 3.0.2 will look confusingly similar to 3.1.

[dauwhe]

Can everyone live with 3.2, even if it's not their first choice? Let's consider this a 24-hour call for consensus. Feel free to use GitHub's thumbs up/thumbs down reactions on this comment.

[dauwhe]

We have ten thumbs up, and no thumbs down. So I believe we have consensus in the community group for the proposed update to EPUB to be version 3.2. Thanks everyone for a good discussion!