RE: TTML2 backwards compatibility with TTML1

I am more concerned that we are all really in agreement with the principle.

In this example, it could also be changed to “deprecated”. The text is a bit confusing since it goes on to say what a processor must do if the value is present:

“If it appears in a profile specification, then it must be interpreted as if required had been specified.”

which is a bit at odds with it being forbidden and non-conformant.

                Mike

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Wednesday, May 31, 2017 9:52 AM
To: Michael Dolan <mike@dolan.tv>
Cc: public-tt@w3.org
Subject: Re: TTML2 backwards compatibility with TTML1

Regarding the obsoleting of value="use" on ttp:feature and ttp:extension, we could tie this to whether the document is identified as ttp:version="2" or greater, deprecating it for version < 2, and obsoleting it for version >= 2.

On Wed, May 31, 2017 at 10:37 AM, Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>> wrote:
Nigel,

Your acceptance of this principle uses “deprecate” and is conditional on “a better way to do things”.  What I said was: “all conformant TTML1 instance documents would also be conformant TTML2 instance documents”. These are not the same.

Based on the definition of “deprecated” (“may but should not appear in a TTML document instance, and a validating processor should report a warning if it does appear”) in section 2.3 it is arguably consistent in principle with what I said, but one would have to inspect the conformance language in the body for each deprecated item to confirm that the intent of 2.3 was actually followed.

Section 2.3 also defines “obsoleted” (“must not appear in a TTML document instance, and a validating processor should report an error if it does”) of which there is at least one instance (6.1.3 ttp:feature value), thus at odds with this backwards compatibility principle.

If we all agree with the principle as I have stated it, then perhaps we should include that in the front matter of the TTML2 spec to remove all doubt. And, I don’t see how obsoleting any feature is consistent with this.

Can we discuss tomorrow?

                Mike

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>]
Sent: Wednesday, May 31, 2017 8:59 AM

To: Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>>; public-tt@w3.org<mailto:public-tt@w3.org>
Subject: Re: TTML2 backwards compatibility with TTML1

Thanks Mike,

I think we have discussed and agreed a goal to specify TTML2 so that a TTML2 processor would process TTML1 documents. For me also it would need a very strong argument to break this, however deprecating features or syntax is IMO reasonable if we have a better way to do things. I do not think there are any other examples than #331 – please do alert us if you find any.

Nigel


From: Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>>
Date: Wednesday, 31 May 2017 at 16:43
To: "public-tt@w3.org<mailto:public-tt@w3.org>" <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: RE: TTML2 backwards compatibility with TTML1
Resent-From: <public-tt@w3.org<mailto:public-tt@w3.org>>
Resent-Date: Wednesday, 31 May 2017 at 16:43

Apologies.  (I keep trying not to send email before my first coffee, but….FYI, I was separately emailing with another colleague about that one and crossed up the issues.)

I am mostly reacting to the recent discussion on this issue https://github.com/w3c/ttml2/issues/331


I missed that it was deprecated in the first place, but why is restoring this even a debate?  I.e. see below about my understanding of a guiding principle. If we in fact all agree with that, then this issue should just be accepted and closed without further discussion.

                Mike

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: Wednesday, May 31, 2017 8:26 AM
To: Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>>; public-tt@w3.org<mailto:public-tt@w3.org>
Subject: Re: TTML2 backwards compatibility with TTML1

Hi Mike,

The link you provided is an IMSC issue not a TTML2 issue. I'm a bit confused – perhaps there's another example where a TTML2 constraint is being introduced that would mean a TTML2 processor would not process a TTML1 document correctly?

Kind regards,

Nigel


From: Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>>
Date: Wednesday, 31 May 2017 at 16:11
To: "public-tt@w3.org<mailto:public-tt@w3.org>" <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: TTML2 backwards compatibility with TTML1
Resent-From: <public-tt@w3.org<mailto:public-tt@w3.org>>
Resent-Date: Wednesday, 31 May 2017 at 16:12

I thought we had a (perhaps implicit and unspoken) requirement that TTML2 would be backwards compatible with TTML1.  That is, all conformant TTML1 instance documents would also be conformant TTML2 instance documents.

However, we are making decisions that are at odds with the above, e.g. this week’s change to constrain origin and extent in issue 239 and its PR: https://github.com/w3c/imsc/pull/240  There are other examples.

I think we need to all be on the same page about the above requirement.

My personal view is that unless something is really broken and unusable/untestable from TTML1, that this requirement should hold.

Perhaps we can discuss this tomorrow before committing any more changes that are at odds with it?

                Mike

---------------------------
Michael A DOLAN
TBT, Inc;  PO Box 190
Del Mar, CA 92014
+1-858-882-7497<tel:(858)%20882-7497>




----------------------------

http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------