- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 1 Mar 2018 17:20:43 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <D6BDE413.56300%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/2018/03/01-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
01 Mar 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/03/01-tt-irc
Attendees
Present
Philippe, Glenn, Pierre, Nigel, Andreas
Regrets
Thierry
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TTML1 3rd Ed CR
3. [6]TTML2
4. [7]Profile related features should be optional
ttml2#683
5. [8]IMSC
6. [9]APA comment: align altText restrictions with HTML
alt attribute imsc#321
7. [10]APA comment: richer semantic layers than
forcedDisplay allows imsc#320
8. [11]APA comment: permit font related features in Image
profile imsc#319
9. [12]APA comment: specify association between image and
text profile documents imsc#318
10. [13]APA comment: Meet WCAG SC 1.4.1 requirement
imsc#317
11. [14]APA comment: presentation customisation imsc#316
12. [15]APA comment: Improve introduction imsc#315
13. [16]Should the character sets be minimum *font*
requirements? imsc#236
14. [17]Charter
15. [18]Meeting close
* [19]Summary of Action Items
* [20]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: Today we have TTML1 3rd Ed CR, TTML2, IMSC - general
actions and issues.
... There are one or two issues/pulls marked for Agenda.
Glenn: I'd like to raise a question on TTML1 about what we
should call the CR.
<plh>
[21]https://w3c.github.io/transitions/nextstep.html?shortname=t
tml1
[21] https://w3c.github.io/transitions/nextstep.html?shortname=ttml1
Philippe: It's just "CR".
Glenn: Pubrules has "First Public CR", which I selected for
TTML2 last night, which worked,
... whereas I noticed that Pierre just used "Candidate
Recommendation" for TTML1 3rd Ed,
... so we should be consistent.
Philippe: I agree.
... I think FPCR is for a CR without a WD. That's not the case
for TTML1, which should just be "CR".
Nigel: Anything else for the agenda?
group: [silence]
Philippe: Is Charter on the agenda?
Nigel: Not right now.
Philippe: Can we touch base on it at the end?
Nigel: Yes
TTML1 3rd Ed CR
Nigel: What's the status of TTML1 3rd Ed?
Pierre: All substantive issues have been resolved, and all
that's left open are editorial issues.
... I think we're ready to publish as CR - we should plan on
publishing in 2 weeks,
... merging editorial issues today and starting the 2 week
clock.
Nigel: Makes sense to me. I added this to the agenda:
PROPOSAL: transition to CR of TTML1 3rd Edition based on build
available at
[22]https://rawgit.com/w3c/ttml1/TTML1-3ED-CR1-build/index.html
[22] https://rawgit.com/w3c/ttml1/TTML1-3ED-CR1-build/index.html
<plh>
[23]https://www.w3.org/Guide/transitions?profile=CR&cr=rec-upda
te
[23] https://www.w3.org/Guide/transitions?profile=CR&cr=rec-update
Philippe: You're not adding features, but you are making
substantive changes?
Nigel: Correct
Philippe: I posted a link to the transition requirements for
that, above
... You don't have to publish a WD, you go directly to CR.
... It could be pretty fast, in general the expectation is that
you're ready to move out of CR
... when you enter CR, because you're just folding errata into
the document. In terms of
... Wide Review, you've published errata already, or you prove
that you have had the right
... people looking at the errata. It should be a pretty short
CR period, 20 days, and after
... 20 days you would go directly to PR.
Nigel: In this case it seems sensible to avoid a test suite and
implementation report but
... instead to point to existing implementations that already
exhibit the behaviour being
... clarified by the substantive changes.
Philippe: Yes that's right, the expectation is that there are
already implementations.
... You need to back this up with some facts, could be based on
tests or on something else.
... The Directors won't mind what you use. You would need to
provide evidence such as
... an implementer report saying that they already do it.
... There is a desire to make it very easy to update Recs to
make them reflect reality.
Pierre: I believe IMSC.js already matches the proposed 3rd Ed.
Glenn: Same for TTT.
Philippe: Record that in the minutes and you can point the
Director to it.
Nigel: Done!
... We have 4 open pull requests, two editorial, and one that
brings in the 2nd Ed errata,
... and a final one to generate a CR version.
Philippe: You don't need to resolve the issues to publish as
CR, they can be made at PR.
Nigel: I'm going to propose that we merge the open pull
requests, and resolve to publish
... as CR.
Pierre: I'll take care of the merges.
Nigel: Thank you.
Glenn: No problem.
RESOLUTION: After merging the currently open pull requests,
request transition of TTML1 3rd Ed to CR.
Philippe: A reminder: you can publish a new Rec any time if the
changes are only editorial.
Nigel: Good to know.
Glenn: I was reviewing the status - I notice that the link to
the implementation report doesn't
... point to anything.
Nigel: Following the discussion above, we need to modify pull
#343 so we do not point to
... an implementation report but instead will demonstrate that
the updates reflect current
... practice by reference to existing implementations.
... Do we need to be clearer about the exit criteria?
Philippe: You're already asserting that you've met exit
criteria by that statement.
Nigel: And the earliest exit date?
<plh>
[24]https://w3c.github.io/spec-releases/milestones/?cr=2018-03-
15&noFPWD=true
[24] https://w3c.github.io/spec-releases/milestones/?cr=2018-03-15&noFPWD=true
Philippe: 28 days from publication, which would be April 26th
and Rec on May 31 based
... on publication on 15th March. You need to send your
transition to PR request no later
... than April 19.
<plh> Deadline for comments: April 12, 2018
Pierre: I'll replace the exit criteria line and earliest exit
date according to what I see here.
Nigel: Anything else on TTML1?
Pierre: No, thanks for your help on this.
Philippe: Anything I can do to make it easier!
Glenn: Thank you Pierre for your editing work
TTML2
Nigel: We have one agenda topic for today:
github: [25]https://github.com/w3c/ttml2/issues/683
[25] https://github.com/w3c/ttml2/issues/683
github-bot, end topic
Profile related features should be optional ttml2#683
github: [26]https://github.com/w3c/ttml2/issues/683
[26] https://github.com/w3c/ttml2/issues/683
Glenn: This is a CR2 issue, so we don't have to resolve it
today. In TTML1 we did require
... support for the profile mechanism in all conformant
processors, which included all the
... related syntax and semantics.
... My position is that we should have the same level of
mandate for TTML2 upgraded to
... the TTML2 level of semantics particularly the introduction
of the new contentProfiles
... and processorProfiles attributes. I agree that there may be
some aspects of how it is
... currently defined in terms of features that would allow us
to take out a couple of those
... features, such as authorial ways of specifying
combinatorial methods. As long as the
... default semantics for those parameters are implemented as a
default scenario then I can
... see scaling back what #profile-version-2 means.
... As to the issue of whether a profile is mandated now, I was
referring to a conversation we
... had about the version parameter, if there was a requirement
for some version 2 feature,
... I remember a fairly unanimous position by the WG that all
documents should specify
... profile, which I agreed with. Although I agree we did not
translate that to normative
... language in the spec that mandates a profile attribute be
present, because we have a
... defaulting mechanism. We may need to revisit that as an
issue in CR2, if it is mandatory
... for a document instance to specify a profile. I'm flexible
no that right now.
... I definitely think that TTML2 should have similar parity to
TTML1 with the requirement
... for contenrProfiles and processorProfiles attributes. If we
let implementations have a
... free pass on that it doesn't accomplish our goals.
Pierre: Is there one of those features that specifically
requires the profile processing
... algorithm including the defaulting? As long as that's
required then we're good.
... TTML2 has really improved the profile derivation algorithm.
Glenn: The way that those semantics are written, it does not
require a processor that
... supports profiles to dereference and parse a specified
profile document, in case it might
... not be available. Is it legitimate for a processor to
completely ignore an embedded profile
... in a document though? My current position is that is not
permissible, it should at least
... acknowledge and implement the semantics of profile if a
required feature is not supported.
Pierre: Your argument is if you don't mandate say the
contentProfiles features as part of
... the transformation profile then by default it doesn't
matter what someone write in there?
Glenn: Exactly.
... At the baseline, recognising the semantics of the default
is the baseline, but on top of
... that we at least need to follow TTML1 for support for
embedded profiles.
Pierre: These are required only in the baseline transformation
and presentation profiles.
Glenn: Any processor in TTML terms that ignores an internal
profile is not a conformant processor.
... On the other hand if the document points to an external
profile the processor could avoid
... getting it and then be conformant.
Pierre: IMSC 1 has prohibited those internal profiles.
Glenn: Then you're okay. SMPTE-TT does allow them.
Pierre: There's a way to bypass the profile mechanism, which is
what a hypothetical
... processor would do if it did not support profiles because
of knowledge embedded in the
... document processing context.
Nigel: That's my concern, that a TTML2 processor that does not
implement profile features
... might not be considered a TTML2 processor.
Glenn: Maybe with some notes we can finagle this so that a
processor that always does
... an override is not deemed non-compliant.
SUMMARY: Add informative text explaining how a processor that
does not support the "required" profile features can
nevertheless be considered a conformant TTML2 processor.
IMSC
Nigel: There are 8 issues marked for "agenda", 7 of which
relate to yesterday's joint call with APA.
[27]The minutes of the APA call
[27] https://www.w3.org/2018/02/28-apa-minutes.html
Nigel: Effectively we discussed only one issue, and I got the
feeling that the others are not
... considered so important, but Janina did say she would go
back and check them.
Pierre: That was my feeling as well.
Nigel: The main concern was that the spec should not prevent
implementations from
... allowing some kinds of customisation or adaptation for
accessibility needs, with the example
... provided being increasing the font size.
... I think we took an action to add informative text.
Pierre: Specifically to link to the MAUR, pointing authors and
implementers to that spec.
Andreas: I'm not sure if this belongs in IMSC, TTML or any of
the specifications. I agree with
... some of the comments from yesterday, that for an
implementer, some guidance about
... achieving e.g. customisation of font size with TTML or IMSC
is useful. It is not completely
... arbitrary what kind of customisation is needed - mostly
font size, colour and background colour.
... Possibly not in that spec but in some customisation
guidance you could point implementers
... to a strategy how to achieve that and what to take care
about. For example for font size
... you need to ignore any kind of specified font size and
apply just one to all of the elements.
... I'm not sure at the moment how this should look concretely,
but I'm sure we could help
... implementers to achieve such a feature.
Nigel: It is difficult when the problem space is open ended and
so is the authoring practice.
Glenn: That's in the document processing context in TTML1. I
know Mike was in agreement with that
... following analysis of the US requirements at that time.
Pierre: In the US there are legal requirements.
... As I mentioned it would be incredibly helpful for someone
to do some analysis of the
... global requirements. I'm fairly convinced that neither IMSC
nor TTML is the right place
... to do that. The APA group is better placed to take that on.
Andreas: I do not completely agree here - the regulation is
diverse, but I think you will find
... font size in nearly all the customisation requirements that
exist. Some hints about what
... you should take care about can be given by the spec.
... For example you need to know that regions don't dynamically
grow with font size, which
... may be different in TTML to other specs . How you customise
based on TTML is something
... we can help with.
Glenn: I'm sceptical but I suppose it doesn't hurt to look at
it yet again.
... The document processing context can determine anything out
of the author's knowledge.
... Screen readers have very different formatting requirements
from CSS based browsers.
Pierre: Andreas's very specific point is something we can act
on - it is useful not just for
... accessibility but for any author. We can just file that as
an issue and deal with it.
... That's very different to the generic question of how to
deal with customisation to satisfy
... various regulatory and user preference. As someone
mentioned yesterday, one possible
... solution is to show the subtitles on a different device,
which is done in cinemas. The
... broader question of customisation - I'm more than sceptical
that we can solve this.
... I'd like to know if the WG approves of the draft
disposition I've added to the issues.
APA comment: align altText restrictions with HTML alt attribute
imsc#321
github: [28]https://github.com/w3c/imsc/issues/321
[28] https://github.com/w3c/imsc/issues/321
Nigel: There's an outstanding question which we didn't cover
yesterday.
Pierre: Rather than the HTML alt attribute where the
recommendation is for it to be present
... even if it is empty, we took a different route. I don't see
the need to change anything here.
... In addition, ittm:altText is deprecated so if there's
something to improve it should be done
... in TTML2. My recommendation is to dispose to make no change
or reject.
Nigel: Any other views?
Glenn: Are there two different altText attributes, one in itts:
and one in ittm:?
Pierre: No that was a mistake.
Glenn: We went a different route to HTML, we're saying it's
metadata and there is no
... semantic processing requirement.
Pierre: Importantly it is not equivalent to HTML. alt is
mandatory in HTML but can be empty.
... Here we say that it can be omitted if there's nothing to
say. I think that's functionally
... equivalent, so there's no need to change anything.
... The spec already notes that it is _not_ the same as HTML
alt.
Nigel: Is anyone proposing a change to the spec in response to
this issue?
group: [no]
RESOLUTION: The WG disposes that `ittm:altText` is not
equivalent to HTML5 `@alt`. Whereas HTML5 `@alt` is required
but allows empty values, `ittm:altText` is absent when there is
no value. `ittm:altText` is deprecated and specified only for
backwards compatibility; it is replaced by the altText named
metadata item in TTML2.
APA comment: richer semantic layers than forcedDisplay allows
imsc#320
github: [29]https://github.com/w3c/imsc/issues/320
[29] https://github.com/w3c/imsc/issues/320
Pierre: I have proposed to defer to IMSCvNext, and my comment
can be used as the disposition.
Nigel: that's
[30]https://github.com/w3c/imsc/issues/320#issuecomment-3635297
05?
[30] https://github.com/w3c/imsc/issues/320#issuecomment-363529705
Pierre: Yes
RESOLUTION: WG disposition is as per
[31]https://github.com/w3c/imsc/issues/320#issuecomment-3635297
05
[31] https://github.com/w3c/imsc/issues/320#issuecomment-363529705
APA comment: permit font related features in Image profile imsc#319
github: [32]https://github.com/w3c/imsc/issues/319
[32] https://github.com/w3c/imsc/issues/319
Pierre: I think this is a simple misunderstanding because SVGs
are not permitted, only PNGs,
... so the comment does not apply.
... We should defer this in case we ever go down the path of
permitting SVGs.
Nigel: Yes
RESOLUTION: WG disposes to defer this until such time as SVG
images are supported.
APA comment: specify association between image and text profile
documents imsc#318
github: [33]https://github.com/w3c/imsc/issues/318
[33] https://github.com/w3c/imsc/issues/318
Nigel: It looks like we simply think the proposal is a bad
idea.
Pierre: Absolutely, and that's reflecting what the industry is
overwhelmingly saying right now.
Nigel: Looking at the comment, I think it doesn't say that the
association data needs to be
... inside document instances, but that it needs to be
specified.
Pierre: The specification is not the right place to document it
- it is out of scope.
Nigel: Yes, that's what I was thinking too.
RESOLUTION: The WG considers the method to signal any
association between document instances to be out of scope of
the specification.
APA comment: Meet WCAG SC 1.4.1 requirement imsc#317
github: [34]https://github.com/w3c/imsc/issues/317
[34] https://github.com/w3c/imsc/issues/317
Pierre: This is not an issue because we do not use colour to
signal deprecation in IMSC 1.1.
Nigel: In fact we do not use colour alone to signal deprecation
in any of our specifications.
RESOLUTION: WG agrees with the comment, and notes that the TTWG
does not use colour alone to signal deprecation in any
specification.
APA comment: presentation customisation imsc#316
github: [35]https://github.com/w3c/imsc/issues/316
[35] https://github.com/w3c/imsc/issues/316
Nigel: This is what we largely discussed yesterday.
[36]Minutes from yesteday's call
[36] https://www.w3.org/2018/02/28-apa-minutes.html
Nigel: Specifically, call out: "JF agrees with the proposition
that an informative note citing this MAUR document would
improve the caption-related specifications."
... We could do that by modifying appendix D to include MAUR
considerations additionally.
Pierre: Sounds good to me.
... I'll prepare a pull request.
SUMMARY: @palemieux to prepare a pull request adding reference
to MAUR.
github-bot, end topic
APA comment: Improve introduction imsc#315
github: [37]https://github.com/w3c/imsc/issues/315
[37] https://github.com/w3c/imsc/issues/315
Pierre: We had disagreement over pull request #326 that we
should discuss now.
Pierre and Nigel: [discuss stuff already in the pull request]
Pierre: [proposed an edited version combining best of both
proposals]
Nigel: Obviously if Image is used because semantics not
available in TTML are needed then
... it is no longer feasible to distribute Text and Image
Profile documents representing the same content.
Pierre: I think we cover the point about distributing both text
and image versions of the same
... content sufficiently.
Nigel: Ok, the updated version works for me.
... I've approved it.
... I'll ping the commenter to request review of the pull
request now that we think
... we know what we want to say.
RESOLUTION: WG disposition is to make the edits as per pull
request #326.
... @nigelmegitt to prompt the commenter for a review of the
pull request
Should the character sets be minimum *font* requirements? imsc#236
github: [38]https://github.com/w3c/imsc/issues/236
[38] https://github.com/w3c/imsc/issues/236
Pierre: This is an issue that we seem to come back to
regularly.
Glenn: I predicted this would happen.
Pierre: My challenge is I don't understand what the commenter
wants.
... TTML1 and TTML2 already require support for Unicode
characters, so an implementation
... cannot reject a document because it does not accept a
unicode character.
Glenn: That's correct. It need not have rendering support or
fonts.
Pierre: The spec is trying to be helpful to implementers who do
want to support particular
... languages or scripts. My suggestion is to organise a call
with i18n and try to get down
... to what they are trying to achieve. We seem to be talking
past each other.
Nigel: I can take an action to try to set that up.
Glenn: My response would be "No. Font and unicode rendering
capabilities are an implementation dependent property in
TTML1."
... Of course in TTML2 with downloadable fonts that opens
things up a bit, but generally
... you cannot support a complex script without adding code, so
just adding a Mongolian
... font won't cut it.
... I would suggest focusing on the characters aspect not the
rendering aspect.
Philippe: Can I try asking a few questions to see if I can
channel Richard?
... Right now are you saying you don't expect implementations
to support UTF-8 necessarily?
Pierre: No, IMSC1 requires support for UTF-8 and TTML requires
support for Unicode.
Philippe: Are you saying you should not use a character outside
the encoding you are using?
Pierre: No, the purpose of the annex is to help an implementer
select which particular
... character they should render. Noone renders all Unicode
characters. They make a decision
... on which set of characters they render based on
requirements such as territory.
... This section is to help implementers.
Philippe: Right now it is worded from the point of view of the
author not the implementer.
Pierre: Originally it was a Processor recommendation, and I
think Dave Singer got really
... upset by that, so we changed it to an authoring
requirement.
... In my mind this is really a processor requirement.
Philippe: r12a's suggestion is also a suggestion for
implementers.
Pierre: Yes, but if we change to a processor requirement we
might get the same objections
... as we had before. For all intents and purposes they are
equivalent.
Philippe: I think we should invite @r12a to this conversation.
Pierre: We're definitely not saying that some scripts do not
need to be supported.
Glenn: "Supports unicode" is an overloaded phrase. It just
means support for the character
... semantics irrelevant of their formatting.
Philippe: In that case the treatment would be the same for all
characters. Why only those?
Glenn: Yes, that's why I suggested not having this section in
the first place.
Nigel: I'll invite him to a discussion.
Charter
Philippe: I haven't had time to talk to Thierry about this -
are you aware of any movement
Nigel: No, the action was with Thierry to organise time with
him, me and Dave, so far we
... haven't found a mutually acceptable time to meet.
Glenn: [discussion with Philippe about publishing TTML2 CR
mechanics]
Nigel: Philippe, please can you take care of the transition
request?
... We already have the resolutions in place.
Philippe: Yes, I'll do things on my side, assuming I can do it
today the earliest publication
... date is 8th March.
... I'll look in the minutes for the resolution.
Glenn: The CfC ends on Monday.
Philippe: If I make the transition request on Tuesday then we
will publish on March 13.
Glenn: I'll put that date in the document, plus 4 weeks later
(April 10th) for the end of comments period.
Philippe: Nigel, send me a ping if I don't make the transition
request on Tuesday.
Meeting close
Nigel: Thanks everyone for attending today. [adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [39]After merging the currently open pull requests, request
transition of TTML1 3rd Ed to CR.
2. [40]The WG disposes that `ittm:altText` is not equivalent
to HTML5 `@alt`. Whereas HTML5 `@alt` is required but
allows empty values, `ittm:altText` is absent when there is
no value. `ittm:altText` is deprecated and specified only
for backwards compatibility; it is replaced by the altText
named metadata item in TTML2.
3. [41]WG disposition is as per
https://github.com/w3c/imsc/issues/320#issuecomment-3635297
05
4. [42]WG disposes to defer this until such time as SVG images
are supported.
5. [43]The WG considers the method to signal any association
between document instances to be out of scope of the
specification.
6. [44]WG agrees with the comment, and notes that the TTWG
does not use colour alone to signal deprecation in any
specification.
7. [45]WG disposition is to make the edits as per pull request
#326.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [46]scribe.perl version
1.152 ([47]CVS log)
$Date: 2018/03/01 17:19:23 $
[46] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[47] 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, 1 March 2018 17:21:21 UTC