{minutes} TTWG Meeting 2016-01-07

Thanks all for a productive start to 2016. Minutes from today's meeting can be found in HTML format at http://www.w3.org/2016/01/07-tt-minutes.html

I didn't get around to it but once again congratulations to all who have been involved in developing TTML over the years for the Emmy award.

In text format:


      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

07 Jan 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/01/07-tt-irc


          nigel, glenn, andreas, mike, pierre





     * [3]Topics
         1. [4]This Meeting
         2. [5]Action Items
         3. [6]IMSC CR3 etc
     * [7]Summary of Action Items
     * [8]Summary of Resolutions

   <scribe> scribe: nigel

This Meeting

   nigel: Next week David Ronca from Netflix has agreed to present
   what he couldn't at Sapporo,
   ... so I'd like to propose a 2 hour meeting so we can do that
   and normal business.
   ... i.e. on 14th Jan
   ... For today I propose we look at Actions, IMSC CR3 and issue
   #111 and TTML2 Editorial Actions.
   ... Also as AOB, more on the Emmy award.
   ... Any other AOB?

   group: no AOB

Action Items


   <trackbot> action-451 -- Thierry Michel to Investigate if we
   are required to move to the 2015 process -- due 2015-12-03 --


      [9] http://www.w3.org/AudioVideo/TT/tracker/actions/451

   nigel: The objection deadline passed on the call for consensus
   so we have moved to 2015 process.

   close action-451

   <trackbot> Closed action-451.

   atai2: I pushed some corrections of the drafts relating to
   fonts and mapping and the feature problems reported by Pierre
   and Simon.

   nigel: Please could you review your actions on tracker and if
   there's any update or a move to a github issue add the info and
   mark the action as pending review or closed?

   atai2: Okay, I'll update them.

   nigel: Thanks!

IMSC CR3 etc

   nigel: I'd like us to look at issue #111 if we can - we have a
   good set of people here to talk about this.


     [10] https://github.com/w3c/imsc/issues/111

   glenn: Pierre and I had a talk about this and that resulted in
   a modification to my proposal that would allow me to remove the

   pal: One way is to give control to Glenn on Webex to
   review/edit the solution live?

   nigel: Just checking everyone can see a shared screen?

   group: No objections.

   glenn: [shares screen showing proposal text]
   ... The main objection was that a processor that can work with
   both profiles simultaneously needs to
   ... make a decision on what profile to apply.
   ... Implementors might choose either text or image profile and
   implement only one of them, in which case there's no decision
   ... However if you're implementing a processor that operates in
   a mode that only supports those two profiles then you need to
   make a
   ... decision with one of two answers, either text or image
   profile. Other possibilities I consider out of scope, for
   example a processor that
   ... can handle an arbitrary set of TTML profiles. This document
   is not interested in or defining or discussing that usage in
   the larger context.

   <Zakim> mdolan, you wanted to ask about the premise

   mike: An observation: in the known specification and
   implementations of the predecessor and IMSC 1 the decoders all
   support both
   ... profiles but don't rely on any sort of intermediate Y in
   the train tracks. The external signalling defines one or the
   ... The scenario is an implementation possibility but the issue
   hasn't come up because the switch in the train tracks was
   signalled at a higher level.

   glenn: I account for that internally. I'm dealing with the
   situation where there is no external information, and the
   processor is not
   ... implementing a sniffer and there is no external metadata
   and I'm trying to resolve the ambiguity that in the absence of
   any external
   ... profile metadata or preprocessor that guesses it then there
   is such a fork in the processing path. I only want to deal with
   the fallback
   ... default scenario here.

   mike: In this case, unlike perhaps the other TTML1 profiles,
   it's not the case that IMSC 1 Text and IMSC 1 Image are subsets
   of each other
   ... so treating them like the TTML 1 profiles where that
   processing can be done this is different.

   glenn: I'm not arguing that. I'm interested in 2 kinds of
   processing. For validation if you don't know what kind of
   profile you're validating
   ... with then it's not useful to proceed. I'm addressing a
   presentation processor case where you build a presentation
   engine that can
   ... support both of the two profiles and in doing so makes a
   decision on which profile applies to perform constraint
   processing during the
   ... presentation process. That can be provided externally by
   the document interchange process, using sniffing or envelope or
   context, or
   ... in the absence of that there needs to be a decision made.
   This harks back to the fact that TTML1 and TTML2 both define
   such a fallback
   ... default normatively. In TTML1 it is the DFXP transformation
   profile. TTML2 has a more complex algorithm using the version
   ... and other information and chooses between a default in the
   TTML 1 profile space or a default in the TTML2 profile space.
   ... Both cases define a fallback default.
   ... In that case, I have an implementation that makes such a
   decision, and it's my perception that the specification is
   ambiguous and it
   ... should be possible to define a fallback default like TTML1.

   mike: In TTML1 the fallback is trivial - it's full.

   glenn: That's not the default - it's transformation.

   mike: It's easy because there are no extensions and all
   profiles are strict subsets.
   ... Normally people think about profiles as subsets - in this
   case it's a subset plus extensions so the fallback breaks down
   in this case.

   glenn: TTML1 does support extensions so I don't see how IMSC
   does something different in this regard. The defaulting
   ... doesn't take into account profiles outside its own space -
   you're right there. The only point in having a fallback default
   is to resolve
   ... the specification ambiguity in a formal way. If you leave
   it undefined I perceive that as being a hole in the
   specification, that it says A OR B
   ... and doesn't provide guidance as to making the decision.

   pal: Do you agree that if the image and text profiles were in
   two specifications then that statement would not apply?

   glenn: It wouldn't apply to either of those documents, correct.
   But they are both in the same specification so it is not

   pal: I think it is relevant because it's an artefact of the
   profiles being in the same specification.

   <Zakim> nigel, you wanted to ask why a processor needs to make
   this decision

   nigel: Why would you want to do "constraint processing" here
   given that a processor that can process documents in either
   ... must logically support the union of features needed to
   process all features, so why would you need to make the

   glenn: There are a number of options for what to do and which
   rules to use, depending on which profile is in place. If as
   part of your
   ... presentation process you are paying attention to the
   constraints but not validating for the purpose of aborting if
   not valid, or notifying
   ... the user of problems then you have to pay attention to
   which constraints apply. In some cases the constraints are
   common to both
   ... profiles, such as the use of different metrics, and there
   are per profile constraints defined in §7 and §8.
   ... You need to know which rules apply.

   nigel: I'm confused still - what behavioural differences would
   arise if a non-conformant document were processed?

   glenn: The differences would depend on which profile applied.
   In the absence of any external information then it has to have
   a default.
   ... I made the text profile the default fallback because it
   seemed least likely to be a false positive. The only case is an
   image profile document
   ... that contains no indication that it is an image profile

   mike: I'm still not sure I agree with the premise but I'd like
   to see what you're proposing.

   glenn: Let me take you through it.
   ... [add terminology for single profile processor and multiple
   profile processor]

   pal: I just want to make something clear - the multi-profile
   IMSC processor is one that ONLY supports both IMSC processors
   and no others?

   glenn: Right.

   pal: And nothing else?

   glenn: That's correct. Further down I specified a note that the
   determination of processing of an arbitrary document instance
   not compatible
   ... with either profile definition here is out of scope. It
   wasn't my intent to handle a truly generic processor. That's an
   uber problem that
   ... could be specified elsewhere if we wanted to.

   nigel: What do we do with an SDP-US or SMPTE-TT document that
   in all other respects than the profile indication is IMSC

   glenn: I'll get there.
   ... The #profile feature in §6 as agreed in Sapporo needs to be
   referenced in the defaulting algorithm so I elevated that text
   into this
   ... proposal without any change in it. Where it says [profile
   specification] that's the same text as agreed in Sapporo.
   ... Then the meat of the proposal under the [profile
   defaulting] section describes what a single profile processor
   and multiple profile processor
   ... should do.
   ... [single] - if profile designator doesn't match processor
   profile then document processing may be aborted
   ... [multiple] - too complex rules to summarise in minutes

   mike: A comment: I think the context in a single profile
   processor will be clear - the real issue is for the multiple
   profile processor.
   ... The choice of default to the text profile is not based on a
   good decision tree because the probabilities of text or image
   seem equal.

   glenn: You're correct. You could say it's a random choice, but
   I tried to choose one that I thought would be more likely
   compatible, because
   ... it's more likely compatible with EBU-TT-D. I was trying to
   reduce the number of false positives and negatives and I
   thought the text profile
   ... would do a better job in some scenarios. The case where it
   would be wrong is if a document is image profile and the
   algorithm chooses
   ... to process as a text profile.

   mike: What does "tentatively" mean? Does it imply a SHOULD?

   glenn: I use the term SHOULD to intentionally weaken the
   language and to make it possible for the implementation to make
   more choices.
   ... An implementation could choose the image profile - that
   wouldn't follow the recommendation but would be permitted.
   ... By tentatively I mean that if the wrong decision is made
   then abort would be an option, or retry with the other
   ... When it is processing it is working on a guess.

   atai2: It is strongly recommended to signal the profile or give
   information in the context. You have the probability of making
   the right
   ... choice by using text profile but you have no fact to base
   the decision on.

   glenn: Keep in mind that when it says "compatible with" I tried
   to avoid language that would strictly pin the language to a
   processor profile
   ... as defined in TTML1 because IMSC mixes the specifications
   of content and processor profiles. You're right. The way to
   have this default
   ... apply is to ensure there is some indication of profile, but
   the intent of this language is to encourage it.

   nigel: I can't see behavioural differences for processors based
   on the profile - what practical difference does this make?

   glenn: If you're using vertical writing mode that violates the
   constraints of the image profile - so what should the processor
   do? It can only
   ... decide whether to abort or ignore if it knows the profile.
   I agree there are few explicit normative statements that define
   behaviour. The
   ... only one I can think of off hand is the UAX14 line breaking
   algorithm. The definition of behaviour on non-compliance is
   undefined, which
   ... makes it hard to interoperably test content in my
   estimation. The processor needs an indication of what to do.

   mike: I agree with Andreas, a recommendation or strong
   encouragement to use profile is helpful, and further,
   ... on discovering that it's not a text profile then you should
   try the image profile rather than aborting. I would then
   probably be happy with
   ... this.

   glenn: A strong recommendation to mark or signal externally the
   profile would be fine. I could add that.
   ... On discovering a profile incompatibility switching profile
   - is that what you meant?

   mike: Yes, I think you want to encourage all possible efforts
   to try the correct presentation even if you discover an element
   or attribute that
   ... doesn't fit the profile would be better.

   glenn: If I were to change the note about potentially aborting
   would that help?

   mike: Yes, where "try the other profile" is the preferred

   nigel: We're out of time - I don't think we've handled the
   SDP-US or SMPTE-TT issues.

   glenn: I'll work on this in the meantime and we could maybe
   deal with that next time?

   pal: I'll review the revised proposal. Something I think will
   need to change is the name of the multi profile processor. It
   needs to be
   ... explicit that it supports only those two profiles, e.g. an
   'exclusive multi-profile processor' or something similar.

   nigel: Summarising, we need to review a revised version of this
   and discuss again next week.

   glenn: I will post the proposal as a message to the public

   nigel: Thanks all, I'll close the call now [adjourns meeting]

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [11]scribe.perl version
    1.144 ([12]CVS log)
    $Date: 2016/01/07 16:13:21 $

     [11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

     [12] http://dev.w3.org/cvsweb/2002/scribe/



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.


Received on Thursday, 7 January 2016 16:21:08 UTC