Changelog between August 26, 2014 and September 2, 2014

Issues | Actions.

Get changelog

Issues

ISSUE-338 (raised)
  • 2014-08-26 17:12:04:
    *<Glenn Adams> Created issue 'inconsistent implicit duration of singleton span in sequential container' nickname owned by Glenn Adams on product TTML 1.0, description 'The implicit duration of an anonymous span child of a sequential container is explicitly defined to be zero (section 10.4); however, the implicit duration of an explicit singleton (i.e., non-nested) span in the same context

    Here is an example, where I ignore whitespace to aid in viewing. Given a fragment:

    <p timeContainer="seq">
    Foo
    <span>Bar</span>
    Baz
    </p>

    Generating anonymous spans to wrap text nodes:

    <p timeContainer="seq">
    <span xml:id="anon1">Foo</span>
    <span>
    <span xml:id="anon2">Bar</span>
    </span>
    <span xml:id="anon3">Baz</span>
    </p>

    Applying timing semantics as presently defined to resolve implicit duration:

    <p timeContainer="seq" durImplicit="indefinite">
    <span xml:id="anon1" durImplicit="0">Foo</span>
    <span durImplicit="indefinite">
    <span xml:id="anon2" durImplicit="indefinite">Bar</span>
    </span>
    <span xml:id="anon3" durImplicit="0">Baz</span>
    </p>

    Here, anon2 is assigned an indefinite implicit duration because its parent is an explicit span which defaults to 'par' time containment semantics. Since SMIL requires a seq container that contains an indefinite duration child to also be indefinite, then that indefinite propagates up the node tree.

    This seems counterintuitive. I propose to resolve by a slight change in 10.4 from the current text:

    "if the anonymous span's parent time container is a parallel time container, then the implicit duration is equivalent to the indefinite duration value as defined by [SMIL 2.1]; if the anonymous span's parent time container is a sequential time container, then the implicit duration is equivalent to zero"

    to read:

    "if the anonymous span's nearest explicit time container ancestor is a sequential time container, then the implicit duration is equivalent to zero; otherwise, it is equivalent to the indefinite duration value as defined by [SMIL 2.1]"

    and add the following Note

    "Note: An element is an explicit time container if it specifies a timeContainer attribute."

    Reworking the above example with the new text, we get:

    <p timeContainer="seq" durImplicit="0">
    <span xml:id="anon1" durImplicit="0">Foo</span>
    <span durImplicit="0">
    <span xml:id="anon2" durImplicit="0">Bar</span>
    </span>
    <span xml:id="anon3" durImplicit="0">Baz</span>
    </p>

    The resolution of this issue also needs applied to TTML2.
    ' non-public
  • 2014-08-26 17:57:40:
    *<Glenn Adams> Continuing the first sentence of the description:

    "... is assigned indefinite, an apparent inconsistency."
ISSUE-339 [allow #overflow] (raised)
  • 2014-08-27 20:28:50:
    *<Frans de Jong> Created issue 'Allow the use of #overflow' nickname allow #overflow owned by Frans de Jong on product TTML IMSC 1.0, description '---------------------------------------------------------------
    Request
    ---------------------------------------------------------------
    Section 5.8 (Common Constraints->Features)

    It shall be possible to use the #overflow feature.

    Needed change

    Now:
    #overflow -> SHALL NOT be used

    Proposed
    #overflow->MAY be used


    If this editorial change is not feasible the second (but worse option) would be to add a requirement that a processor should not stop processing the document even if it contains the unsupported tts:overflow attribute.


    ---------------------------------------------------------------------------------------------
    Background
    ---------------------------------------------------------------------------------------------
    In IMSC the use of overflow is not allowed. It is not defined if a processor is allowed to reject a document that uses tts:overflow.

    The assumed behaviour in IMSC is tts:overflow="hidden". As this is the TTML initial value and "visible" is not allowed, the feature is prohibited entirely.

    In EBU-TT-D it is specified that

    If the value of this attribute is “visible", then content
    should not be clipped. If the value is hidden, then content that
    goes outside of the affected region should be clipped and is not
    visible

    Further it is added in an informative note:

    Note: Setting the feature to “visible” does not
    guarantee that content that overflows the region will be
    presented, e.g. if the content would need to overflow the root
    container region.

    Therefore if the default behaviour is applied (content that overflows is hidden) the processor behaviour will still be EBU-TT-D compliant and acceptable. But a processor shall not reject the document and shall process it.

    It would be better to enable the feature to make IMSC more consistent. As the implied presentation behaviour is not a strict requirement for a presentation processor it should not cause any problem for any existing processor that has not implemented this feature yet.
    ' non-public
ISSUE-340 [profile designator clarification] (raised)
  • 2014-08-27 20:31:31:
    *<Frans de Jong> Created issue 'Make clear that the use of the ttp:profile attribute is not required.' nickname profile designator clarification owned by Frans de Jong on product TTML IMSC 1.0, description '----------------------------
    Request
    ----------------------------
    Section: 5.1 (Text Profile Constraints -> Profile Designator)

    Further details should be added to this section to clarify that the association of a documents with a the IMSC profile designator does not require the presence of the designator in the XML document. Possibly some examples how to associate the designator to a document could be given (e.g. through the use of an metadata element not in TTML namespace). It should be made clear that the use of the ttp:profile attribute is not required.

    ---------------------------------------
    Background
    -------------------------------------

    IMSC says: A subtitle document conforming to the Text Profile SHALL be
    associated with the following profile designator:
    (https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html#text-profile-designator)

    EBU-TT-D does not allow to use the TTML profile element or the profile attribute. The reason why EBU-TT did not include the profile mechanism was that some of the strategies defined by profile mechanisms did not correlate with the EBU-TT requirements, e.g. according to the profile mechanism a processor is required to reject a document if a required feature of an "associated" profile is not supported (regardless if this feature is used in the document or not).
    ' non-public
ISSUE-341 (raised)
  • 2014-08-27 23:59:08:
    *<Glenn Adams> Created issue 'ambiguous definition for determination of descendant region identifier' nickname owned by Glenn Adams on product TTML 1.0, description 'Step 3 of the [association region] procedure in Section 9.3.2 is ambiguous if multiple descendants are associated with a region (possibly distinct).

    Suggest changing from:

    "if the element contains a descendant element that specifies a region attribute, then the element is associated with the region referenced by that attribute;"

    to

    "if the element contains a descendant element that specifies a region attribute, then the element is associated with the first region referenced by that attribute using a breadth-first pre-traversal search of descendant elements;"' non-public

Actions

No actions were modified in this period.


David Singer <singer@apple.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, Chairs, Thierry Michel <tmichel@w3.org>, Philippe Le Hégaret <plh@w3.org>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: changelog.php,v 1.34 2014-02-12 10:08:50 dom Exp $