Backward Compatibility in EPUB 3.1

[murata2makoto]

Backward Compatibility
It should process EPUB version "2.0" Publications as defined in [OPF2], [OPS2] and [OCF2].

It should process EPUB version "3.0" Publications as defined in [Publications 3.0.1], [Content Docs 3.0.1] and [OCF 3.0.1].

It must attempt to process any given Rendition of an EPUB Publication whose Package Document version attribute designates a version lower than "3.1" or which omits the version attribute.

I would like to drop this entirely. First, many Asians would like to implement an RS dedicated to 3.0.1 and 3.1. Why do we need the first bullet? Second, this section may make it difficult to create an ISO/IEC standard from 3.1, if the ISO/IEC TS for 3.0 is superseded by the ISO/IEC standard for 3.1.

[mattgarrish]

I'm not sure I follow. The requirement is only that it attempt to process an epub with a version lower than 3.1. Do we really want reading systems rejecting the files outright?

The other two points are only recommendations. They don't require the reading system to support 2.0 or 3.0, but it would be good if they did.

[murata2makoto]

The other two points are only recommendations. They don't require the reading system to support 2.0 or 3.0, but it would be good if they did.

If so, I would like to delete them strongly.

We already have EPUB 2 and 3.0.1, which encourage people to support EPUB 2 and EPUB 3.0.1. EPUB3.1 does not have to encourage people to support them.

We intend to create an ISO/IEC standard for EPUB eventually. In ISO/IEC, normative references and bibliography are very different. Adding something to the biblography is easy. But adding something as a normative reference is different. Normative references to non-ISO specs require reference explanatory reports. Normative references to non-latest versions of ISO/IEC standards are not allowed (I believe so). It is only these two bullets that require EPUB 2 and EPUB 3.0.1 as normative references.

I might be overworried since standards submitted by the fast-track or PAS procedure do not require the separation of normative references and bibliography. But when we revise them, we will be requested to separate them.

[mattgarrish]

Sure, if we keep the requirement to attempt to open epubs with a lower, or no, version, losing the recommendations to open older versions according to their specifications doesn't strike me as problematic.

We could also look at how to say this non-normatively and without referencing any specific version. For example, maybe a note like:

"EPUB Publications with older version numbers will not always render exactly as intended unless processed according to their respective specifications. Reading System developers are encouraged to support such EPUB Publications as defined by those specifications."

@TzviyaSiegman @GarthConboy @mgylling any thoughts on whether to drop, add a note or do nothing?

Or should we wait on this one until calls resume?

[TzviyaSiegman]

I am fine with a slightly less encouraging of old EPUB version of Matt's language. Perhaps, something like:
"EPUB Publications with older version numbers will not always render exactly as intended unless processed according to their respective specifications. Reading System developers should attempt to support such EPUB Publications as defined by those specifications."
I do think this merits discussion on a call, and I will email some people with a firmer grasp of the needs of the EPUB 2 market.

[GarthConboy]

+1 to Tzviya's comment. We clearly don't want to go out of our way to orphan the millions of 3.0.1, 3, and 2.x EPUBs out there. So, think the first two bullets are really fine:

It should process EPUB version "2.0" Publications as defined in [OPF2], [OPS2] and [OCF2].

It should process EPUB version "3.0" Publications as defined in [Publications 3.0.1], [Content Docs 3.0.1] and [OCF 3.0.1].

Or, the slightly less explicit version proposed by Matt/Tzviya is okay too.

The third bullet:

It must attempt to process any given Rendition of an EPUB Publication whose Package Document version attribute designates a version lower than "3.1" or which omits the version attribute.

seems a little wonky. Do we really need to mention rendition? And why do we have "or which omits the version attribute" -- I'd think just the "lower than 3.1" would be fine.

[mattgarrish]

Are you saying that if the version attribute isn't defined the reading system can decide for itself whether to open?

I wouldn't interpret the lack of a version attribute as indicating the publication has a version lower than anything. It's ambiguous what it means. That's why we added the statement, as I recall. It would be good to still say whether it becomes a should or may.

The wording can be cleaned a lot, I agree. It could just be: "It MUST attempt to process an EPUB Publication whose version is lower than "3.1"."

[TzviyaSiegman]

I think you're asking Garth, but please do not remove the version attribute. I'm fine with proposed wording.

[mattgarrish]

Not proposing to remove the attribute, no. It's just about what the reading system is expected to do when it finds an invalid publication without one.

It's technically error handling, so I'm not completely wedded to keeping it. It just seems like an obvious question since we say you must attempt to open lower and should attempt to open higher.

[BluefireMicah]

+1 on all of Garth's comment above. As a reading system implementer, my take is that real world use case scenarios and business requirements will by far and away drive implementation of backwards compatibility more so than any "should" or "recommended" language around backwards compatibility. Certainly it is a good thing to recommend, and I would strongly support and advocate for inclusion of such language. That said, I do believe it is relatively unimportant in the big picture as no matter what the language there is, it seems very highly unlikely to actually impact what gets implemented - or not. Once EPUB3 functionality is implemented in an RS, adding support for 2.0 is rather trivial in comparison to the already invested scope of effort. And, given that there are many millions of high value EPUB2 documents in existence, the impetus to support them relative to the effort required to do so is quite compelling - more compelling than any "recommendation" could ever be. Even in Asian markets, where EPUB2 is not anywhere as common, there certainly are use cases around English language content - and even in cases where there aren't - "should" statements don't seem to be a problem - unless I'm missing something? If there are future considerations around spec language (e.g. ISO/IEC) I myself would be completely comfortable with something along the lines of what Tzviya mentioned: "EPUB Publications with older version numbers will not always render exactly as intended unless processed according to their respective specifications. Reading System developers should attempt to support such EPUB Publications as defined by those specifications."

[GarthConboy]

My comment re "version" attribute was driven by the attribute always being required (right?) [seemed required in 2.0.1 to my read]. So, I didn't get why we even mentioned it not being there.

I like the simplification:

"It MUST attempt to process an EPUB Publication whose version is lower than "3.1"."

[mattgarrish]

Yes, but 2.0.1 also stated:

A package element that omits the version attribute must be processed as an OEBPS 1.2 package.

Do we care about opening those?

[GarthConboy]

Ah, too far in the way-back-machine! I forgot we didn't originally have that attribute.

Given your quote above, I think it's okay to omit another (modern) mention of it not being there -- as if they are doing 2.0.1, they would hit the omit case there. :-)

[BluefireMicah]

Please forgive my ignorance, but I don't fully understand the implications of having both:
should process
Must attempt to process

Is it that "full" prior version support is a "should", but that at least partial support of prior versions is a "must"? That is, I guess I don't quite understand what "attempt to process" means in pragmatic terms of what I'd be telling my development team to implement in terms of functional requirements.

Again, apologies if that should be clear if I were more familiar with spec-speak.

[mattgarrish]

Support per the specifications that defined the prior versions is not required to be conformant, but the reading system must attempt to render a publication with an older version number. The reading system could attempt to process an older version according to 3.1 requirements. That's all the "must" is about.

It is recommended to support older versions according to their specifications for obvious reasons, of course.

If we keep the "should", I'd reorder so that the "must" is first, as it's the broader statement.

[BluefireMicah]

Thanks Matt.

[mattgarrish]

Proposed Solution

Remove references to old epub specifications and keep generalized requirement as detailed in #780 (comment)

Reword requirement to open lower versions to: 'It MUST attempt to process an EPUB Publication whose version is lower than "3.1".'