Incorrect usage of forward/backward compatibility in Sections 3.4.[12]

[skynavga]

The use of forward and backward in sections 3.4.[12] appears to be inconsistent (and inverted) with respect to common usage. I propose an editorial change as follows:

• change Forward Compatibility to read Downward Compatibility, i.e., the ability of a older version to work with data produced by or for an newer version;
• change Backward Compatibility to read Upward Compatibility, i.e., the ability of a newer version to work with data produced by or for an older version;

[nigelmegitt]

This is always confusing, whichever way we write it, because the direction depends on whether you're thinking from a document or a processor perspective, and whether that's a TTML1 or a TTML2 instance. For what it's worth (not much!) I hadn't heard of Upward/Downward Compatibility as commonly used terms.

One might also expect that something like "Forward" or "Upward" compatibility would also tell you something about the commitment to compatibility of TTML2 documents or processors with future versions of TTML, but of course it does not, since we haven't made any such commitments.

Perhaps we should rename the sections even more explicitly, such as:

• 3.4.1 Forward Compatibility -> TTML1 processor handling of TTML2 documents
• 3.4.2 Backward Compatibility -> TTML2 processor handling of TTML1 documents

[skynavga]

FYI, here is what ChatGPT 3.5 says about this:

Forward and backward compatibility are two important concepts in software systems that refer to how software interacts with different versions of itself.

1. Forward Compatibility:
   Forward compatibility, also known as upward compatibility, refers to the ability of a newer version of software to work with data and interfaces from an older version. In other words, if a software system is forward compatible, it can understand and handle data and features created by previous versions of the software. This is crucial to ensure that users can seamlessly upgrade to a newer version without facing data compatibility issues or breaking their existing workflows.

For example, suppose a word processing software's latest version introduces some new formatting options. When a user saves a document with these new formatting options in the latest version, the file should still be readable and functional in an older version of the word processor, even if some of the newer features are not supported.

2. Backward Compatibility:
   Backward compatibility, also known as downward compatibility, is the opposite of forward compatibility. It refers to the ability of an older version of software to work with data and interfaces from a newer version. If a software system is backward compatible, it can understand and interact with files and features from a more recent version without issues. This is important to ensure that users can open and use files created with newer versions of the software, even if they haven't updated to the latest version yet.

Continuing with the word processing software example, if a user receives a document created with the latest version, they should be able to open and view it correctly using an older version of the word processor. While they may not have access to all the newest features, the core content and formatting should be intact.

In summary, forward compatibility ensures that newer versions of software work with data from older versions, while backward compatibility ensures that older versions of software can handle data from newer versions. These concepts are crucial in software development to maintain seamless user experiences during software upgrades and prevent data compatibility issues.

[nigelmegitt]

That is a nicely readable explanation - my instinct is to somewhat distrust it though, just in case it is not actually correct. But enough of my problems.

We have:

• Forward/Upward Compatibility of TTML1 documents with TTML2 processors
• Backward/Downward Compatibility of TTML2 documents with TTML1 processors

Maybe we should drop the forward/backward/upward/downward phrasing altogether? It seems to add more confusion than benefit. And if we don't mention specifically that we're talking about compatibility of this version with respect to the previous version, then it seems as though we accidentally forgot to describe compatibility of this version with respect to some future version.

[cconcolato]

A conforming TTML1 processor may be able to process a TTML2 content document instance, provided ...

This is exactly what forward compatibility means to me.
Same for backwards compatibility, the current text says that a new processor will process old documents the correct way.
I don't see the problem.

[skynavga]

As Nigel points out, there is an ambiguity based upon whether you are considering compatibility as a property of documents (data) or processors (systems).

We wrote these sections from the perspective of the a document (data), i.e., we used forward to describe the ability of a system to process documents from an earlier version (moving older data formats forward).

And we used backward to describe the ability of a system to process documents from a later version (moving newer data formats backwards.

The problem (as I see it) is that most common descriptions, e.g., in Wikipedia and elsewhere, consider forward and backward as a property of the processor (system) rather than a property of the document (data): a processor that is backward compatible can process older document formats, and a processor that is forward compatible can process newer document formats.

So this common understanding of backward and forward translates to forward and backward, respectively, in terms of the current language in TTML2.

This difference between the current formulation in TTML2 and the common understanding gives rise to confusion. This can be resolved in a couple of ways:

• adding a note that points out the difference between usage in the TTML2 spec and common usage;
• renaming (or expanding) the titles of these sections in TTML2;

My preference is the latter.