Epub-specs: clarify meaning of validity wrt warnings

[mattgarrish]

I'm a bit uncomfortable with the assertion in the changes document that all 3.0.1 files are valid 3.2 files:

(A given version of EPUB is said to be strongly backwards-compatible with an older version if and only if any EPUB publication conformant to the older version is also conformant to the newer version). All valid EPUB 3.0.1 files will also be valid EPUB 3.2 files.

It's not practically true, as it all depends on whether your existing file makes use of any deprecated features or not. You might well have an invalid file if you validate against 3.2's rules (which probably isn't any different than what 3.0.1 did to some existing content). This later statement is a bit closer to the mark by saying "should not", but is still making a statement that won't always be true:

Since all valid EPUB 3.0.1 files will also be valid EPUB 3.2 files, creators of EPUB 3 publications today should not need to change anything.

What we haven't done is removed features entirely, but that's something different.

Should we consider tempering these statements?

[murata2makoto]

Even if some feature is deprecated, documents containing them are still conformant. So, I do not think that the quoted assertion is overstatement.

[mattgarrish]

The implication here is that you can submit a file to the same vendor running the latest validation rules that you previously submitted and there won't be any issues. That's not true, as it depends on what features you're using. Deprecation clearly impacts on validity as far as most epub producers will understand it, since it will result in warnings.

[murata2makoto]

I do not think warning implies invalidity and thus do not think deprecation impacts on validity. If I buy your argument, I have to propose to undeprecate features.

[mattgarrish]

I do not think warning implies invalidity

But this is a long-standing issue that publishers have had with warnings. Vendors won't accept files that report warning or errors, so they're inseparable to them. They're valid in the sense the features aren't forbidden from appearing in documents, but not valid in the sense that authors may have to remediate their old files.

All I'm suggesting is that we temper the statements, not drop them, so that people understand this reality. For example, we could add a note after the first statement I listed above that says:

Note
EPUB Publications that are valid to this version of the specification might contain features that are deprecated or no longer recommended. Whether these features are accepted in distribution channels is outside the scope of this specification.

That, or we should look at whether to demote deprecation messages from warnings to something else, although each time that's come up it's been noted that vendors will just add the "something else" messages to their ban list.

[llemeurfr]

@mattgarrish the note you're proposing above seems fine, as it protects the notion of backward compatibility btw EPUB 3.2 and EPUB 3.0.1 (if there is no backward compatibility we are creating EPUB 4 here ...) and addresses the minor issues publishers will meet with future versions of EPUBCheck.

This means that the sentence about validity should be reinstanciated with this added note.

@murata2makoto would you be ok with that?

[dauwhe]

Closed via #1260. We can reopen if we need to :)