W3C home > Mailing lists > Public > public-tt@w3.org > October 2017

Re: {minutes} TTWG Meeting 2017-10-05

From: Glenn Adams <glenn@skynav.com>
Date: Wed, 11 Oct 2017 23:45:49 -0600
Message-ID: <CACQ=j+f+fy6+qU1nLFknU_u39Z5VQtpp-GZE4MWLSFjzcu=WNA@mail.gmail.com>
To: Pierre-Anthony Lemieux <pal@sandflow.com>
Cc: David Ronca <dronca@netflix.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, Timed Text Working Group <public-tt@w3.org>
On Wed, Oct 11, 2017 at 10:14 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Glenn,
>
> > As currently expressed in TTML2, this is at the option of the implementer
>
> Yes, there will be variations across implementations.
>
> However do you agree that it would be undesirable if, given a document
> that contains only TTML1 syntax, a processor was compelled by the
> TTML2 specification to process differently than it would have been
> compelled by the TTML1 specification. For instance, wouldn't it be
> undesirable if "associate region" algorithm (which is normative in
> both TTML1 and TTML2) would compel an implementation to end-up with a
> different associated region given the aforementioned document?
>
> In order words, can't we set the objective to achieving equivalence on
> those features that TTML1 and TTML2 have in common, given a document
> that contains only TTML1 syntax.
>

I would agree that if a TTML2 processor supports TTML1 documents and
semantics, that it should process a document that is determined to be a
TTML1 document in accordance with TTML1 rules. What I don't know is

   - whether, as currently written in TTML2, there is anything that would
   prevent this behavior while still adhering to TTML2 processor conformance
   [but I'm willing to claim this is an objective; OTOH, I haven't heard
   anyone make a claim there is a specific conflict, which leaves me with the
   conclusion that we don't really know, or at least I don't know, since I
   haven't scoured TTML2 for possible divergence in this scenario];
   - in the absence of a user based directive, what criteria determines
   whether an arbitrary document is designated as a TTML2 or a TTML1 document.

However, in theory, it should be possible to answer both these questions,
or at least come up with an operational answer.


>
> Best,
>
> -- Pierre
>
>
> On Wed, Oct 11, 2017 at 8:33 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> >
> > On Wed, Oct 11, 2017 at 8:33 PM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> Hi David,
> >>
> >> > Adding a significant amount of TTML2 functionality into IMSC1 and
> mixing
> >> > TTML 1 and 2 seems untenable.
> >>
> >> In the current IMSC1.1 draft, all references to TTML1 have been
> >> replaced with reference to TTML2.
> >>
> >> > We need an IMSCvNext profile that is a pure subset of TTML2.
> >>
> >> That remains the objective. In order to achieve it,
> >>
> >> - TTML2 needs to be tweaked to match industry practice and
> >> expectations, e.g. make sure that fillLineGap behaves identically in
> >> TTML2 as it does in IMSC1.0.1 [1].
> >>
> >> - TTML2 has to be a strict superset of TTML1, i.e. given a document
> >> that conforms to TTML1 and does not use any TTML2 features, a TTML2
> >> processor needs to process the document as a TTML1 processor would
> >> have [2].
> >>
> >> [1] https://github.com/w3c/ttml2/issues/429
> >> [2] https://github.com/w3c/ttml2/issues/458
> >
> >
> > I want to point out that we do not yet have WG consensus on either of
> these
> > points, and the second of these has only just been posted and not even
> > discussed by the WG.
> >
> > Nonetheless, I don't see any problem to resolve the first of these, even
> > though, IMO, it sets a bad precedent, namely, allowing extensions in a
> > profile (and, indeed, one not yet deployed, which I claim is the case for
> > IMSC1.0.1) to dictate future directions in TTML proper.
> >
> > As for the second, I responded today on this issue that it is not at all
> > clear what is meant here, let alone reaching a comment agreement. For
> > example, one definition of strict superset is syntactic superset. Adding
> > semantics to this mix pushes it to an entirely different level, and we
> have
> > barely scratched that surface. The question that remains in my mind is
> > whether it is mandatory that every TTML2 processor be a TTML1 processor.
> As
> > currently expressed in TTML2, this is at the option of the implementer,
> and
> > not a criteria for satisfying TTML2 processor conformance.
> >
> >>
> >> Hope this makes sense.
> >>
> >> Best,
> >>
> >> -- Pierre
> >>
> >> On Mon, Oct 9, 2017 at 4:45 PM, David Ronca <dronca@netflix.com> wrote:
> >> >> Given that we're not proposing a pure subset of TTML2 I would propose
> >> >> calling this
> >> >> ... IMSC v1.1, especially since we seem to be targeting IMSC 1
> >> >> compatibility.
> >> >
> >> > Adding a significant amount of TTML2 functionality into IMSC1 and
> mixing
> >> > TTML 1 and 2 seems untenable.  Will a processor have to decide
> >> > feature-by-feature, whether to interpret as TTML1 or TTML2?
> >> >
> >> > We need an IMSCvNext profile that is a pure subset of TTML2. Giving
> it a
> >> > version 1.1 seems to obfuscate the fact that IMSCvNext necessarily
> >> > carries
> >> > significant changes from V1.  Especially WRT JA features.
> >> >
> >> >
> >> > On Thu, Oct 5, 2017 at 9:20 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> >> > wrote:
> >> >>
> >> >> Thanks everyone for attending today's TTWG meeting. Minutes can be
> >> >> found
> >> >> in HTML format at https://www.w3.org/2017/10/05-tt-minutes.html
> >> >>
> >> >> Please note the proposal to publish a FPWD of IMSC v1.1 next week,
> and
> >> >> to
> >> >> publish the IMSC v1.1 requirements.
> >> >>
> >> >> Minutes in text format:
> >> >>
> >> >>    [1]W3C
> >> >>
> >> >>       [1] http://www.w3.org/
> >> >>
> >> >>                 Timed Text Working Group Teleconference
> >> >>
> >> >> 05 Oct 2017
> >> >>
> >> >>    See also: [2]IRC log
> >> >>
> >> >>       [2] http://www.w3.org/2017/10/05-tt-irc
> >> >>
> >> >> Attendees
> >> >>
> >> >>    Present
> >> >>           Nigel, Pierre, Andreas, Mike, Thierry, Glenn
> >> >>
> >> >>    Regrets
> >> >>           Cyril
> >> >>
> >> >>    Chair
> >> >>           Nigel
> >> >>
> >> >>    Scribe
> >> >>           nigel
> >> >>
> >> >> Contents
> >> >>
> >> >>      * [3]Topics
> >> >>          1. [4]This meeting
> >> >>          2. [5]IMSC vNext Issues
> >> >>          3. [6]SMPTE backgroundImage deprecation
> >> >>          4. [7]TTML2 Wide and Horizontal Review
> >> >>          5. [8]IMSC vNext FPWD
> >> >>          6. [9]TTML2 #454 Missing ruby attributes from list of
> >> >>             styling attributes
> >> >>          7. [10]TTML2 #440 Condition attribute missing in Core
> >> >>             catalog.
> >> >>          8. [11]Other TTML2 issues
> >> >>          9. [12]Meeting close
> >> >>      * [13]Summary of Action Items
> >> >>      * [14]Summary of Resolutions
> >> >>      __________________________________________________________
> >> >>
> >> >>    <scribe> scribe: nigel
> >> >>
> >> >> This meeting
> >> >>
> >> >>    Nigel: I haven't had confirmation of whether David or Silvia
> >> >>    will join, so we'll bump WebVTT
> >> >>    ... down the agenda until they join.
> >> >>    ... Today then we have IMSC vNext requirements, TTML2 wide
> >> >>    review comments, and
> >> >>    ... then WebVTT review comments.
> >> >>    ... Anything else to cover, or specific points to raise?
> >> >>
> >> >>    Pierre: I sent an email - suggest getting to FPWD of IMSCvNext
> >> >>    as soon as possible,
> >> >>    ... hopefully by next week so that it can be in time for MPEG.
> >> >>
> >> >>    Nigel: OK got that for the agenda, anything else? I know for
> >> >>    TTML2 we need to think about
> >> >>    ... review comment timing.
> >> >>
> >> >>    Pierre: I'd like to cover Mike's two IMSC issues too.
> >> >>
> >> >>    Nigel: I don't think there's anything to discuss re TPAC so
> >> >>    I'll drop it from today's agenda.
> >> >>
> >> >> IMSC vNext Issues
> >> >>
> >> >>    Pierre: Mike brought up two issues: a) if all IMSC vNext
> >> >>    references should be to TTML2,
> >> >>    ... and if TTML2 is in fact a superset of TTML1 and processing
> >> >>    a TTML1 document with the
> >> >>    ... TTML2 processor will yield the same result.
> >> >>    ... b) deprecation of smpte:backgroundImage - to me that was a
> >> >>    good exercise to try
> >> >>    ... deprecating that.
> >> >>
> >> >>    github: [15]https://github.com/w3c/imsc/issues/258
> >> >>
> >> >>      [15] https://github.com/w3c/imsc/issues/258
> >> >>
> >> >>    Mike: I was concerned that the focus has shifted from being an
> >> >>    extension of IMSC 1.0.1
> >> >>    ... to being a subset of TTML2 and those things aren't
> >> >>    necessarily incompatible but they
> >> >>    ... change the risk profile, so I'd like the group to consider
> >> >>    the choice here. It may be that
> >> >>    ... we have to reference both TTML1 and TTML2, but changing
> >> >>    everything to TTML2 when
> >> >>    ... there's a risk that the processing would change.
> >> >>
> >> >>    Nigel: I've always thought that TTML2 is a superset of TTML1,
> >> >>    and I've never seen anything
> >> >>    ... that made me doubt that.
> >> >>
> >> >>    Pierre: There's a related issue w3c/ttml2#442 requesting that
> >> >>    the scope of TTML2 is
> >> >>    ... defined as a superset of TTML1. For example there are
> >> >>    changes to prose for style resolution.
> >> >>
> >> >>    Glenn: Something to bear in mind is that a TTML2 document will
> >> >>    be processed differently
> >> >>    ... by a TTML1 processor and a TTML2 processor. But more
> >> >>    importantly if a TTML2
> >> >>    ... processor is processing a TTML1 document then its incumbent
> >> >>    on the implementation
> >> >>    ... to behave modally as a TTML1 processor. It's not completely
> >> >>    clear what we're talking about.
> >> >>
> >> >>    Mike: We need to make a fundamental decision that either IMSC
> >> >>    vNext is a superset of
> >> >>    ... IMSC 1.0.1 or a subset of TTML2. Based on what Glenn just
> >> >>    said I'm really concerned here
> >> >>    ... about replacing TTML1 references with TTML2 ones.
> >> >>
> >> >>    Andreas: I think this is really important, that IMSC vNext is a
> >> >>    strict superset of 1.0.1.
> >> >>    ... The question for this superset in the next version of which
> >> >>    version of TTML should be
> >> >>    ... referenced for already present features is not easy to
> >> >>    answer. If we change any TTML1
> >> >>    ... reference to TTML2 that could be a blocker for adoption of
> >> >>    IMSC vNext because all
> >> >>    ... implementers need to check everything that's referenced and
> >> >>    verify that their
> >> >>    ... implementation is still compliant.
> >> >>
> >> >>    Pierre: I thought the goal was to make TTML2 a superset of
> >> >>    TTML1, but are you saying
> >> >>    ... that a TTML2 processor would process a document differently
> >> >>    from a TTML1 processor?
> >> >>
> >> >>    Glenn: Not if it is processing it as a TTML1 processor.
> >> >>
> >> >>    Pierre: What has changed?
> >> >>
> >> >>    Glenn: Lots of things, I'd have to check. Looking at the
> >> >>    version number, treating origin and
> >> >>    ... position if both are present - if processing as a TTML2
> >> >>    document it would use position
> >> >>    ... in preference to origin.
> >> >>
> >> >>    Nigel: I think that's a different question - position would
> >> >>    never be present in a TTML1-only document.
> >> >>
> >> >>    Mike: But other TTML2 properties may be added to a TTML1
> >> >>    document, such as disparity,
> >> >>    ... as has been adopted by ATSC. If the presence of that TTML2
> >> >>    attribute triggers different
> >> >>    ... processing of the whole document than in TTML1 that would
> >> >>    be a worry.
> >> >>
> >> >>    Glenn: It may be that we need to think about this a bit more.
> >> >>
> >> >>    Pierre: I'm happy to back out the TTML2 references and replace
> >> >>    by TTML1 in IMSC vNext,
> >> >>    ... or I'm equally happy to make TTML2 a superset of TTML1.
> >> >>
> >> >>    Glenn: It is a superset in that it supports the features. The
> >> >>    question is which mode is it
> >> >>    ... operating in, either with the knowledge of some fixes
> >> >>    relative to TTML1, or if the author
> >> >>    ... declares that it's a TTML2 document, and puts a version="2"
> >> >>    parameter on it, then the
> >> >>    ... author has said that TTML2 rules should apply.
> >> >>    ... I don't see this as a binary answer.
> >> >>
> >> >>    Mike: In the case of TTML1 vs TTML2 we can sort that out as we
> >> >>    go, but in the case of
> >> >>    ... IMSC vNext it's fundamental. If the intent is backwards
> >> >>    compatible then that's a different
> >> >>    ... thing to "it's compatible with some different behaviours".
> >> >>
> >> >>    Glenn: I agree
> >> >>
> >> >>    Mike: I'm aligned with Andreas that IMSC vNext should be a
> >> >>    superset of IMSC v1.0.1.
> >> >>
> >> >>    Glenn: It may be that when there is an identified difference, I
> >> >>    wonder if we can make a default choice without studying each
> >> >>    case.
> >> >>    ... Absent of information, I would assume that a reference to
> >> >>    TTML1 would be a safer bet
> >> >>    ... than simply adopting references to TTML2 across the board.
> >> >>
> >> >>    Nigel: How does rendering using CSS factor into this, given
> >> >>    that we're putting the mappings
> >> >>    ... from TTML style attributes to CSS informatively into TTML2?
> >> >>
> >> >>    Pierre: If we want to continue referencing TTML1 for processing
> >> >>    behaviours but also add
> >> >>    ... TTML2 features like ruby, then we will have to create new
> >> >>    extension features for that syntax. We
> >> >>    ... can't reference the TTML2 features because that brings the
> >> >>    whole TTML2 processing model.
> >> >>    ... For disparity it's not an issue but for something like Ruby
> >> >>    then it might be an issue.
> >> >>
> >> >>    Nigel: Adding something else into the mix here, we have an
> >> >>    intention to work on TTML1 Third Edition
> >> >>    ... which essentially backports the important fixes to TTML1
> >> >>    Second Edition. Which version
> >> >>    ... of TTML1 do we want to reference in IMSC vNext?
> >> >>
> >> >>    Pierre: Going back to Andreas's suggestion, if we explicitly
> >> >>    state in TTML2 that the
> >> >>    ... processor should process TTML1 documents as TTML1 then we'd
> >> >>    be good right? Why
> >> >>    ... can't we say that?
> >> >>
> >> >>    Nigel: I have no reason not to be able to say that.
> >> >>
> >> >>    Pierre: Can we say in TTML2 that a TTML2 processor should
> >> >>    process a TTML1 document
> >> >>    ... exactly as a TTML1 processor?
> >> >>
> >> >>    Glenn: Yes, that's always been the goal.
> >> >>    ... There are no blanket statements to that effect.
> >> >>
> >> >>    Pierre: Then we have the specific issue here that Mike has
> >> >>    raised - that ATSC allows
> >> >>    ... tts:disparity to be used in a TTML1 document without
> >> >>    specifying ttp:version="2".
> >> >>    ... Could one solution in the case of IMSC vNext be never to
> >> >>    use ttp:version="2" except when
> >> >>    ... using a whitelist of features that are known to affect the
> >> >>    processing model. Or prohibit
> >> >>    ... ttp:version altogether?
> >> >>
> >> >>    Andreas: A question for my understtanding for ttp:version - if
> >> >>    we have a TTML1 document
> >> >>    ... and we add ttp:version="2" the rendered outcome of a TTML1
> >> >>    document would be no
> >> >>    ... different from a TTML1 processor at the moment? That should
> >> >>    not have any effect on the
> >> >>    ... outcome.
> >> >>
> >> >>    Pierre: The particular example that Glenn brought up is
> >> >>    position, if ttp:version="2".
> >> >>
> >> >>    Glenn: More substantively if there's no profile present then
> >> >>    signalling ttp:version="2"
> >> >>    ... causes selection of a different default profile. If it is
> >> >>    missing then the default would be
> >> >>    ... as in TTML1, the old DFXP profiles. However if
> >> >>    ttp:version="2" is present then it would
> >> >>    ... substitute the TTML2 default profiles which bring in new
> >> >>    processor profile defaults.
> >> >>
> >> >>    Pierre: If ttp:version is absent, and a TTML2 processor
> >> >>    encounters a ruby element what does
> >> >>    ... it do?
> >> >>
> >> >>    Glenn: It depends on whether it is processing it as a TTML1 or
> >> >>    a TTML2 document, independently of ttp:version.
> >> >>    ... If it is processing as a TTML1 document then it might
> >> >>    ignore ruby even if it knows how
> >> >>    ... to process ruby. That's an implementation choice. We can't
> >> >>    from a spec perspective
> >> >>    ... mandate the implementation in terms of backward
> >> >>    compatibility in this regard.
> >> >>
> >> >>    Pierre: If we remove ttp:version and let profile signalling
> >> >>    completely drive processing then
> >> >>    ... there would be no ambiguity.
> >> >>
> >> >>    Mike: An IMSC1.0.1 document could add all the vNext features,
> >> >>    and the processor might
> >> >>    ... understand it, then the version becomes critical, because
> >> >>    you're explicitly telling the processor
> >> >>    ... to do something different.
> >> >>
> >> >>    Pierre: In the case of IMSC vNext there would be a profile
> >> >>    identifier so version wouldn't be needed.
> >> >>
> >> >>    Glenn: I disagree. We changed the profile mechanism. The
> >> >>    processor needs to know which
> >> >>    ... profile processing system is being used.
> >> >>
> >> >>    Pierre: The mere presence of ttp:contentProfiles signals that
> >> >>    the new system is being used.
> >> >>    ... The processor can unambiguously identify which TTML version
> >> >>    it would be using.
> >> >>
> >> >>    Glenn: You're suggesting removing ttp:version and adding an
> >> >>    algorithm for deriving the
> >> >>    ... TTML version being used. I don't see that as being any
> >> >>    different.
> >> >>
> >> >>    Pierre: I'm addressing the case identified by Mike that
> >> >>    everyone might start putting ttp:version="2" in the IMSC
> >> >>    documents.
> >> >>
> >> >>    Glenn: That's maybe something that IMSC vNext should say
> >> >>    something about but I see it
> >> >>    ... as a different issue from what is in TTML2.
> >> >>
> >> >>    Pierre: TTML2 requires ttp:version="2" if any TTML2 feature is
> >> >>    used including ttp:contentProfile.
> >> >>    ... That's what the thread has said.
> >> >>
> >> >>    Glenn: No you're overstating it. I said if an author requires
> >> >>    TTML2 processing they can
> >> >>    ... specify it. They can still not do so. If they fail to do so
> >> >>    then it would still provide some sort
> >> >>    ... processing dependent on the implementation. I guess the
> >> >>    question is what should TTML2
> >> >>    ... say regarding documents without ttp:version that do use a
> >> >>    TTML2 feature. My response
> >> >>    ... would be as an implementer, since the author hasn't said it
> >> >>    is required, I would derive it
> >> >>    ... using other methods, for example seeing if contentProfiles
> >> >>    were present. I don't know
> >> >>    ... what you can say about authors blanket putting ttp:version
> >> >>    in the document. Maybe add
> >> >>    ... a big warning saying "If you put ttp:version="2" then that
> >> >>    may cause processing differences in TTMl2 processors compared
> >> >>    to TTML1".
> >> >>
> >> >>    Pierre: What will ATSC signal as the profile in documents with
> >> >>    tts:disparity?
> >> >>
> >> >>    Mike: There's no choice, just IMSC 1.0.1 with the extensions
> >> >>    and with no other signalling.
> >> >>    ... I don't remember if we suggested explicitly stating the
> >> >>    profile.
> >> >>
> >> >>    Pierre: Yes, IMSC, absolutely.
> >> >>
> >> >>    Mike: Ok, but there's no version, or other profile and there
> >> >>    probably never will be. To the
> >> >>    ... extent that IMSC 1 is deployed in the US, nobody believes
> >> >>    that the additions in IMSC vNext are needed.
> >> >>    ... If the additions land somewhere else, in a different
> >> >>    country, what is an ATSC decoder
> >> >>    ... going to do? I don't know, this isn't heading in a good
> >> >>    direction...
> >> >>
> >> >>    Pierre: Imagine an IMSC 1 processor - it would ignore
> >> >>    tts:disparity.
> >> >>
> >> >>    Mike: The ATSC processor would know what to do with it. It was
> >> >>    explicitly agreed by this
> >> >>    ... group that an IMSC processor ignore attributes it doesn't
> >> >>    understand.
> >> >>
> >> >>    Pierre: Now the same document appears in a non-ATSC decoder,
> >> >>    but one that is IMSC vNext,
> >> >>    ... and it is labelled as IMSC v1 and there's no profile, and
> >> >>    it has tts:disparity, are we trying
> >> >>    ... to solve the case of what it does?
> >> >>
> >> >>    Andreas: Isn't the question if we can make IMSC vNext use TTML2
> >> >>    features in a TTML1 processor?
> >> >>    ... If a TTML2 feature is used then the processor must be a
> >> >>    TTML2 processor.
> >> >>
> >> >>    Pierre: It's hard to specify that, is TTML2 processing required
> >> >>    whenever a TTML2 feature is encountered?
> >> >>
> >> >>    Glenn: Here's something to consider: a complicated thing was
> >> >>    introduced in HTML5 - is it compatible with previous
> >> >>    specifications?
> >> >>    ... Probably not. Have implementers verified that it's
> >> >>    compatible with their own implementations?
> >> >>    ... Probably not. It was just defined. We have a similar issue.
> >> >>    We have to go ahead with
> >> >>    ... caution about changes that affect processing in older
> >> >>    processors. I don't know how we
> >> >>    ... check that we don't break compatibility. It's not out
> >> >>    intention to break it, and I don't have
> >> >>    ... a list where we have made that decision either.
> >> >>
> >> >>    Mike: I understand the analogy, I'm not sure it's a good one.
> >> >>
> >> >>    Nigel: It's hard to move from the abstract to the concrete
> >> >>    without any specific examples
> >> >>    ... where a TTML2 processor has a significantly worse
> >> >>    presentation than a TTML2 processor
> >> >>    ... for a TTML1 document.
> >> >>
> >> >>    Pierre: I'm encouraged by Glenn's response that there's no
> >> >>    intention to differ. Glenn, do
> >> >>    ... you have any objection to making a blanket statement in
> >> >>    TTML2 that a TTML2 processor
> >> >>    ... processing a TTML1 document should yield identical results?
> >> >>
> >> >>    Mike: Be careful of the language.
> >> >>
> >> >>    Glenn: TBD the language, but I have no reason to object to
> >> >>    doing so.
> >> >>    ... The question is do we want to introduce extra language. I
> >> >>    think I added a compatibility section.
> >> >>
> >> >>    Pierre: I would add it up front in the scope so the objective
> >> >>    is clear.
> >> >>
> >> >>    Glenn: Putting that in the front matter should be okay. I'm
> >> >>    just going to find the section I think I added.
> >> >>
> >> >>    Andreas: [I have to drop off] I support what Pierre suggested.
> >> >>    It's a good opportunity to
> >> >>    ... start the IMSC requirements and to keep the backward
> >> >>    compatibility, which means that
> >> >>    ... a TTML2 feature being used in an IMSC vNext processor would
> >> >>    not change any TTML1
> >> >>    ... features used in IMSC.
> >> >>
> >> >>    Glenn: I added §3.4 under conformance, and it has forward and
> >> >>    backward sections. It is
> >> >>    ... marked as non-normative but says things along the lines of
> >> >>    what we're talking about.
> >> >>
> >> >>    Mike: The conformance is one angle - it's important that a
> >> >>    presentation processor also
> >> >>    ... does the same thing.
> >> >>    ... Currently all the language is about conformance of
> >> >>    documents as opposed to rendering.
> >> >>    ... Let's work on the language a bit - I'll take a run at it.
> >> >>
> >> >>    Glenn: It's §3.4 in TTML2.
> >> >>    ... I recall we had a look at this in the past for TTML2 too.
> >> >>
> >> >>    SUMMARY: Mike to study TTML2 §3.4 and propose any
> >> >>    modifications.
> >> >>
> >> >> SMPTE backgroundImage deprecation
> >> >>
> >> >>    Nigel: We should defer discussing this.
> >> >>
> >> >>    Pierre: Maybe a public document would help also.
> >> >>
> >> >> TTML2 Wide and Horizontal Review
> >> >>
> >> >>    Thierry: I went through the archives and verified all the
> >> >>    comments sent in are there plus
> >> >>    ... I've added some sent as liaisons. They're all on GitHub.
> >> >>    Some issues don't need any
> >> >>    ... processing - if they say everything is fine. I still put
> >> >>    them on GitHub so they will be on
> >> >>    ... our disposition of comments. All the comments have a label,
> >> >>    open, pending, etc. When
> >> >>    ... the issue status changes we will add a new label.
> >> >>
> >> >>    Nigel: Fantastic, thanks for that - a lot of work.
> >> >>
> >> >>    Action-506?
> >> >>
> >> >>    <trackbot> Action-506 -- Thierry Michel to Draft a wiki page
> >> >>    explaining our review and disposition steps and labels -- due
> >> >>    2017-09-21 -- OPEN
> >> >>
> >> >>    <trackbot>
> >> >>    [16]http://www.w3.org/AudioVideo/TT/tracker/actions/506
> >> >>
> >> >>      [16] http://www.w3.org/AudioVideo/TT/tracker/actions/506
> >> >>
> >> >>    close action-506
> >> >>
> >> >>    <trackbot> Closed action-506.
> >> >>
> >> >>    Nigel: There were a number of issues that said thank you, they
> >> >>    would look at TTML2 but
> >> >>    ... not before 30th September.
> >> >>
> >> >>    Thierry: If you agree I would take the action to write to them
> >> >>    to say we will process their
> >> >>    ... comments but they should send them ASAP after their
> >> >>    meetings.
> >> >>
> >> >>    Pierre: I recommend to do nothing, and process them when they
> >> >>    come in, and put them
> >> >>    ... in a queue.
> >> >>
> >> >>    Thierry: I've had comments come in 6 months late in the past
> >> >>    and the Director still wants
> >> >>    ... to take them into account.
> >> >>    ... I want to add a bit of pressure.
> >> >>
> >> >>    Pierre: They know how this works, I would say nothing!
> >> >>
> >> >>    Nigel: I'm happy to do nothing - they've told us they will do
> >> >>    something and we should assume that they will do so.
> >> >>    ... I just wanted to check if we want to explicitly extend the
> >> >>    deadline.
> >> >>
> >> >>    Pierre: I would not.
> >> >>
> >> >>    Thierry: I would not.
> >> >>
> >> >>    Glenn: I agree, the deadline has passed. I would not put those
> >> >>    in as wide review comments anyway, they're not comments about
> >> >>    the spec.
> >> >>
> >> >>    Nigel: The point at which we draw a close to the wide review
> >> >>    opportunity is when we
> >> >>    ... have agreed to request transition to CR.
> >> >>
> >> >>    Thierry: Correct.
> >> >>
> >> >>    Mike: Would it help to track comments as late and put them at
> >> >>    the bottom of the pile?
> >> >>
> >> >>    Pierre: I like that, a priori put them at the bottom of the
> >> >>    pile unless we all see that it's a big
> >> >>    ... issue.
> >> >>
> >> >>    Nigel: Okay this is all fine for me, thanks everyone, we don't
> >> >>    need to take any action at all here.
> >> >>    ... We simply need to come up with a disposition for every
> >> >>    substantive comment.
> >> >>
> >> >>    Thierry: Some issues are marked as editorial - we should have a
> >> >>    type label for editorial vs substantive.
> >> >>
> >> >>    Nigel: That works for me.
> >> >>    ... I think in the old tracker there was a flag for exactly
> >> >>    that.
> >> >>
> >> >>    <scribe> ACTION: Thierry Check if there are
> >> >>    editorial/substantive labels for TTML2 issues and add if not.
> >> >>    [recorded in
> >> >>    [17]http://www.w3.org/2017/10/05-tt-minutes.html#action01]
> >> >>
> >> >>      [17] http://www.w3.org/2017/10/05-tt-minutes.html#action01
> >> >>
> >> >>    <trackbot> Created ACTION-508 - Check if there are
> >> >>    editorial/substantive labels for ttml2 issues and add if not.
> >> >>    [on Thierry Michel - due 2017-10-12].
> >> >>
> >> >>    Nigel: Between now and next week please could everyone look at
> >> >>    the GitHub issues and
> >> >>    ... propose any dispositions, so that we can start to agree
> >> >>    them in next week's meeting, or
> >> >>    ... at any rate discuss them?
> >> >>
> >> >>    Glenn: I've already addressed a couple of TTML2 issues, so if
> >> >>    we can get resolution on those
> >> >>    ... today then I would be happy to close something.
> >> >>
> >> >> IMSC vNext FPWD
> >> >>
> >> >>    Pierre: I propose a 1 week review of the draft and the
> >> >>    requirements document, which go
> >> >>    ... hand in hand, and I keep synchronised. If there are no
> >> >>    major objections publish as a FPWD
> >> >>    ... and send a liaison informing them of the beginning of this
> >> >>    work and inviting them to provide comments.
> >> >>
> >> >>    Nigel: What's the URL of the thing we're discussing?
> >> >>    ... I see that IMSCvNext is not on the master branch of the
> >> >>    imsc repo.
> >> >>    ... Can we put IMSC vNext in a new folder so we don't get a
> >> >>    clash of URIs?
> >> >>
> >> >>    Pierre: I didn't do that because then I'd have to synchronise
> >> >>    IMSC 1.0.1 changes with
> >> >>    ... vNext. Also we haven't got a name for it yet.
> >> >>
> >> >>    <pal>
> >> >>    [18]https://rawgit.com/w3c/imsc/6eafca943b2294d2d2d979960981429
> >> >>    9e4b361cf/imsc1/spec/ttml-ww-profiles.html
> >> >>
> >> >>      [18]
> >> >>
> >> >> https://rawgit.com/w3c/imsc/6eafca943b2294d2d2d97996098142
> 99e4b361cf/imsc1/spec/ttml-ww-profiles.html
> >> >>
> >> >>    Nigel: Given that we're not proposing a pure subset of TTML2 I
> >> >>    would propose calling this
> >> >>    ... IMSC v1.1, especially since we seem to be targeting IMSC 1
> >> >>    compatibility.
> >> >>
> >> >>    Pierre: That's what I'm thinking too.
> >> >>
> >> >>    Nigel: In that case I think we need an imsc1_1 folder.
> >> >>
> >> >>    Pierre: I really would like to delay that as much as possible.
> >> >>    Once it's published on /TR
> >> >>    ... it doesn't really matter where it is in the repo.
> >> >>
> >> >>    Nigel: It makes it really awkward to navigate though. When
> >> >>    would you move it to a different folder?
> >> >>
> >> >>    Pierre: I think it will become obvious.
> >> >>
> >> >>    Nigel: We're not really expecting any changes to 1.0.1
> >> >>
> >> >>    Pierre: Compare with software development - you'd maintain
> >> >>    different versions on different branches.
> >> >>    ... Here all the tests, examples etc are going to be
> >> >>    substantially the same.
> >> >>
> >> >>    Nigel: The other thing you'd do is use release tags.
> >> >>    ... Okay, Pierre, you proceed as Editor.
> >> >>
> >> >>    Pierre: Can you request a short name?
> >> >>
> >> >>    <tmichel>
> >> >>    [19]https://lists.w3.org/Archives/Public/spec-prod/2017JulSep/0
> >> >>    005.html
> >> >>
> >> >>      [19]
> >> >> https://lists.w3.org/Archives/Public/spec-prod/2017JulSep/0005.html
> >> >>
> >> >>    Thierry: Yes I will. Just to let you know there's a new rule as
> >> >>    per the above link, and it
> >> >>    ... would be worth Editors looking at this.
> >> >>
> >> >>    Nigel: This is a convention for Latest Version links, mainly.
> >> >>    ... Thanks for the reminder Thierry, I had seen that and not
> >> >>    taken any action.
> >> >>
> >> >>    <pal> ttml-imsc1.1
> >> >>
> >> >>    PROPOSAL: Publish a FPWD of IMSC v1.1 with the short code
> >> >>    ttml-imsc1.1, based on the ED in the IMSCvNEXT branch
> >> >>
> >> >>    Pierre: Would you like me to propose liaison text?
> >> >>
> >> >>    Nigel: Yes please
> >> >>
> >> >>    <scribe> ACTION: pal Propose liaison text for the IMSC 1.1 FPWD
> >> >>    [recorded in
> >> >>    [20]http://www.w3.org/2017/10/05-tt-minutes.html#action02]
> >> >>
> >> >>      [20] http://www.w3.org/2017/10/05-tt-minutes.html#action02
> >> >>
> >> >>    <trackbot> Created ACTION-509 - Propose liaison text for the
> >> >>    imsc 1.1 fpwd [on Pierre-Anthony Lemieux - due 2017-10-12].
> >> >>
> >> >>    action-507?
> >> >>
> >> >>    <trackbot> action-507 -- Nigel Megitt to Add imsc vnext repo to
> >> >>    agenda, board, github-bot etc -- due 2017-10-05 -- OPEN
> >> >>
> >> >>    <trackbot>
> >> >>    [21]http://www.w3.org/AudioVideo/TT/tracker/actions/507
> >> >>
> >> >>      [21] http://www.w3.org/AudioVideo/TT/tracker/actions/507
> >> >>
> >> >>    Nigel: I link from the agenda to
> >> >>    [22]http://www.w3.org/AudioVideo/TT/board/
> >> >>    ... Has anyone here ever followed that link and looked at it?
> >> >>
> >> >>      [22] http://www.w3.org/AudioVideo/TT/board/
> >> >>
> >> >>    Pierre: I have not.
> >> >>
> >> >>    Thierry: No.
> >> >>
> >> >>    Nigel: Does anyone use it?
> >> >>
> >> >>    Pierre: I didn't realise it existed
> >> >>
> >> >>    Nigel: The reason I ask is that if nobody uses it then I will
> >> >>    drop it; conversely I could maintain it.
> >> >>
> >> >>    Thierry: I think it's valuable. I did use it some times, I
> >> >>    recall, but I'd forgotten about it.
> >> >>
> >> >>    Nigel: Okay I'll update the board and continue with it.
> >> >>
> >> >> TTML2 #454 Missing ruby attributes from list of styling attributes
> >> >>
> >> >>    github: [23]https://github.com/w3c/ttml2/issues/454
> >> >>
> >> >>      [23] https://github.com/w3c/ttml2/issues/454
> >> >>
> >> >>    Glenn: This was an editorial change, I've already fixed it and
> >> >>    updated the ED.
> >> >>    ... I guess we can change the status of this with labels. It's
> >> >>    done.
> >> >>
> >> >>    Nigel: I see, there's nothing significant to review here -
> >> >>    Thierry do you want to apply the
> >> >>    ... appropriate labels?
> >> >>
> >> >>    Thierry: Yes, it's spec updated and WG approved.
> >> >>
> >> >>    Nigel: I've assigned it to you Thierry.
> >> >>
> >> >> TTML2 #440 Condition attribute missing in Core catalog.
> >> >>
> >> >>    github: [24]https://github.com/w3c/ttml2/issues/440
> >> >>
> >> >>      [24] https://github.com/w3c/ttml2/issues/440
> >> >>
> >> >>    Glenn: This is from Andreas and he's reviewed to say it looks
> >> >>    good.
> >> >>
> >> >>    Nigel: Okay I'm assigning to Thierry to update the labels.
> >> >>
> >> >>    Thierry: Once we have all three of: WG resolution + spec
> >> >>    updated + commenter agreement
> >> >>    ... we can close issues.
> >> >>
> >> >>    Glenn: What if we cannot get agreement from the commenter, do
> >> >>    we have to leave issues
> >> >>    ... as open if we have disagreement?
> >> >>
> >> >>    Thierry: We can close issues but it will red flag to the
> >> >>    Director that we will have to explain
> >> >>    ... to the Director.
> >> >>
> >> >>    SUMMARY: WG approves, Thierry to update labels
> >> >>
> >> >> Other TTML2 issues
> >> >>
> >> >>    Glenn: We haven't discussed XML, CSS comments etc.
> >> >>
> >> >>    Pierre: I would like to close those issues off, so can we
> >> >>    schedule a time to do so?
> >> >>
> >> >>    Nigel: Sure, if we cannot resolve it on the GitHub issue.
> >> >>    ... We have discussed over the years some issues about time,
> >> >>    mediaOffset, and begin and
> >> >>    ... end clipping, which I want to resolve soon too.
> >> >>
> >> >>    Glenn: Check if there are existing issues.
> >> >>
> >> >>    Nigel: Will do.
> >> >>
> >> >> Meeting close
> >> >>
> >> >>    Nigel: Thanks everyone, we've done what we could on the agenda.
> >> >>    [adjourns meeting]
> >> >>
> >> >> Summary of Action Items
> >> >>
> >> >>    [NEW] ACTION: pal Propose liaison text for the IMSC 1.1 FPWD
> >> >>    [recorded in
> >> >>    [25]http://www.w3.org/2017/10/05-tt-minutes.html#action02]
> >> >>    [NEW] ACTION: Thierry Check if there are editorial/substantive
> >> >>    labels for TTML2 issues and add if not. [recorded in
> >> >>    [26]http://www.w3.org/2017/10/05-tt-minutes.html#action01]
> >> >>
> >> >>      [25] http://www.w3.org/2017/10/05-tt-minutes.html#action02
> >> >>      [26] http://www.w3.org/2017/10/05-tt-minutes.html#action01
> >> >>
> >> >> Summary of Resolutions
> >> >>
> >> >>    [End of minutes]
> >> >>      __________________________________________________________
> >> >>
> >> >>
> >> >>     Minutes formatted by David Booth's [27]scribe.perl version
> >> >>     1.152 ([28]CVS log)
> >> >>     $Date: 2017/10/05 16:17:51 $
> >> >>
> >> >>      [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
> scribedoc.htm
> >> >>      [28] http://dev.w3.org/cvsweb/2002/scribe/
> >> >>
> >> >>
> >> >
> >>
> >
>
Received on Thursday, 12 October 2017 05:46:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:44:20 UTC