- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 26 Oct 2017 15:52:05 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D617C2FE.4CAE3%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/10/26-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
26 Oct 2017
See also: [2]IRC log
[2] http://www.w3.org/2017/10/26-tt-irc
Attendees
Present
Nigel, Cyril, Glenn, David_Ronca, Pierre
Regrets
Andreas, Thierry
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TPAC 2017 Advanced planning
3. [6]TTML1 and TTML2 compatibility in practice
4. [7]Definition of tts:fillLineGap does not match
itts:fillLineGap as specified in IMSC 1.0.1. #429
5. [8]Add equivalent CSS properties to style attributes
#406
6. [9]Create CSS mapping for tts:fontShear based on CSS
skew #471
7. [10]Allow detection of the EBU-TT-D content profile.
#467
8. [11]contentProfiles and processorProfiles delimiters
possibly ambiguous #474
9. [12]Updated profile signaling and resolution to match
TTML2 semantics #267
10. [13]Other IMSC issues
11. [14]Meeting close
* [15]Summary of Action Items
* [16]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: Today we have: TPAC planning, TTML1 and TTML2 (not much
to discuss?),
... IMSC Pull Requests and TTML2 Pull Requests. As in recent
meetings I haven't had
... confirmation that anyone will join to discuss WebVTT but if
they do then we may be able
... to cover that.
Glenn: [will need to leave after 1 hour]
Cyril: I'd like Glenn's opinion on last week's discussion about
compatibility issues between
... TTML1 and TTML2.
Nigel: Ok.
TPAC 2017 Advanced planning
Cyril: Have we heard anything more from CSS WG?
Nigel: I have not, no, I will check in with the Chairs, Alan
and Rossen to see if they have
... any suggestions.
... I wanted to mention that since our Charter expires at the
end of March 2018, I've
... added it to the TPAC agenda topic list, since we may want
to begin thinking about the
... next steps.
... Following up on the discussion we had about the "demo"
session, Pierre and I have a
... plan of action, and I've added some text to:
[17]TPAC Demo session proposal
[17] https://www.w3.org/wiki/index.php?title=TPAC/2017/SessionIdeas#TTML_and_IMSC_rendering_in_Javascript_with_CSS_styling
Nigel: If other people want to come along that's fine,
otherwise Pierre and I will be there to
... explain about TTML rendering in browsers with Javascript,
and the challenges of mapping
... to CSS, including some of the TTML2 features.
... It will give us a chance to gauge interest. I'm not sure
exactly what the format is, if we
... are in a single room or if we will all be gathered together
in one big space.
TTML1 and TTML2 compatibility in practice
Cyril: Not much to discuss, Glenn, did you have time to look at
it and review what was
... discussed last week about the document?
Glenn: I've given it a first review and thank you for doing the
work - it's very useful. It will
... help provide another set of objective considerations to
look into if we have issues.
... From my first pass, I didn't see anything there that was
overly surprising or alarming,
... which was good, so that's a good first step at least.
Nothing popped out at me right away.
... It has always been my intention to try to minimise any
substantive issue that would cause
... problems for a TTML2 processor to process a TTML compliant
document, so I think I've
... succeeded to a certain extent. Some of the details over
time have changed the TTML2
... spec and it's probably a good opportunity to go back and
see if there's been any inadvertent
<cyril>
[18]https://docs.google.com/document/d/1Ri7RBBsbIK9SRxA1KsHRejX
bYBuL4CRRrbmEZRbwZpg/edit#heading=h.p3blw6xu90rj
[18] https://docs.google.com/document/d/1Ri7RBBsbIK9SRxA1KsHRejXbYBuL4CRRrbmEZRbwZpg/edit#heading=h.p3blw6xu90rj
Glenn: movement away from that goal. Of all the things you
looked at, it seems like there were
... one or two orange or red blocks?
Cyril: There was ttp:pixelAspectRatio, tts:direction,
tts:overflow and the computed style set processing.
Glenn: On pixelAspectRatio we have tried to nail down the issue
of aspect ratios more carefully,
... particularly by introducing display aspect ratio, which is
different. Right now the way I
... see it is that the TTML1 processor has more freedom to
interpret display aspect ratio and
... the coordinate space of the TTML document, so if anything
what we have done is to try
... to make it less ambiguous. That's one of the areas of
change that I think Nigel commented
... on recently when he said that if there are errors or
ambiguities in TTML1 that we need
... to fix then that may present us with some inevitable change
and is something we are
... assuming may occur. I guess we have to keep our eyes on how
they may cause issues.
... In this case my feeling is that existing implementations,
being less constrained by the spec,
... will produce potentially a greater variety of results than
they would otherwise so authors
... cannot rely on a consistent treatment of ambiguous things
in TTML1.
Cyril: That's my understanding, that in most cases the TTML2
changes make things more precise
... and reduce the variability.
Glenn: That's right.
... Moving onto tts:direction, I recall that in XSL 1.1 this
language already appeared, or something
... very close to it, and we had not documented it or pointed
it out in TTML. In a sense we
... were incomplete with regard to our intention to adhere to
XSL semantics. This is another
... case where we tried to nail down something we had a
precedent for in XSL.
Cyril: So this can probably be back-ported to TTML1 Third Ed.?
Glenn: Yes, as resolving an ambiguity.
Cyril: I'll take the action to make sure there is an issue on
TTML1 Third Edition for this.
Glenn: I don't think there is one, so that's a good idea.
Cyril: Last week I had the action to propose changes as part of
ttml2#458 for the compatibility
... section of TTML2. My idea was to write the text in a
similar way to how I wrote it at the
... beginning of this document, would you agree with a sentence
like this in §3.4.2 or TTML2?
... "TTML2 is designed in such a way that a TTML1 document (not
containing any TTML2 feature) would be rendered by a TTML2
presentation processor in an acceptable way according to TTML1.
This includes all variations allowed per TTML1. "
Glenn: Someone may question "in an acceptable way" but looks
good on the surface.
Cyril: I'll put the text in the issue so we can fine-tune it. I
plan to put it in §3.4.2.
Glenn: Right, that sounds like a good home for it.
... I'm sensitive that Mike has continued to insist on language
about an exact same rendering,
... which is problematic.
Cyril: I tried to avoid that by talking about being acceptable
within the variations allowed in TTML1.
Glenn: That's one way to handle that.
Cyril: There's one part of that section about TTML1 document
instances being intended to
... be conformant TTML2 documents. I don't know why the wording
"is intended" is present?
... What would be the difference?
Glenn: The section is non-normative and I was trying to capture
the intentions of the spec
... writer and the group for objectives for the specification
as opposed to mandating or
... requiring a state of affairs normatively.
Cyril: The "is intended" is a bit weak - I would prefer to say
"TTML2 is designed such that
... a conforming TTML1 document is a conforming TTML2
document".
Glenn: I think we can do that. We should at least aim for it.
Cyril: I'll comment on the issue with the two proposed changes.
Glenn: Thanks. I appreciate issues where exact spec text
material is provided as a starting point.
Definition of tts:fillLineGap does not match itts:fillLineGap as
specified in IMSC 1.0.1. #429
github: [19]https://github.com/w3c/ttml2/issues/429
[19] https://github.com/w3c/ttml2/issues/429
Nigel: The last comment on this is from me, saying we need
practical proposals to address the needs of
... the various constituents.
Glenn: We already don't support, say, smpte:backgroundImage, so
there's a precedent for
... not supporting fillLineGap seems no different.
Nigel: That's confusing - not putting smpte:backgroundImage in
TTML2 doesn't mean it
... cannot be in a profile.
Glenn: That's right.
David_Ronca: We've been advocating that IMSC vNext is a subset
of TTML2, but there are
... two ways to get to it - either make sure that there's a
TTML2 equivalent feature for everything,
... or by bringing IMSC namespace attributes into TTML2. We
prefer the former.
... We'd like to address the features in TTML2 not by pulling
in IMSC namespace.
Nigel: Reminder that we agreed to look at each case
individually last week, and that we
... should do that at TPAC.
Glenn: Makes sense to me.
David_Ronca: We should do that, at TPAC.
Nigel: For fillLineGap specifically I'd like more detailed
proposals.
... We have tts:fillLineGap in TTML2 and itts:fillLineGap and
they have different wording, so
... they may have different semantics. The goal is probably to
align the semantics, and then
... for IMSC vNext we need to think about how to handle this if
both are permitted, for all
... constituents.
Add equivalent CSS properties to style attributes #406
github: [20]https://github.com/w3c/ttml2/issues/406
[20] https://github.com/w3c/ttml2/issues/406
Nigel: Glenn, have you been able to look at this?
Glenn: I've not completed looking at it.
Nigel: Primarily I'm interested in incorrect mappings, and
secondarily on formatting - I'm
... not especially happy with how it's turned out but I don't
have a better suggestion.
[21]TTML2 Pull Request #470
[21] https://github.com/w3c/ttml2/pull/470
Create CSS mapping for tts:fontShear based on CSS skew #471
github: [22]https://github.com/w3c/ttml2/issues/471
[22] https://github.com/w3c/ttml2/issues/471
Nigel: I haven't made a change for this yet.
... Cyril please could you confirm my reading of this and the
proposed mapping?
Cyril: I will confirm, but I think you're right.
Allow detection of the EBU-TT-D content profile. #467
github: [23]https://github.com/w3c/ttml2/issues/467
[23] https://github.com/w3c/ttml2/issues/467
Nigel: To discuss the pull request:
[24]Add document proceessing context override semantics for
effective con… #468
[24] https://github.com/w3c/ttml2/pull/468
Nigel: There's one easy fix here about an element being called
an attribute, and a typo.
Glenn: I'll get those in and maybe we can wrap that one up.
... Pierre, if you have any additional comments on this please
say so, in the thread.
Pierre: The proof will be when we see how IMSC 1.1 uses this,
in terms of how the global
... override works.
... A global override like is suggested here will work for
IMSC. When we walk through the
... revamped IMSC 1.1 profile resolution section, which is the
first user of this TTML2
... functionality, we'll see if there are any issues. In the
meantime I think this pull request
... addressed the major issue, which is there used to be no way
to provide an external
... input to the process, so that's been fixed.
Glenn: It already did support the document interchange context
providing a value if there
... was no other value than that chosen so far. You had
explicitly asked that it pertained
... to the document processing context as opposed to the
document interchange context.
Pierre: That's right.
Glenn: I took that to mean you wanted a way for the processor
to look inside the document
... and make a determination based on the document content or
on the entity that's controlling
... the application.
Pierre: Yes but there's also an issue with the document
interchange context, that it comes
... after everything else, only if everything else failed.
Glenn: That's right, that particular mechanism did not provide
an override path, which is why
... I ended up combining the original request along with an
override.
Pierre: Exactly, so right now the new language supports that.
... Which is fine.
... We'll try with IMSC 1.1 and see if it works.
SUMMARY: Modulo the minor text edits required, this is good to
merge.
contentProfiles and processorProfiles delimiters possibly ambiguous
#474
github: [25]https://github.com/w3c/ttml2/issues/474
[25] https://github.com/w3c/ttml2/issues/474
Nigel: (summarises last comment on issue)
Glenn: I thought about that - we have some syntax sections like
a content value syntax section,
... where for example <condition> is described. I was thinking
to have a uri reference
... subsection added to that to be a sibling with the other
items in the content value syntax
... section, and that we could provide the common language
there, and everywhere else we
... could refer to that syntactic non-terminal without having
to repeat the language everywhere.
Nigel: Sounds great to me.
Glenn: Sounds like I can go ahead to craft something in that
direction.
Nigel: Yes please.
... Did you have any thoughts about RFC3986 and percent
encoding?
Glenn: I was surprised about this because I had not thought
that spaces were permitted in URIs.
... Where it cautions about the technical possibility of
whitespace it is referring to the lexical space,
... which is not the literal space of the document encoding so
some processing has already
... occurred to put it into the lexical space form. The other
thing I noticed was it did not
... define a canonical lexical space for the URL primitive
type, whereas it does for everything else.
... If it had defined one then I would have expected to see
something there dealing with this situation.
... The point is that percent encoding or decoding would have
already occurred between the
... document literal encoding and the lexical space, but the
space would not be in the document.
... If you combine that with the other XLink reference my
conclusion was that in the document
... you would not see a space, so it is not a problem for
parsing. But it does raise the question
... of if we expect the percent encoded text to be decoded
before going into the abstract
... information set. Since we define everything with reference
to the reduced infoset I think
... we need to say it must still be percent encoded in the
reduced infoset.
Nigel: I agree - percent encoding and decoding is not
idempotent so we need to be clear
... about exactly what should be expected so that the encoding
and decoding are done
... the correct number of times.
Glenn: Yes, and cautionary avoidance of doubt notes are a good
idea, and this new section
... would be the right place for it, so I'll go ahead and do
that in a pull request.
SUMMARY: @skynavga to propose a pull request refactoring
`<uri>` references into the content value syntax section and
including a cautionary note about percent encoding.
Updated profile signaling and resolution to match TTML2 semantics
#267
Nigel: I'd like to step through this, but maybe not now.
Pierre: There's still time. It's using the override feature
from TTML2.
Nigel: Is it dependent on the TTML2 pull request we discussed
earlier?
Pierre: Yes.
Glenn: Isn't there a danger of rewriting or paraphrasing the
TTML2 profile resolution semantics?
Pierre: The goal is just to use that.
Glenn: I may have misunderstood in reading between the lines.
Pierre: It says "the profile semantics of TTML2 apply" and then
explains how you deal with
... say, ebuttm:conformsToStandard.
Glenn: That sounds reasonable.
Pierre: It's supposed to be easier!
<pal>
[26]https://rawgit.com/w3c/imsc/dda2f98b3f3fb817ef482fdb498f298
971ce64c3/imsc1/spec/ttml-ww-profiles.html
[26] https://rawgit.com/w3c/imsc/dda2f98b3f3fb817ef482fdb498f298971ce64c3/imsc1/spec/ttml-ww-profiles.html
Nigel: I think what I just realised is that in reading this we
have to follow it against not just
... TTML2 but actually the open pull request on TTML2!
Pierre: Look at §5.4 and §7.8 on the above rawgit link.
Nigel: What does it mean to say that a processor profile is a
subset of another processor profile?
Pierre: It means that it's a collection of features.
Glenn: It might be useful to say "strict" subset.
Pierre: Literally it's a mathematical subset.
... of a collection of features.
Nigel: Why didn't you use "superset" vs "subset"? I think it
would be more helpful to indicate
... to adopters that if they have, say, a Text Profile
processor then it can be used to process
... those subset profiles, or can be claimed to be a processor
of them.
Pierre: If that works better for you, then fine, it means the
same thing.
Nigel: I think it's a pyschological thing - more helpful to
describe in positive terms than negative ones.
... I will have a look and make some other comments.
Other IMSC issues
Pierre: I've started to indicate which IMSC issues are blocked
by TTML2 issues. Some are
... super boring but cannot be fixed until TTML2 is fixed, for
example ttml2#455 that blocks imsc#255.
Glenn: Have you applied a label?
Pierre: I've applied "blocked" on the IMSC repo.
[27]Blocked IMSC issues
[27] https://github.com/w3c/imsc/issues?q=is:open+is:issue+label:blocked
Glenn: I think we discussed #background-color and agreed what
to do. I should be able to take care of this ASAP.
... I will enhance its priority.
Pierre: There's also the profile signaling one imsc#261
dependent on ttml2#435.
Nigel: Thanks, that's very useful Pierre.
Glenn: Question - you say that imsc#267 does not require
ttp:version...
Pierre: Because IMSC 1.1 requires contentProfiles to be
present, ttp:version is never used.
... There's never an ambiguity that's resolved by the presence
of ttp:version, so given the
... rich semantics we have with ttp:contentProfiles and
ttp:processorProfiles I'm concerned
... that we don't need ttp:version. You could just require that
ttp:version or ttp:processorProfiles be present.
Glenn: One of the other main reasons in my mind that
ttp:version is useful is to signal to
... the processor that it is going to require, say, support for
ttp:contentProfiles. Right now,
... if you use that and want to make it the source of any
inferences about processor profiles,
... if the TTML2 processor happened not to support
contentProfiles but only processorProfiles
... then it might not even look for contentProfiles whereas if
you say ttp:version="2" that's
... an implicit statement to tell the processor to pay
attention to contentProfiles.
Pierre: The same could be said for a processor that did not
support ttp:version. If ttp:version
... goes away and contentProfiles and processorProfiles are the
way they are signalled then
... it would be dumb for processors not to implement them.
Glenn: It depends what you think you'll get for supporting say
contentProfiles.
Pierre: If I'm an author and I want to communicate explicitly
to the processor what processor
... profile is required then I can do that with the designator
and that's more expressive
... and explicit than ttp:version.
Glenn: Yes, in TTML1 we did not require support for
ttp:profile, and that optionality was used by EBU-TT.
Pierre: This is greatly improved in TTML2 so maybe we don't
need ttp:version. I'm questioning
... if it is a good idea to have the switches based on the
value of ttp:version given the goal
... to be seamless with TTML1. If we get rid of ttp:version we
can maybe get rid of all ambiguity.
Glenn: I'll take a fresh look at it with that in mind.
Pierre: Given the community's experience with TTML1 maybe we
should require signalling
... of the processor profile. Now we can do it there's no
excuse not to do it!
Glenn: I agree.
... I also need to review the code in TTP to see where
ttp:version is used.
Pierre: Yes, that goes to the heart of Cyril's work - to
resolve if there are spec issues or code issues.
Glenn: OK.
Meeting close
Everyone: needs to step out/fall asleep.
Nigel: [Hurriedly adjourns meeting] Thanks everyone!
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [28]scribe.perl version
1.152 ([29]CVS log)
$Date: 2017/10/26 15:51:09 $
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[29] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 26 October 2017 15:52:38 UTC