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

{minutes} TTWG Meeting 2017-05-11

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 11 May 2017 16:42:44 +0000
To: Timed Text Working Group <public-tt@w3.org>
Message-ID: <D53A4C00.3F311%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2017/05/11-tt-minutes.html


Apologies for having technical difficulties during the meeting, and thanks Pierre for stepping in and scribing.

In text format:


   [1]W3C

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


                Timed Text Working Group Teleconference

11 May 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/05/11-tt-irc


Attendees

   Present
          dae, Glenn, Nigel, Andreas, Pierre, David_Ronca

   Regrets
          Thierry, Mike

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]This meeting
         2. [5]TTML issue assignment and progress tracking.
         3. [6]TTML1 & TTML2 issues, actions, PRs, editorial
            actions etc
         4. [7]#268
         5. [8]#263
         6. [9]#141
         7. [10]#128
         8. [11]#274
         9. [12]#189
     * [13]Summary of Action Items
     * [14]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

This meeting

   Nigel: [goes through agenda points]. Any other business or
   specific points to raise?

   Pierre: Deprioritise TPAC for this meeting, prioritise TTML
   issues.

   group: [no other business to raise]

   Nigel: Okay, in that case I think we can skip TPAC today unless
   anyone has any
   ... urgent changes to the survey responses listed in the
   agenda.

TTML issue assignment and progress tracking.

   Nigel: Can we timebox this to 15 minutes maximum?
   ... Are there any issues anyone wants to discuss prior to
   taking on?

   Pierre: I plan to start on TTML1 issues.

   Nigel: Do you want to raise any specific issues to work on, or
   deal with them offline?

   Pierre: They're ones that I have already discussed, no need to
   discuss them further
   ... now.

   Dae: Does anyone think any of the unassigned TTML2 issues need
   to be resolved
   ... before wide review?

   Pierre: All of them.

   David_Ronca: Here's an example - a comment about moving Ruby
   into elements.

   Dae: Or #259, which is an editorial assigned, so it might not
   need to be resolved
   ... before wide review.

   Pierre: If they're editorial then we should just deal with
   them. If they need to be
   ... deferred we can do that now. Fixing the document later will
   be more expensive.

   David_Ronca: At this point I think we're trying to target a
   June 30 WR. To reinforce
   ... Pierre's point why can't we just resolve these issues? If
   they can be resolved they
   ... should be resolved. We should try to make WR as clean as
   possible in the next
   ... month and a half.

   Andreas: I also reviewed 50-60% of the issues - there are a lot
   so June is ambitious.
   ... In general I agree with Pierre and David that the HR
   comments on i18n should be
   ... dealt with. I think that any review feedback has to be
   given high priority in general.
   ... If you look at Richard's comments he read the spec very
   carefully and made some
   ... comments so I think we should put the effort in to find a
   solution that the reviewer
   ... is fine with. Apart from that, a lot of Richard's comments
   were about Ruby and
   ... some quite complex issues introduced in TTML2 and from my
   view it certainly
   ... needs Glenn's involvement on those.

   Dae: I looked at all the open unassigned issues and took the
   ones I thought I could
   ... take care of or could resolve before WR. I thought #259 was
   not critical or I could
   ... not handle it. If everyone else took the same approach then
   we can assume that
   ... all the unassigned issues are those that nobody can
   resolve.

   Nigel: No, please do not assign yourself all the issues you
   might be able to handle,
   ... because that just blocks others from taking them on. Assign
   yourself an issue if
   ... you're about to work on it.

   Dae: Well #259 may be deferrable.

   Pierre: I'd like more time to prepare before deciding to defer
   any issues.

   Glenn: I think we should move to considering issues. As to
   #259, which is a question,
   ... we can simply respond to the question (and say yes) and
   close the issue.
   ... I am qualified to deal with all open issues, but my time is
   limited so I have to
   ... prioritise. I agree that if we can resolve all HR comments
   then we should without
   ... it delaying our proposed schedule, but at some point we may
   need to push things
   ... back. It's too early to make a general policy about this.

   Nigel: My original question is: Are there any issues that
   anyone is considering picking
   ... up but wants to discuss?

   Pierre: Not for me.

   Glenn: I can pull my name off issues that I'm not working on
   right at the moment.

   Nigel: That would be helpful.

   Glenn: It was not my intention to prevent anyone else from
   working on them.

   Nigel: Thank you.

TTML1 & TTML2 issues, actions, PRs, editorial actions etc

   Nigel: Thank you Pierre for sending that additional list of
   issues. How we close issues
   ... is we address them with pull requests, so I would like to
   review the open ones
   ... first, to see if we have consensus to merge, and then look
   at the issues next.
   ... By the way Pierre's list was on top of the list that was
   already in the agenda.
   ... There are no open pull requests on TTML1.
   ... There are 2 on TTML2.
   ... They are both related to #271:

   [15]Metadata examples do not include xml:lang (editorial)

     [15] https://github.com/w3c/ttml2/issues/271


   Nigel: Due to comments on Pierre's initial pull request, I
   proposed an alternate
   ... resolution in

   [16]Issue 0271 xml lang metadata examples take 2

     [16] https://github.com/w3c/ttml2/issues/307


   Glenn: I think this is best resolved simply by adding a note to
   ttm:item to say that
   ... xml:lang can be used and doing nothing. The problem with
   the new proposed
   ... examples is that they are not in the language section. Or
   we could put a new note
   ... or section in §8.2.8 xml:lang, where it is already stated
   that you can put it on
   ... metadata vocabulary as a subset of core vocabulary.
   ... Putting a small note in §14.1.6 ttm:item isn't necessary
   because it is explicitly
   ... permitted in the syntax.
   ... I don't know if we need to add anything.

   Pierre: I'm fairly certain that this is already done in the
   text, so the question is how
   ... we can resolve it.

   Andreas: We need to consider that this comes from i18n
   (Addison) so naturally they
   ... are looking at that point and their comment indicates that
   the labelling with
   ... languages of text and content is insufficient and should be
   given higher priority.
   ... So regardless of whether it is actually the core thing
   being talked about in the document
   ... it should be there. Although it is optional it is better to
   give readers clearer signals
   ... to add this information, while on the content element it is
   clearer, for the metadata
   ... it is not that clear and it does not hurt to add that extra
   information. To deal with
   ... this comment it would be good to add this simple example.

   Glenn: There's a very simple reason, which is that it pollutes
   the example. The
   ... examples do not need to be complete. We don't have any
   reason to add a lang
   ... tag to the example. If it helps the reader we can add a
   note to say it could be
   ... placed there if desired.

   Pierre: I'm sympathetic to that argument, but in this case it
   is being responsive

   <atai> +1

   Pierre: without negatively impacting the document.

   Nigel: My comment
   [17]https://github.com/w3c/ttml2/pull/301#issuecomment-29873041

   8
   ... was to add both a note and the examples, and that got a +1
   from the issue
   ... raiser Richard. I can add a note to the PR if that helps.

     [17] https://github.com/w3c/ttml2/pull/301#issuecomment-298730418


   Glenn: I will add a note to the pull request explaining what my
   concern would be.

   Nigel: Thank you.
   ... Does that mean that we have consensus to close with regrets
   Pierre's original
   ... pull request #301?

   Glenn: Sounds good to me.

   Nigel: Is everyone else happy to go with the pull request that
   adds a note and a separate
   ... example?

   group: [silence]

   Nigel: I'll take that as assent.

   <dae> Nigel are you on audio?

#268

   <pal> glenn: CSS3 does not support 'auto'

   <glenn> Group decides to mark as works for me and close without
   action. CSS3 WM does not support an 'auto' value.

   <pal> consensus: WG believes it is not a requirement for TTML2.
   Close as Works For Me.

#263

   <pal> consensus: problem stated by commenter is already
   addressed. Closes as Works for Me.

   <pal> topic #253

   <pal> no objection from the WG to resolution as-is

#141

   <pal> defer until Nigel attends

#128

   <pal> defer until Nigel attends

#274

   <pal> AI: Dae to bug Richard Ishida and Glenn Adams

#189

   <pal> need an assignee

   <pal> glenn: very complex to specify. suggest deferring.

   <pal> atai: new feature request. agree with glenn.

   Nigel: Apologies for the large outage from me, problems here.

   Pierre: #141

   [18]Embedded graphics don't fully meet requirement

     [18] https://github.com/w3c/ttml2/issues/141


   Pierre: Nigel do you agree that the requirement is wrong?

   Nigel: I don't see how it is possible to guarantee that any
   text present is the correct
   ... text. You can require some text to be present syntactically
   or semantically but
   ... the requirement as it's stated goes too far.

   Glenn: Authorial requirements are not supposed to be covered.

   Nigel: I agree it looks like an authorial requirement.

   Pierre: So that cannot be specified.

   Nigel: So the action is to fix the requirement?

   Pierre: I'm concerned about spending any time revising those
   decade old requirements.

   Nigel: I don't have a problem making a point edit to the
   requirements and
   ... revising the spec to match.

   Glenn: I would propose to add a note to Annex M to say that
   those requirements
   ... are not being updated.

   Pierre: I see a hard time updating the group note on
   requirements because that will
   ... require review at least by me.

   Nigel: are you saying we don't need a requirements doc?

   Pierre: No it would have been great to revisit those
   requirements, but now we have
   ... a choice to reopen requirements and go down that path, or
   just say the document
   ... is historical and not necessarily accurate and just move
   on.

   Nigel: I certainly did check back on the requirements probably
   back in 2015, and am
   ... fairly confident that they are mostly correct and relevant.
   ... Is the action now to mark up the annex for this requirement
   to say that although
   ... it is not met fully, add a note that we do not impose
   authorial requirements via
   ... the specification here, so in that sense the requirement is
   not correctly formed.

   Glenn: That would work for me. I don't think we need to produce
   an errata document
   ... for those requirements.

   Pierre: +1
   ... Can I assign this to you Nigel?

   Nigel: Yes you can!

   Pierre: done.

   Nigel: Thank you!

   Pierre: The next one was #128.

   [19]The uniqueness of xml:id needs to be broken for some uses
   of condition

     [19] https://github.com/w3c/ttml2/issues/128


   Nigel: As far as I'm concerned this is a big issue, with
   condition not really being
   ... usable in the way that a lot of people would want to use it
   - it could be a really
   ... powerful feature that is hobbled at the moment. I want to
   make sure that a
   ... workable pattern is clear so that people can use it
   successfully. It looks like that
   ... needs some changes to the way that the <set> element works.

   Glenn: I care about this also.

   Pierre: Can I assign this to you Nigel?

   Nigel: Yes.

   Glenn: I think we need to take this offline.

   Nigel: Ok happy to do that.

   Pierre: The next is #189

   [20]Add support for adjacent background area merging

     [20] https://github.com/w3c/ttml2/issues/189


   Pierre: I think Glenn's position on that is it is very complex
   to specify, and proposes
   ... to defer it.

   Glenn: The proposal is to defer to v.next.

   Nigel: do we have rounded borders now?

   Glenn: This is about background areas, and rounded borders clip
   them.

   Nigel: So we can round backgrounds now?

   Glenn: Yes, we can.
   ... It is not specified what the border radii apply to, so I
   think it is implementation
   ... dependent which of the first three options in
   [21]https://github.com/w3c/ttml2/issues/176#issuecomment-246140

   753
   ... is presented, and any of them could be legal. I don't think
   CSS 3 really helps on
   ... this situation either.

     [21] https://github.com/w3c/ttml2/issues/176#issuecomment-246140753


   Nigel: Okay I need to look at that some more.
   ... I would expect the background on the span to be the thing
   subject to the border
   ... rounding, so the first example would be what is expected.

   Glenn: I wouldn't disagree that may be the case.

   Nigel: One option would be just to remove border-radii - does
   anyone need it?

   Andreas: What is the problem in keeping it?

   Glenn: One resolution of this would be to add two examples,
   with the behaviours

   <atai> +1

   Glenn: with respect to p and span in TTML2. That would be fine
   with me, and then if
   ... we want TTML.next then merging background areas could be a
   follow-on step.

   Nigel: At least the examples will help authors understand what
   they will get, so if
   ... they don't want it then I guess they'll have to lump it.

   Glenn: Would you be prepared to create a PR for this Nigel?

   Nigel: Yes that's fine.
   ... I've added a note to #189.

   Glenn: I've assigned it to you Nigel.

   Pierre: That completes everything we had on the back-burner.

   Nigel: Okay thanks for going through those issues while I was
   off the audio call.
   ... Now how about #224 and #235?

   [22]https://github.com/w3c/imsc/issues/224


     [22] https://github.com/w3c/imsc/issues/224


   [23]https://github.com/w3c/ttml1/issues/235


     [23] https://github.com/w3c/ttml1/issues/235


   Nigel: Sorry for the confusion, let's look at TTML1 #235.

   Pierre: I think in TTML1 the processing is unambiguous so some
   tabs are kept and
   ... there's no definition for what they look like. We could
   recommend that they look
   ... like something, and recommend authors don't use it, but we
   can't do much more.

   Glenn: I've pinged Steve and Tony and they haven't responded.
   So my understanding
   ... is that we're talking about what happens with tabs when
   xml:space="default" and
   ... there's a horizontal tab at the beginning of a line.
   ... Regardless of xml:space the presentation semantics of tab
   are not defined in TTML
   ... - for xml:space="default" it's not clear from XSL-FO if
   that's mapped to space
   ... during the refinement process or not. There are two
   technical questions, one about
   ... the refinement process and the second is if it is not
   mapped to space then what
   ... does it mean for presentation. I agree with Pierre's
   comment that we should
   ... recommend that author's should not use a tab in any case,
   regardless of xml:space.

   Pierre: Yes. and if we want to be helpful, we could recommend
   that processors turn
   ... tabs into spaces which would lead to what most people
   expect I think, in TTML1.

   Glenn: "A preferred way for implementations to handle this is
   blah blah".

   Pierre: That would work for me.

   Andreas: I think the handling of xml:space is specified in
   XSL-FO but the base spec
   ... that defines it is the XML standard itself. Whatever we do
   it needs to be inline with
   ... what the XML standard says.

   Pierre: Would it be inconsistent with XML to recommend weakly
   that implementations
   ... treat tab as space?

   Glenn: This is not to do with the XML spec, perhaps the XSL-FO
   spec, but my position
   ... is that XSL-FO is ambiguous on this.

   Andreas: I will double check that.
   ... If there is an issue I will comment on the proposed
   wording.

   Pierre: Glenn, should we open a pull request for TTML1?

   Glenn: I would suggest opening a pull request with a proposed
   note. I will do that.

   Pierre: I might suggest that in IMSC 1.0.1 we add a note
   pointing to this note in
   ... TTML1.

   Nigel: OK now what about TTML2?
   ... I think the easiest proposal is to say that a tab character
   has no presentation effect
   ... whatsoever.

   Glenn: For TTML2 I would take the TTML1 note and make it
   normative.

   Andreas: Another useful resource for clues about intended
   behaviour is to look at
   ... XSLT (or maybe XPATH), which was part of XSL-FO a long time
   ago.
   ... As far as I can remember if there's no xml:space="preserve"
   the default behaviour
   ... is to normalise tabs to spaces.

   Glenn: XSLT is not formally part of XSL-FO, so the focus should
   be on what XSL-FO
   ... does. If we have time it might be worth looking at what FOP
   and Antenna House
   ... does, but we don't have to do the same as them.

   Pierre: What does CSS do with presentation of tabs?

   Glenn: That's more complicated. After CSS2.1 and later it maps
   a tab to tabstops that
   ... are nominally 8 spaces across. So "xxx[tab]y" means the "y"
   appears 8 spaces across.
   ... I don't think we want to adopt the CSS behaviour.

   Nigel: Can we adopt my proposal that a tab has no presentation
   effect at all?

   Glenn: I would prefer to map to a single space rather than
   nothing, for security
   ... reasons, Invisible content can be used for phishing etc. as
   a general principle.
   ... For example you can create URLs with invisible character in
   them which mislead
   ... the browser user.

   Nigel: Okay, mapping a tab to a single space would work for me.

   Glenn: That would be my default proposal for presenting a tab.

   Pierre: I think we should start there and I'll review.

   Nigel: This needs a new TTML2 issue.

   Glenn: I consider it part of #302. That's supposed to
   incorporate further changes
   ... between TTML1 and TTML2.

   Nigel: I think this sufficiently different from the TTML1 issue
   that it needs a new TTML2 issue.
   ... I will add a note to the TTML1 issue that is currently
   assigned to Glenn, #235.

   <glenn> See
   [24]https://www.w3.org/TR/CSS2/text.html#white-space-model for
   CSS2.1 tab handling rules.

     [24] https://www.w3.org/TR/CSS2/text.html#white-space-model


   Nigel: I'd like to move to the Audio Description requirements.
   Pierre, you made the
   ... point that we as a group have not been through those
   requirements.

   Pierre: I wasn't at the Web and TV IG/TTWG joint meeting. I
   don't really have an
   ... issue with the requirements but in the context of
   distribution I would like to review
   ... that face to face.

   Nigel: OK that sounds like a discussion of a distribution
   profile for AD, which I'd be
   ... happy to add to the agenda at TPAC, but I would also like
   to continue with the
   ... existing TTML2 work.

   Glenn: How I've been drafting it is a neutral addition to the
   existing semantics around
   ... audio inclusion in TTML2 - I have not mentioned audio
   description explicitly.

   Nigel: We're out of time for today, and I see that the audio
   call has dropped off for
   ... some reason too, so let's adjourn until next week.
   [adjourns meeting]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [25]scribe.perl version
    1.152 ([26]CVS log)
    $Date: 2017/05/11 16:14:48 $

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

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






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

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.

---------------------
Received on Thursday, 11 May 2017 16:43:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:40 UTC