See also: IRC log
<scribe> scribe: nigel
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.
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:
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.
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
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.
github: 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.
github: 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.
github: 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.
github: https://github.com/w3c/ttml2/issues/467
Nigel: To discuss the pull request:
Add document proceessing context override semantics for effective con… #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.
github: 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.
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!
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.
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.
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.
Everyone: needs to step out/fall asleep.
Nigel: [Hurriedly adjourns meeting] Thanks everyone!