Re: Proposed Language for #111 - Revision 5

Further comments inline:

From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Friday, 8 January 2016 03:17
The following is revision 5 of my proposed text. I have added language to address the comments received today from Mike and Nigel. Revisions (from what we reviewed in today's meeting) are highlighted.

Add to Section 3:
IMSC Processor. A Processor that supports one or both IMSC Profiles.
Single-Profile IMSC Processor. An IMSC Processor that supports one and only one of the profiles defined in Section 5, namely, the Text Profile or the Image Profile. Multiple-Profile IMSC Processor. An IMSC Processor that supports both of and only the profiles defined in Section 5, namely, both the Text Profile and the Image Profile.

Compatible Profile. A non-IMSC profile with which IMSC is expressly designed to be compatible for the purpose of enhancing

Surely even a profile that is accidentally compatible would be in the class "Compatible Profile". Also compatible profiles may be created in the future with the intention of being compatible with IMSC.

content interoperability. A Document Instance declared or determined to be associated with a Compatible Profile does not violate IMSC defined content constraints with respect to one of the profiles defined in Section 5.
Note: The profiles defined by [EBU-TT-D], [ST2052-1], and [ttml10-sdp-us] are examples of Compatible Profiles.
Create a new Section 5.4, entitled Profile Specification and Processing:

[profile specification]

The references to this section below seem to treat it as an algorithm that returns a value ("is determined by [profile specification]"), however the text does not read that way. If we follow the TTML1SE definition of processing the attributes and elements then EBU-TT-D conformance will not be picked up and the wrong result will be obtained for SDP-US – I explain more below.


The ttp:profile attribute SHOULD be present on the tt element and equal to the designator of the IMSC1 profile to which the document conforms; unless the document also conforms to [EBU-TT-D], in which case the ttp:profile attribute SHOULD NOT be present on the tt element, and instead the designator of the IMSC1 profile to which the document conforms and the URI "urn:eebu:tt:distribution:2014-01"

s/eebu/ebu/

SHOULD each be carried in an ebuttm:conformsToStandard element as specified in [EBU-TT-D].

TTML1SE §5.2 includes:

[[

If a ttp:profile element appears as a descendant of the tt element, then the ttp:profile<http://www.w3.org/TR/ttml1/#parameter-attribute-profile> attribute should not be specified on the tt element. If both a ttp:profile element and attp:profile attribute are present (in a given Document Instance), then the ttp:profile attribute must be ignored for the purpose of determining the declared profile requirements.

]]

The language in the proposal above is recommending that for SDP-US documents (for example) the ttp:profile attribute should be present and have a different value to the SDP-US designator in the ttp:profile element. This takes the opposite recommendation stance to TTML1SE. That is not a conformance problem per se, however TTML1SE does say that the ttp:attribute must be ignored in this case – do we need to clarify that in the case of IMSC it may still be used by a processor? Or do we need to require the appropriate IMSC profile designator to be included within a ttp:profile element if any ttp:profile element is present?

It would also be possible but not sufficient alone to specify that for compatible profile documents the attribute should be omitted unless it is required by the compatible profile.



[profile defaulting]
A Single-Profile IMSC Processor SHALL process a Document Instance in accordance to the single profile which it supports. If a profile is determined by [profile specification] and its value is not equal to the profile designator associated with that single supported profile and is not a Compatible Profile with respect to that single supported profile, then the Document Instance MAY be considered incompatible with that Processor and subject to abort processing. If no profile is determined by [profile specification], then the Document Instance SHOULD be tentatively considered to be compatible with that Processor and subject to normal processing.
A Multiple-Profile IMSC Processor SHALL process a Document Instance in accordance to one of its supported profiles.

I don't think this ("one") is a requirement. The requirement is that conformant document instances conform to one or other profile. The requirement on processors is to process such conformant documents. Further, we should arrange it, if we can, so that it is possible to implement an MPIP that processes conformant document instances of either profile without knowing which profile it is at the beginning. If there are constraints or implications that mean this is not possible we should enumerate those and try to resolve them so there is no mutual incompatibility of this sort between the profiles.

This is not a philosophical point: I expect many implementations, especially in devices like televisions etc. to be targeted at processing incoming documents regardless of which profile they are, and our interoperability goal should be that the presentations by such processors are as similar as possible. If there is some kind of decision point which would result in half those processors producing one presentation and the other half some other differing presentation, that's a problem for us to solve here.

If a profile is determined by [profile specification] and its value is not equal to the profile designator associated with any of the supported profiles and is not a Compatible Profile with respect to any of the supported profiles, then the Document Instance MAY be considered incompatible with that Processor and subject to abort processing. If no profile is determined by [profile specification], and if no external profile metadata is provided by the Document Interchange Context, then the Document Instance SHOULD be tentatively considered to be compatible with the Text Profile and subject to normal processing as such.

I have a problem with offering this fallback for validation processors: validation processors that can validate against both Text and Image profiles should do exactly that; they should validate independently against each profile. It's an implementation issue if that validation process can be executed concurrently in a single pass through the document or if the processor tries each profile in turn, consecutively. Similarly it is an implementation issue if the validation aborts on finding the first error or attempts to find all errors.

The outcome for any given document instance is one of four possibilities:
1) Not conformant to either profile. If the purpose of the validation is to verify that subsequent presentation will be possible then the nature of the errors may be recorded and a decision made on whether or not to attempt presentation. It is beyond the IMSC specification to define this.
2) Conformant to Image profile only.
3) Conformant to Text profile only.
4) Conformant to both profiles (which by the way implies the document contains no content).

A processor that both validates and presents concurrently does not have the opportunity to use this approach to establish conformance: again, if there are reasons why it is not possible to create a processor that can validate and present conformant documents of either profile without knowing which it is in advance then we should enumerate those reasons and see if it is possible to remove them.


In order to avoid the invocation of this [profile defaulting] procedure, content authors and interchange agents SHOULD specify the profile that applies to a Document Instance, by means of either the [profile specification] procedure or external profile metadata, or both. If both internal and external profile metadata is provided and if there is a disagreement between the two designated profiles, then the external profile metadata takes priority.

I'm happy with the intent here, but since we are not defining the external profile metadata it would be dangerous to specify relative prioritisation. All we can say is that the external profile metadata scheme should state which takes priority in the case of a disagreement between the designated profiles.

Note: A Document Interchange Context can obtain external profile metadata by multiple means, including but not limited to: profile parameter data provided by a content container or envelope, using a pre-processor that attempts to guess the applicable profile, etc.

Note: If a Document Instance is considered compatible with a Processor, but is determined to be incompatible, then normal processing may be aborted. As an alternative, a Processor is permitted to restart processing with the Image Profile as the default profile in case an incompatibility is detected and the [profile defaulting] procedure was previously used to select the Text Profile.

Note: The determination and processing of the profile of an arbitrary TTML Document Instance that is not compatible with either Profile defined herein is outside the scope of this specification.

Modify Section 6.10 #profile entry to replace the first paragraph

"The ttp:profile attribute ..."

with the following:

"The constraints and recommendations specified by [profile specification] (see §5.4 above) apply."



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

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.

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