Resolve confusion between default and implicit (#590).

[skynavga]

Closes #590.

[nigelmegitt]

Need to fix the sentence to be correct, if at all possible...

[nigelmegitt]

This statement is not actually true. SMIL 3 does not define any default begin attribute value for par or seq time containers. However it does define the semantics in the absence of such an attribute value. This distinction is important because it allows smpte discontinuous to be handled also. I think the sentence should read:

if no <att>begin</att> attribute is explicitly specified on a timed element, then the
beginning of the element's active period is resolved as the parent element's resolved
begin time if the parent is a parallel time container, or in relation to both the parent
element and the preceding siblings according to the semantics defined for a sequential
time container. In any case no additional begin time offset is defined in TTML.

[skynavga]

@nigelmegitt we are not talking about the beginning of the element's active period; we are talking about the default value of the begin attribute (in the XML sense that an attribute may have a default value); the note (as amended here), is entirely correct; this should be clear to any reader who reads the default value of the attribute (my emphasis); furthermore, you are neglecting the language in SMIL 3:

for par [1]

The default value of begin for children of a par is "0".

[1] https://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-timing.html#Timing-ParSyntax

for seq [2]

For children of a sequence, the only legal value for begin is a (single) non-negative offset value. The default begin value is "0".

[2] https://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-timing.html#Timing-SeqSyntax

[nigelmegitt]

Right, I see that we might be talking about different things. My interpretation is that specifying a default begin value of 0 represents an offset time, and that is resolved relative to the syncbase. The resolution is defined for both par and seq containers by SMIL offset values. And this is independent of the markerMode too.

[palemieux]

I think the prose should simply point to the appropriate SMIL3 section (like TTML1 3ED https://w3c.github.io/ttml1/index.html#timing-attribute-begin)

edited to reference SMIL3

[nigelmegitt]

I think the prose should simply point to the appropriate TTML3 section (like TTML1 3ED https://w3c.github.io/ttml1/index.html#timing-attribute-begin)

@palemieux did you mean "point to the appropriate SMIL3 section"?

[cconcolato]

Agree that it's simple to reference SMIL only without rephrasing it.

[nigelmegitt]

That would work for me too, though I think it is not a great service to the reader. If nobody thinks it incorrect, could we refer to SMIL3 normatively and add an informative note as per #652 (comment) ?

[skynavga]

@nigelmegitt awaiting your feedback on #652 (comment); please process ASAP

[skynavga]

@palemieux what SMIL defines as a default attribute value is dependent on SMIL DTDs; we don't use SMIL DTDs, so we need to express default values directly in our spec

[nigelmegitt]

I've changed my position on defining the default value, but notice that the value we specify is not valid in TTML. Added as a question for now - would appreciate others' thoughts.

[nigelmegitt]

0 is not actually a valid offset time expression in TTML - should this be 0s instead?

Also, do we need to clarify that this is interpreted as an offset time relative to the element's syncbase as per SMIL offset time?

[skynavga]

@nigelmegitt addressed comment in ad4ac88; we do not (and should not) paraphrase or redefine the semantics of begin; so in answer to your question of restating the meaning of "offset", the answer is NO.

[skynavga]

@palemieux @cconcolato please (1) approve, (2) dismiss your review, or (3) propose specific text changes;

[skynavga]

@nigelmegitt please re-review and approve

defer to @palemieux and @nigelmegitt to check the latest changes.

[nigelmegitt]

@skynavga please could you resolve the merge conflicts?

[skynavga]

@nigelmegitt trying, but something appears amiss with travis just now

[skynavga]

@nigelmegitt merged

[skynavga]

@palemieux ping

[palemieux]

As stated multiple times before, my preference is to simply point to SMIL and omit explanatory text, which is only marginally useful outside the full context of SMIL.

If the absence of informative text is a blocker, then the exact informative text used in SMIL should be used:

Children of a par begin by default when the par begins (equivalent to begin="0s"). Children of a seq begin by default when the previous child ends its active duration (equivalent to begin="0s");

[skynavga]

@palemieux so, are you prepared to block progress on TTML2 if we don't adopt your preference? it is quite absurd to force the reader to chase down the relevant language in SMIL just to answer the simple question of what the default value is; and, unless there is a substantive error or mischaracterization of the language in SMIL, the language used here works just fine

in particular, you are asking to include text which defines the meaning of a value of 0s, while the language I have use defers the interpretation to SMIL (via the existing reference) and merely states the literal default value

[palemieux]

so, are you prepared to block progress on TTML2 if we don't adopt your preference

Yes. TTML and SMIL, are complex enough by themselves. I do not see any reason to complicate matters by introducing new terminology and language.

[skynavga]

@palemieux then we are going to be blocked ... because I am not prepared to incorporate language from SMIL that assigns an interpretation to the meaning of 0s, which is what you are asking for

furthermore, it is entirely appropriate for us to define what default values apply since TTML is not SMIL but integrates (with constraints) a limited SMIL vocabulary; we explicitly define default values for everything else so failing to do so here would be an error by omission

[palemieux]

@skynavga My preference is to use the following text, adapted from TTML1, which addresses both our concerns since no new interpretation is assigned/inferred.

See [SMIL 3], § 5.4.3, Begin value semantics when no begin attribute is specified.

[skynavga]

@palemieux which was added in 3rd Ed draft without my review; further, this requires the reader to chase down the default value in SMIL, which says only:

If no begin is specified, the default timing is dependent upon the time container.

then the reader has to apply a TTML specific constraint, namely, that only par and seq time containers apply,

then the reader has to figure out where a default value for begin is defined for these time containers, which leads the reader to Section 5.4.4, where they have to tease out

for par:

The default value of begin for children of a par is "0".

for seq:

For children of a sequence, the only legal value for begin is a (single) non-negative offset value.
The default begin value is "0".

then the reader has to mentally translate 0 into 0s, since the former is not a legal value in TTML

unlike your suggestion, the note we ALREADY added in TTML2, about which this most simple edit merely removes one word "(implicit)" and changes 0 to 0s, does the reader a big favor by doing the leg work described above, and which has a definite clarifying affect, since a reader may fail to follow such necessary hermeneutic steps

[nigelmegitt]

@palemieux @skynavga Can we do both what is in this pull request and add the statement under the begin attribute semantics referring to SMIL as per TTML1 3rd Ed? They're both useful and true as far as I can see.

[skynavga]

@nigelmegitt the pre-existing note already says as much:

As defined by , §5.4.3,
if no begin attribute is explicitly specified on a timed element,
then

referring to 5.4.3 twice is redundant and probably confusing

[nigelmegitt]

@skynavga sorry, yes, I'm not sure why I missed that before. The notes don't actually say the same thing though. One says "see SMIL for semantics when begin is missing", the other says "as per SMIL, here's the default value for begin". The way I see this, it is important:

1. To refer the reader to SMIL for behaviour when there is no begin attribute
2. To be clear what the default value of the begin attribute is if one is needed/used.

They are separate points that both can usefully be made, possibly by a cleverly constructed edit to the existing note.

[skynavga]

@nigelmegitt but yet again, the normative paragraph just before this note says:

The semantics of the begin attribute are those defined by [SMIL 3.0], §5.4.3, while taking into account any overriding semantics defined by this specification.

the only point being made by the note is to clarify the default value, and not to define semantics

[css-meeting-bot]

The Working Group just discussed Resolve confusion between default and implicit (#590). ttml2#652, and agreed to the following:

• SUMMARY: Pull request resolves the defects in the issue, so proceeding. Concern registered that the note may not direct the reader to the full complexities, however they are normatively present.

The full IRC log of that discussion

<nigel> Topic: Resolve confusion between default and implicit (#590). ttml2#652
<nigel> github: https://github.com//pull/652
<nigel> Glenn: It's good to remind ourselves that the reason for this issue in the pull request is that some time ago we added a note
<nigel> .. because a point was made that nowhere did we say anything about the default value for begin. When we got into the long
<nigel> .. discussion about timelines and so forth that you initiated Nigel that came out of the discussion. But the language of the
<nigel> .. note had some language "a default (implicit) value" and someone asked about the (implicit) and it was clear that it could
<nigel> .. confuse the reader since SMIL mentions implicit, so we took out the implicit and tweaked the wording to make it more clear
<nigel> .. that it was specifying a default value a bit like in a DTD. We could have everywhere we put begin, in the element information
<nigel> .. item syntax, specified a default value that would be compatible with the other places we've done that for attributes but
<nigel> .. we didn't do that, probably because SVG and SMIL didn't do it, they built the default into their processor. That was the only
<nigel> .. real intent of this. Then Nigel pointed out that the value 0 is not syntactically correct and it needs to be something like 0s
<nigel> .. so we made that change. The current text, if you look at the ED today, the paragraph already says the semantics of the
<nigel> .. begin attribute are defined by [SMIL 3.0] §5.4.3 ... so we already define that. In the note we lead off with "As defined by
<nigel> .. [SMIL 3.0] ... " which is not inconsistent. The most recent suggestion by @palemieux to refer to SMIL when no begin
<nigel> .. attribute is specified merely repeats what was in the previous normative paragraph although it focuses on "when no begin
<nigel> .. attribute" but we've already said that those semantics apply. In my mind it does not clarify for the reader what the default
<nigel> .. value is without considering the interpretation of the semantics of that value. I carefully wrote the note to avoid saying
<nigel> .. anything about what the semantics of the default value are. For such a simple change of a non-normative note we have
<nigel> .. spent a lot of energy on that one. The no-op is to do nothing and leave the note as is with the word (implicit) in and with
<nigel> .. the value of 0 without the s on it. We should at least clarify that because if you follow through what the SMIL document
<nigel> .. says you would eventually get a value of 0 which is not compatible. At a minimum we need to say something but we could
<nigel> .. go ahead and merge as is.
<nigel> Pierre: My take on this is driven by the many hours spent trying to understand how TTML and SMIL work together. There is
<nigel> .. already a sentence in SMIL that says that children of a par begin equivalent to 0 seconds.
<nigel> Glenn: SMIL is inconsistent there.
<nigel> Pierre: It's a note in SMIL 3. I would either just point to that note, or copy it verbatim. I would not try to reinvent things here.
<nigel> Glenn: Why does SMIL say in the normative text 0 and then have a note that says 0s?
<nigel> Pierre: I don't know. My encouragement is to copy and paste the informative note that we like in SMIL because then we're
<nigel> .. consistent with SMIL and don't invent a third way.
<nigel> Glenn: Do you think what's proposed here is inconsistent with SMIL 3?
<nigel> Pierre: What I don't like is the notion of a default value, which is not a defined term in SMIL. There's no default as far as I can tell.
<nigel> Glenn: The text in §5.4.4 defines the default value.
<nigel> -> https://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-timing.html#Timing-ParSyntax SMIL3 definition of default for begin
<nigel> Pierre: I think this is really unfortunate. We should copy the informative note that says what we want.
<nigel> Glenn: I think the note says what we want and is not inconsistent with SMIL in that it does not override the semantics of SMIL.
<nigel> .. It does the job for the reader. I noted a while ago that it requires the reader to chase down text in SMIL 3 - even you [pierre]
<nigel> .. hadn't found that yet.
<nigel> .. [summarises https://github.com//pull/652#issuecomment-395288250 ]
<nigel> .. The point of this was to help out the reader not to make them do this chasing and miss information.
<nigel> Pierre: The issue is that saying the default value is 0s is not the full story.
<nigel> Glenn: Of course, and that's why I don't want to paraphrase what it means to say 0s.
<nigel> Pierre: I think the note is unhelpful.
<nigel> Nigel: Is it misleading or wrong?
<nigel> Pierre: It oversimplifies something that's a lot more complex.
<nigel> .. Clearly removing (implicit) corrected the defect in the ticket, so that's essential.
<nigel> Glenn: Right, and the second change was to change 0 to 0s after Nigel noted that it was inconsistent with TTML.
<nigel> Pierre: I think it's a bad note.
<nigel> Nigel: I'm hearing that it corrects the defect but that Pierre's concern is that it doesn't direct the reader to see that there's more
<nigel> .. to it than just the default value.
<nigel> Pierre: Right, I don't want to paraphrase what SMIL already says.
<nigel> .. I don't want to change the normative text. If nobody else thinks its a bad note then go ahead.
<nigel> .. I'll remove my review that blocks this.
<nigel> SUMMARY: Pull request resolves the defects in the issue, so proceeding. Concern registered that the note may not direct the reader to the full complexities, however they are normatively present.