Re: TTML2 backwards compatibility with TTML1

On Wed, May 31, 2017 at 11:03 AM, Michael Dolan <mike@dolan.tv> wrote:

> 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.
>

Not really. Most processors don't check conformance, so we need to define
behavior in case an unsupported value appears. We do this throughout the
document in statements like, "if a value is not supported, then use the
nearest supported value".


>
>
>                 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> 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]
> *Sent:* Wednesday, May 31, 2017 8:59 AM
>
>
> *To:* Michael Dolan <mike@dolan.tv>; 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>
> *Date: *Wednesday, 31 May 2017 at 16:43
> *To: *"public-tt@w3.org" <public-tt@w3.org>
> *Subject: *RE: TTML2 backwards compatibility with TTML1
> *Resent-From: *<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
> <nigel.megitt@bbc.co.uk>]
> *Sent:* Wednesday, May 31, 2017 8:26 AM
> *To:* Michael Dolan <mike@dolan.tv>; 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>
> *Date: *Wednesday, 31 May 2017 at 16:11
> *To: *"public-tt@w3.org" <public-tt@w3.org>
> *Subject: *TTML2 backwards compatibility with TTML1
> *Resent-From: *<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 <(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.
>
> ---------------------
>
>
>