Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate leap seconds in media time #286

Merged

Conversation

Projects
None yet
6 participants
@palemieux
Copy link
Contributor

commented Dec 13, 2017

Closes #210
Uses prose at w3c/ttml2@f88869e as basis, but does not require a change in processor behavior.

@palemieux palemieux added this to the 3rd Ed milestone Dec 13, 2017

@palemieux palemieux self-assigned this Dec 13, 2017

@skynavga
Copy link
Contributor

left a comment

I thought I was pretty clear. We cannot use the term "deprecate" or "deprecated" except when referring to the possibility of a deprecation in a future version, and we can only do this in a note.

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented Dec 13, 2017

@skynavga You have offered to substantiation, so I assume it is a personal preference/belief of your company and not a W3C requirement.

@palemieux palemieux added the agenda label Dec 13, 2017

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

No, this not a personal preference. It is a past group decision (prior to you joining the group).

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented Dec 13, 2017

No, this not a personal preference. It is a past group decision (prior to you joining the group).

Perhaps, but the group is different now than it was, and the W3C process does not prevent it.

Deprecating it in TTML1 makes it clear that these features/syntax should not be used, and will likely be removed in a future version of TTML1, which is the objective as far as I can tell.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

There is a standing process rule in this group and (all other WGs I am aware of): WG decisions are not revisited without new information of relevance. You are not offering any. The decision stands. In any case, I have a block on this merge which will stay there until the word deprecate is removed as I indicated.

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented Dec 13, 2017

@skynavga You will need to produce the WG decision that you are referencing, so that the group can examine the premise that led to it, otherwise your objection is weak at best.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

No I don't. You can just take my word for it or check with Mike D who I'm sure can confirm it.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

Also, there is something you don't seem to understand here regarding deprecation. When the spec says something is deprecated, that essentially requires a validator to produce a warning (unless the user does something to explicitly disable the warning). Therefore, when you ask to label a feature or usage as deprecated, you are mandating a change in processor behavior.

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented Dec 13, 2017

When the spec says something is deprecated, that essentially requires a validator to produce a warning (unless the user does something to explicitly disable the warning).

Deprecation does not require anything, it merely recommends.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

I should also note that adding a deprecation in TTML1 will invalidate the statement that appears in [1].

No feature is deprecated by this version of this specification.

[1] https://www.w3.org/TR/ttml1/#d3e20309

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented Dec 13, 2017

No feature is deprecated by this version of this specification.

Yes, this statement would need to change if syntax is deprecated in the next edition.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

I also want to take note of the last bullet of item (3) under [1]:

clears up an ambiguity or under-specified part of the specification in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming

By my reading, introducing a deprecation will cause content which was conforming (in the sense that it produces no error or warning by a validator) to become non-conforming (since a warning will appear that did not previously appear).

[1] https://www.w3.org/2017/Process-20170301/#substantive-change

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented Dec 13, 2017

I also want to take note of the last bullet of item (3) under [1]:

Yes, the change is definitely substantive, which is permitted in new editions of specifications AFAIK.

@skynavga I would not argue for deprecation if the syntax in question was not undefined and/or harmful. I do not see why we would shy away from clearly discouraging bad practices.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

However, to date, we have never entertained a substantive change for a new edition of TTML1, and, when we published 2nd Edition, we went out of our way to convince ourselves and the director that we had not made any substantive changes.

To repeat myself, I am not opposed to "discouraging bad practices"; I am opposed to labelling such discouragement a "deprecation".

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented Dec 13, 2017

To repeat myself, I am not opposed to "discouraging bad practices"; I am opposed to labelling such discouragement a "deprecation".

To be clear, you also oppose using should not, or only oppose deprecation?

when we published 2nd Edition, we went out of our way to convince ourselves and the director that we had not made any substantive changes.

Yes. In this case, the consensus indicates that the syntax is harmful and undefined, and should have never been used.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

We can also say in the note something like we say already in a TTML1 note:

Furthermore, the ttp:markerMode is being considered for deprecation in the next revision of this specification.

Here, we could say something stronger, such as

Furthermore, X is expected to be deprecated in the next revision of this specification.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2017

As per #210 (comment) and my follow up, and the absence of further comments to the contrary, my understanding is that we have consensus for a note of disrecommendation. I'm not necessarily against a stronger position though.

I generally don't like making promises about the future in a specification - the strongest statement we should make is to say that X may be considered for deprecation in a future version.

Thinking about the substantive question, I think it would actually be a good idea for a validating processor to produce a warning if this practice (use of 60 second value in inappropriate timebase) is used in a document. The question in my mind is if we need to make that a normative requirement by means of a deprecation or if merely a "should not" is strong enough that conforming validating processors are expected to produce the warning. Or if it's okay for some validating processors to remain silent.

The question has been raised of making existing conformant documents non-conformant by prohibiting the use of 60 second values in the wrong timebase. The questions we should ask here are:

  • how many documents do we think would be affected?
  • what semantic behaviour is defined for this (mis)usage? (none, as far as I'm aware)

I suspect that the real world impact on existing documents of normatively prohibiting this misuse would be zero, but I'm unable to provide any data points to support that suspicion. Can anyone else?

I think we do have the freedom to make the change if we want: Since no semantic behaviour is defined for the misuse now I would argue that this is a clarification rather than a substantive change. Specifically, the text at https://www.w3.org/TR/ttml1/#timing-time-value-expressions :

... seconds (including any fractional part) are constrained to the closed interval [0,60], where the value 60 applies only to leap seconds.

could be interpreted as saying that the value 60 is not permitted except to express leap seconds, and since only UTC incorporates the concept of leap seconds, it would be a reasonable clarification change to add the statement "It is considered an error to use the value 60 in timebases and clock modes that do not support leap seconds". The fact that this statement is currently absent doesn't mean that it is not a reasonable interpretation of the existing text.

@nigelmegitt
Copy link
Contributor

left a comment

Needs further discussion - I think we should go further in clarifying the slightly ambiguous current status.

href="#parameter-attribute-timeBase"><att>ttp:timeBase</att></loc> is <code>clock</code>
and <loc
href="#parameter-attribute-clockMode"><att>ttp:clockMode</att></loc> is <code>local</code> or <code>utc</code>, use of the special value of 60 seconds
to denote a leap second is deprecated and should not be specified.</p>

This comment has been minimized.

Copy link
@nigelmegitt

nigelmegitt Dec 13, 2017

Contributor

I've argued in #286 (comment) that we should go further. Note also this has been added to the agenda for this week's call, so if we haven't resolved it by tomorrow then we will discuss it.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2017

The best way to resolve this issue is simply to state (in a note) that leap seconds in media time base are not defined, and that they are recommended to be avoided in content (or, alternatively, interpreted as 59 by processors).

@mikedo

This comment has been minimized.

Copy link

commented Dec 14, 2017

Why does it have to be an (informative) note? It should be clear that this syntax was not ever intended, as well as being semantically undefined. Why can't we just fix it to be the original intent and constrain the syntax for media? If someone actually authored media time documents with >59, they are broken.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2017

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2017

@mikedo

This comment has been minimized.

Copy link

commented Dec 14, 2017

My only baseline for PER/ER process rules is TTML1SE, where we made such changes when a provision was clearly unintended and/or undefined, even if technically substantive. Did staff or someone tell the WG that we crossed the line in TTML1SE? Perhaps @nigelmegitt can weigh on this policy question?

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented Dec 14, 2017

As detailed at https://w3c.github.io/w3process/#revised-rec , the publication of an Edited Recommendation that incorporates substantive changes, but no new features, seems permitted:

To make corrections to a Recommendation that produce substantive changes but do not add new features, or where there were votes against publishing the corrections directly as a Recommendation, a Working Group may request publication of a Candidate Recommendation, or if no Working Group is chartered to maintain a Recommendation W3C may publish a candidate Amended Recommendation, without passing through earlier maturity levels. [...] If the publication was requested by a Working Group, the resulting Recommendation is called an Edited Recommendation.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2017

Which is as I thought, it requires going through the CR process, which, without the substantive change, it would not be required to do so.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2017

Did staff or someone tell the WG that we crossed the line in TTML1SE? Perhaps @nigelmegitt can weigh on this policy question?

@mikedo Not that I'm aware of.

I think we might have more freedom than we imagine here, and I'm certainly prepared to argue the case that this case was never intended to be supported, and replacing an implied result with explicit specification text is something that should simply be allowed. In the end this will come down to the Director, and we should check with staff on the exact position before going down a route we are not comfortable with.

If it we need to publish a CR for TTML1 Third Edition, the impact of that would probably be that we would need to define tests for the substantively changed parts of the spec, to meet exit criteria. To be honest, that is good practice anyway. I'm not against going back to CR, nor am I against the more direct Edited Recommendation route.

@plehegar

This comment has been minimized.

Copy link
Member

commented Dec 14, 2017

We have indeed a process for making "substantive corrections" to a Recommendation and it does require to publish a Candidate Recommendation:
[[
To make corrections to a Recommendation that produce substantive changes but do not add new features, or where there were votes against publishing the corrections directly as a Recommendation, a Working Group may request publication of a Candidate Recommendation, without passing through earlier maturity levels.
]]
https://www.w3.org/2017/Process-20170301/#revised-rec

The transition requirements for this Candidate Recommendation are available at:
https://www.w3.org/Guide/transitions?profile=CR&cr=rec-update#transreq

For an example, see the recent transition on CSS Color 3:
https://lists.w3.org/Archives/Member/chairs/2017OctDec/0145.html

Btw, if i understand the change here, it would be to remove a feature from the Recommendation, which is something not really addressed in our documentation and I don't believe we have a past example for that. I believe the Director will/should ask the Group to demonstrate that we don't have implementations for the feature but I don't have yet recommendation on how the Group could do that. Input would be welcome I believe...

@palemieux palemieux removed the agenda label Dec 14, 2017

palemieux added some commits Dec 26, 2017

@palemieux palemieux merged commit f386707 into master Dec 26, 2017

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
ipr PR deemed acceptable.
Details

@palemieux palemieux deleted the issue-210-deprecate-leap-seconds-in-certain-time-bases branch Jan 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.