Re: Proposed Language for #111 - Revision 5

On Mon, Jan 11, 2016 at 3:58 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> Further comments inline:
>
> From: Glenn Adams <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".
>

Note the qualifier "expressly designed", which I expect will be backed up
by the new suggested section on "Interoperability Goals".


> Also compatible profiles may be created in the future with the intention
> of being compatible with IMSC.
>

Sure, and this might be further addressed in the new suggested section on
"Extensibility Goals".

My intent in introducing this definition is to provide a way to address
your comment about SDP-US, SMPTE-TT, and EBU-TT-D interoperability.


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

I was reluctant to introduce any change to the following text which was
previously found under #profile. The problem is that the following language
was crafted from the perspective of content conformance and not processing
semantics. We could certainly change this to cover both scenarios, or we
could keep this and also define an algorithm for processing conformance.


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

That is not my language, it is merely the existing language in the current
WD having moved it to here. In any case, it is clear that we had not
(previously) delved into the fact that SDP-US requires use of the
ttp:profile element (not @ttp:profile attribute).


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

IMSC overrides certain TTML1 semantics already, so this would be no
different. However I have no strong opinion on how to deal with the SDP-US
case other than to note that it is certainly possible to follow TTML1
semantics in a TTML1 processor while following IMSC semantics in an IMSC
processor (including override semantics).

As it is, IMSC merely recommends presence of @ttp:profile, and doesn't
require it. I suspect that in order to resolve Issue #128 [1], we will have
to permit the presence of the ttp:profiile element in IMSC as an
alternative to @ttp:profile, in which case we would need to alter the above
(existing) language [about profile specification].

[1] https://github.com/w3c/imsc/issues/128




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

Before we consider this, we need to resolve #128.


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

MPIP is defined here as supporting either IMSC-T or IMSC-I or any document
deemed compatible (one that is authored to a "compatible profile"). So, for
processing purposes, an MPIP is processing a document as an IMSC-T or
IMSC-I document, and not as some other document, e.g., not as an SDP-US
processor, not as a SMPTE-TT document, and not as an EBU-TT-D processor
(even if the document is marked as adhering to one of these latter).


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

We could, but that won't address #111 as I have framed it, so let's not go
there.


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

I'm not sure what you are getting at here, but I don't consider this a
productive direction to pursue, as it will not satisfy #111.


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

There may be, but such processors do not satisfy the definition I have
assigned to SPIP or MPIP, so this is out of scope IMO. I'm not interested
in defining some sort of uber-multiple-profile processor concept in the
context of IMSC. Such treatment might be the subject of a new document, but
it would not be appropriate in IMSC.


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

But that is how IMSC is currently defined, so this is a given. I am not
suggesting we change that, and resolving #111 has no bearing on such a
scenario.


>
> 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 depends on the context in which validation/verification occurs. There
are use cases where validation should be required, optional, or prohibited,
and, if validation is performed, there are use cases where the action
should be to abort, to warn, or to ignore warnings/errors.

In some contexts, it makes sense to have a fallback, in others it does not.
In any case, the language above allows a processor to make use of the DIC
(document interchange context), which can be used to prevent the invocation
of the fallback.


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

True, but not relevant to the proposal.


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

It is up to us to determine what goes into IMSC. I have proposed some
additional language in #125 [2], which is not beyond our ability to specify.

[2] https://github.com/w3c/imsc/issues/125


> 2) Conformant to Image profile only.
>

I think you mean conformant to IMSC-I, but not conformant to IMSC-T, which
is not the same as saying conformant to IMSC-I only.


> 3) Conformant to Text profile only.
>

I think you mean conformant to IMSC-T, but not conformant to IMSC-I, which
is not the same as saying conformant to IMSC-T only.


> 4) Conformant to both profiles (which by the way implies the document
> contains no content).
>

Not true in general, since a document might consist only of metadata, e.g.,
a SMPTE-TT document that contains only 608/708 tunneling data, and since
this document can conform to both profiles, then it may contain content,
but not "content presentable by an IMSC presentation processor".s




>
> A processor that both validates and presents concurrently does not have
> the opportunity to use this approach to establish conformance
>

Of course it can. If the fallback default is invoked, choosing IMSC-T, and
the document is compatible with IMSC-T content requirements, then it can
establish conformance. If the document is not compatible with the fallback
default, then it can establish non-conformance (upon the first violation).


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

I don't agree that this is desirable or even necessary. I certainly see no
benefit in doing so. In any case, your earlier proposal to conditionalize
processing to the "presence of an image" is no different than "knowing
which it is in advance". That is, it is doing inline sniffing at run-time.
Doing this is not unreasonable, and is permitted by the language of my
proposed text, but I see no reason to force this type of implementation as
you seem to suggest.


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

Not at all. This is very common form of specification language in both the
Web and the Internet at large.


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

That would serve no purpose, since it is only by indicating priority within
IMSC that the resolution ambiguity is resolved.


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