See also: IRC log
<scribe> scribe: nigel
nigel: Let's continue from
yesterday according to the agenda we planned yesterday.
... Any other agenda points not yet raised?
rohit: Reminder that we have an agenda point to discuss github experience.
nigel: Philippe you made some progress?
plh: Yes, it was submitted - the
status in IANA today is that it has been sent
... for Expert Review. I would expect an answer within a week
or two. On the action
... item I have logged the details.
action-477?
<trackbot> action-477 -- Philippe Le Hégaret to Progress the update to ttml media type registration with iana -- due 2016-09-15 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/477
plh: I submitted it on Sep 15,
got an ack on Sep 17. As soon as I hear back from
... them I will let you know, and if there are expert comments
I will put the
... commenter in contact with Mike. If everything goes well we
should be all
... set in 2-3 weeks. I don't know how long it takes to update
the registry.
nigel: Thank you!
nigel: I wanted to raise this as
a placeholder - I think it has gone well for IMSC
... but we have had a lot more discussion about TTML. Any
views?
glenn: It's working for me okay.
plh: A question: how far are you from a TTML2 CR?
glenn: Less than 3 months
... We'll ask for Wide Review in 6-8 weeks.
plh: My worry is that you give
the other groups enough time to do the review.
... With the reorg happening Ralph Swick will be responsible
for organising
... horizontal reviews. My recommendation to facilitate your
work on that is
... For Security and Privacy there's a self assessment
questionnaire - you answer
... the questions and send them to the right mailing list as
part of the review;
... if they do not respond then it's fine.
nigel: Even if they don't want to
comment I would expect at least an answer to
... say that, from politeness and also so we know the
status.
plh: That's fair enough. Bear in
mind this is shifting ground and we're changing
... the way we do this. Ralph will be harmonising this.
... For the TAG, you can ask for a review using their
spec-reviews github repo
action-480?
<trackbot> action-480 -- Nigel Megitt to Request schedule time for horizontal review of ttml2 -- due 2016-09-26 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/480
nigel: Please could I delegate this action to you Thierry?
thierry: Yes. This is new to me also.
nigel: I've moved the action to Thierry.
thierry: One idea we have raised is only to request review on the new features.
plh: That will help them but they
may tell you about a problem with the older
... features.
thierry: And then they will destroy TTML1?
plh: Possibly they could!
... Here are some links to help you with this:
... Having difficulty joining IRC so I'll send these by
email.
plh: With the W3C reorganisation
I am becoming responsible for all the WGs in
... W3C, so I will be responsible for ensuring all the WGs are
able to move forward
... on the Charter deliverables. I am allowed to extend
Charters with Director's approval.
... It is now the responsibility of Wendy Seltzer to look after
what the future web
... is going to look like and propose any changes to the
Charter. Ralph is responsible
... for the entire technical coordination of W3C including
horizontal reviews, TAG
... and other technical issues that groups cannot resolve. If
you come to me
... with a major technical issue I will take that to Ralph for
you.
nigel: Thank you for your help over many years!
andreas: +1
plh: I am still responsible for
the TTWG! Nigel can still come to me and complain
... if he has issues - now all the other Chairs can do this
too!
... So I won't be doing github issues etc myself unless it's
super quick.
... Team Contact and Chair training are now under my
responsibility too.
nigel: Thanks - any questions or any more?
plh: It's been a pleasure, feel free to contact me and I'll try to be even more responsive.
glenn: So no more ttml.js maintenance?
plh: If anyone wants to fork that
and come to me for some information on it that's fine
... but I can't spend official time coding any more.
https://github.com/plehegar/ttml-js
plh: You're welcome to rename it
- it's under CC0 so it's public domain. I'm happy
... if someone wants to do something to put a pointer on my
repo to other places to look.
... Excuse me, I need to go to another WG now.
nigel: Thank you very much!
andreas: [projects Hbb4All
presentation]
... I just wanted to give an update on Hbb4all. An EU funded
project that ends this year.
... A strong focus on EBU-TT-D deployment. I always promoted as
TTML because
... it is better known.
... 6 or 7 player implementations, 3 broadcaster apps, one
being for TTAF.
... jwplayer and videojs implementations hopefully that will be
open sourced.
... Also a Samsung native implementation of TTML for HbbTV 2,
which I think
... was a public prototype implementation last year.
... Also, we demonstrated automatic production of subtitles,
DVB TS -> audio processing ->
... speech recognition -> punctuation and captialization
-> TTML generation
... Lots of other partners also.
... subtitling.irt.de - 2 demo live streams of EBU-TT-D in
DASH.
... It uses the dash.js implementation so for example you will
see line gaps between background areas.
... We did some interop testing for each partner with each
other's TTML, to see
... how it is rendered. There are certain issues. Example with
background colour
... not coming out if RGBA is not implemented properly.
... Also font being proportional even though monospace
specified.
... This will be published as a report.
... Another one is overlap of lines - a big problem is
application of lineHeight
... especially with the "normal" setting. There is no clear
message from any group
... using TTML, or there are contradicting messages.
glenn: You mean other than the specification note to use 125%?
andreas: That's a recommendation
only. In EBU-TT-D we recommend not using
... "normal" because it is not implemented the same
everywhere.
... The gaps between lines differ between different renderings
again because of
... lineHeight="normal".
... Another one is where implementations try to do a nice
looking thing even
... though it is not specified, like including linePadding when
it is not in the document.
... I also saw a lot of implementations at IBC sometimes called
DFXP because they
... are not always aware that it is the same as TTML
effectively.
nigel: Thank you!
... While we're on this topic it would be a good time for me to
mention about
... EBU-TT Live.
... I mentioned this at the Web & TV IG yesterday also:
http://ebu.github.io/ebu-tt-live-toolkit
... The project is an open source implementation of the EBU-TT
Live spec
... - we're about half way through implementation. The spec is
at v0.9 now
... and we hope to move to v1 in early 2017.
glenn: Do any of the efforts for live define rollup?
nigel: This doesn't - EBU-TT
doesn't permit any form of animation, and in any
... case it is not clear how to use animation for smooth
roll-up. In my opinion
... the best way to do this is still to allow implementation
specific behaviour as
... written in the Note in TTML1.
... By the way, the context here is a sequence of TTML
documents in the absence
... of any wrapper that can provide additional semantics. For
our work here this
... has two impacts for TTML2, one is sequence identification
and numbering
<tmichel> taking a 15 minutes break
nigel: Shows a scratch diagram
with three real world concepts, the Root Container Region, the
Related Media (e.g. encoded video) and the Media Player, each
being an independent concept.
... default of the Media Object Region which coincides with
TTML1.
... We should make sure that we all share an understanding of
those different
... viewports and that they match what we need in real world
use cases.
glenn: Right. I think we can look
at the Safe Crop Area proposal independent of
... that, because it is orthogonal.
nigel: Right.
andreas: I think we need to
gather all these concepts together and clarify them.
... Especially in relation to IMSC which talks about video
frames.
nigel: https://github.com/w3c/ttml2/pull/184
glenn: So you're defining in the
document coordinate space an area that
... presentation processors should keep sacrosanct.
nigel: Yes.
glenn: I don't see that as a
problem. Putting all four parameter values in a single
... attribute can work. I wonder if we should constrain the
values to percentages.
nigel: Yes we could do that.
glenn: I find that a lot of
implementations are based on percentages.
... The one part I have a problem is the presentation
semantics.
... I think we can dispatch the Visible rendering area
definition, or I'd like to.
nigel: If possible that would be okay.
glenn: I'd like to describe the
process in the 2nd paragraph differently and
... use should rather than shall.
... [discussion] If tts:extent is not defined on the tt element
then the root container region is defined as being coincident
with the related media object region.
... If the Related media object region changes during
presentation then I don't
... agree that this triggers a re-layout.
nigel: I don't agree. If
percentage extents and font sizes are used then it is
... possible that a re-layout is needed.
glenn: We always assumed that would not happen.
nigel: Is that written in the spec somewhere? I've never read it anywhere.
glenn: I think it's implied, I'm pretty sure it's not explicit.
rohit: There's some wording in
the text on the tt element about the behaviour
... if there is no tts:extent on the tt element.
pal: IMSC 1 says explicitly that you shall map to the related media object.
andreas: So IMSC is saying that you map it to the image frame of the related media object.
glenn: Correct, but the language
there does not talk about changing on the fly.
... This is a key point, whether the processing context can
change over time
... or not.
pierre: If you don't specify
tts:extent on tt then there's no notion of pixels at all.
... The root container sets the coordinate space for the
document. Every length
... is related to the root container region always.
glenn: There's another way to
think about that, which is when you establish
... the correspondence in the beginning then you can create
pixel values.
pierre: That is one implementation.
glenn: Then after that if scaling occurs then you still use the same dimensions.
group: [discussion] conclusion that the requirement is to define that implementation ensures that everything that falls within the safe crop area is displayed on the screen.
glenn: If a tts:extent is present
then it establishes the document coordinate space.
... If an extent is absent then you need to establish a
document coordinate space (once and for all time) that overlaps
the Related Media Object Region.
pierre: That's one implementation - some implementations do not use pixel coordinates.
nigel: For me it's okay to have a document coordinate space that is always only in percentages.
glenn: It's important to know the pixels for laying out fonts etc.
pierre: Each implementation decides what pixel grid it wants to render on.
dae: If you have 800x600 video and the user clicks zoom so we now have 400x300 what's the document coordinate space now?
glenn: That would cut off content on the edges.
dae: So in that case 50% would still mean 400 (or 300)?
glenn: Exactly.
andreas: Is this also how IMSC 1 defines it?
pierre: IMSC 1 makes the mapping of the root container dependent to the related media object.
nigel: The section about best
endeavours is there to allow for presentation
... processors to do whatever processing they want to do to
achieve the required
... outcome of ensuring the content in the safe crop area is
displayed (i.e. is in the visible rendering area)
... To draw this to a close, I have an action to modify the
first paragraph in
... pull req §11.3.3 to avoid referencing the undefined term
"TTML content"
glenn: In the second paragraph I would rather not use shall but use a declarative approach.
nigel: This is actually a
processor requirement so it's a shall. There is a defined
... feature for it, which in the case of a presentation
processor, refers to the
... semantics in §11.3.3 so it would be possible to profile out
this behaviour
... using that feature designator.
glenn: Okay I'll look at that.
andreas: I'm a bit worried about
the number of terms and their definitions and that
... we may not all share the same understanding. Everybody has
a certain view,
... but it may be that we are not all on the same level right
now. This is a problem
... if different implementors understand it differently.
pierre: You should bring any
differences here. ittp:aspectRatio in IMSC 1 sets the
... aspect ratio of the root container.
... For example if it were 4x3 then a reasonable implementation
is to create
... a 4x3 pixel array, render the document on that, and
composite that (potentially
... also scaling isomorphically) onto the related media
object.
andreas: Yes, centred.
pierre: If I don't specify
ittp:aspectRatio then I can choose whatever shape pixel
... array corresponds to the related media object, choosing
whatever actual
... resolution I want.
... If we think it is important to explain how this works then
we can generate
... examples if you think that's important. Is that your
concern?
andreas: Yes it's part of it, but it's also the other terms.
nigel: And in IMSC 1 it is
deliberately left vague whether the related media object
... is the encoded video or the media player for example. And
different implementations can make different choices.
pierre: Yes, and that's something
we should try to define possibly in specs that
... that reference IMSC 1.
andreas: For this group I would
like to make sure we have clear definitions of:
... related media object, related video object, related media
object region,
... image frame of the related video object, document
coordinate system,
... viewport, viewport target.
nigel: Let's take a 10 minute
break and restart at midday.
... Okay, we're back...
andreas: I would like to have the
reference terms from TTML1, IMSC, EBU-TT-D
... and then look at the terms in TTML2.
nigel: Ah, that would take a bit
more preparation than I think we have, but it
... sounds like a good review exercise. What we can do now is
look at the new
... terms in TTML2 and do that task later or on our own.
... Glenn what are the important new concepts?
glenn: viewport and viewport
target.
... I don't personally like that definition of viewport because
it is too general.
... In our context it should be closely related to the root
container region.
... What I was thinking at the time is that it is possible to
think of different
... viewports, one for presenting the related video object and
another for
... presenting the root container region, but for us the root
container region
... is the only concept that has any significance.
... In TTML1 there was a long outstanding bug to improve the
definition of pixel.
... At the same time we began introducing mechanisms involving
aspect ratio.
... where we introduced display aspect ratio in IMSC. I needed
appropriate
... terminology for discussing aspect ratios. Then I had to
distinguish between
... time of authoring and time of presentation, where aspect
ratios may differ.
... Then there's the vw and vh unit definition which
effectively assume a viewport term.
... We already have this defined in the XSL-FO space.
... The first note in 11.3.1.4 refers to the page-viewport-area
which here
... corresponds to the root container region. They play a
crucial role in defining
... a local coordinate space in which the children are
positioned and rendered.
pierre: Why do we need to define viewport given that the definition of the vw and vh units do not use it?
glenn: Well we need that to define viewport target.
nigel: Why do we need viewport target?
glenn: This is to relate the root
container region to some other context such as
... encoded video's image area or the area including the black
bars etc.
... Viewport target is a formalisation of an initial attempt to
provide a conceptual
... model for associating a root container region with
something other than the video frame.
... I don't know if it's something that we want to nail down in
TTML2. To support
... it fully we're going to need some new parameters like
viewport target parameter.
... What's in the spec right now is preliminary and needs more
conceptual
... thought as well as syntactic support.
pierre: I don't see why we need anything other than root container region.
glenn: If we are talking about the outer world we need it...
pierre: That's a separate step.
glenn: Yes it is. The question is does the author want to give some hints about it.
pierre: Everything that relates
to generating pixels should always be related to
... the root container region, and then we should separate out
the concept of
... how the root container region relates to any real world
thing.
glenn: I have no problem with that, but we have only one terminology section.
pierre: True, we don't want more than one of those.
nigel: It sounds like there's
more work to do here and some group members may
... have questions in their minds about how far we need to go
in TTML2 to relate
... the root container region to some physical thing.
glenn: I'll proceed with this - it's possible I'll pull it out depending on effort constraints
rohit: If we have root container
region and some aspect ratio defined, is there
... anything else that needs to be normative?
glenn: IMSC defined DAR, so now
we have all three aspect ratios and it's possible
... to generate a conflict.
rohit: Let's say we get past that
issue, is there anything else that needs to be
... normative?
glenn: Then I think we need
normatively use some definitions in other parts of
... the spec to give semantics to definitions.
... If we do want a viewport target parameter then we need
normative
... syntactic definitions. We could segregate some of this into
an informal annex.
nigel: Where is the use case or
requirement coming from to define viewport
... target in the document?
glenn: Someone said it at some
point but I can't point to any formal submission.
... If nobody thinks it is useful then I would just as soon not
spend time on it.
... We do start to touch on this with safeCropArea.
nigel: All we are doing there is
admitting the idea that not all of the root container
... region might be displayed.
glenn: The only other thing is nigel's suggestion to rename vw and vh.
dae: it would seem more consistent to use rw and rh since they are related to root container region.
nigel: My concern is that vw and vh will be misunderstood and misused.
group: discusses impact of changing vw and vh to rw and rh, concludes that we will change.
nigel: Thanks for the
constructive approach everyone.
... I've updated issue https://github.com/w3c/ttml2/issues/181
pal: So initial was introduced to
set defaults for style attributes; and there's already an
inheritance
... scheme for initial. Why not make non-inheritable style
attributes inheritable instead?
glenn: That would break CSS and XSL-FO models very badly, for example all the background properties.
pierre: You could just reference a style from a region, where the desired defaults are in that style.
glenn: That's not style inheritance, that's referential styling.
pierre: Okay, so you could enable
referential styling for backgroundColor with no impact.
... That's my proposal, to use referential styling instead of
initial.
... The style resolution process already does this.
... I then don't need to introduce a new vocabulary.
glenn: That forces users to adopt
a particular authoring style and it may not be efficient in
some contexts.
... For example say you have tts:showBackground which defaults
to "always" which you may want to change to
... "whenActive" so that's a good example for using initial to
set it to a different value instead of its normal
default.
... In the case of an anonymously generated region by putting
an extent and origin on a p or div, it would not be possible to
have
... them style the region that was created anonymously via the
use of a style attribute. Any style attribute on p for
example
... do not apply to the region, only to the p.
... The region created picks up the initial values as
defined.
nigel: This touches on the
question of whether region style attributes modify the existing
region or create a new one.
... Another syntactical approach could be to introduce say a
tts:regionStyle attribute to reference a style for the created
region.
pierre: [Notes that he objected to this solution to meeting the default value requirements back in January]
Andreas: I see a use case for
this - the only thing is are there problems in current
implementations that make this necessary,
... because every additional feature adds to the implementation
burden. Does anyone have a problem in TTML1 that makes
this
... necessary?
glenn: I have noticed that people
often fully specify styles that are redundant. I view initial
as a highly useful authoring tool to
... reduce the size of documents and the complexity.
... I use initial all the time, and it's an option to profile
it out if necessary.
pierre: Is there anything you can do with initial that you cannot do with referential styling?
glenn: No. Indeed you could also use full inline styling.
rohit: If you specify all styling attributes you also would not care about it.
glenn: I found this in change proposal 17 going back to issue #207 in tracker...
nigel: From the discussion, to
summarise, we have consensus to leave initial in the TTML2
spec.
... Thanks, there's no issue to update on this, though this
initial element does appear to satisfy https://github.com/w3c/ttml2/issues/36
... Let's take lunch now, return at 1400.
nigel: I don't feel we have a lot to do here.
glenn: That's my take too -
cleaning up some language may be adequate.
... Adding some notes about SMIL may be helpful. We need to
firm up the
... idea of a document timeline.
nigel: I have three things to
raise here:
... 1. I would like us to have a defined document timeline for
which the document
... defines some activity.
... 2. Consider removing SMIL normative references and
replacing them with our own normative text.
... 3. Consider adding a time expression model controlled by a
parameter on the tt element
... in which all the time expressions are flat and on the
document timeline,
... so no calculations are needed for nested timed elements. We
would need to
... be careful to clarify that elements can only active in this
new model when
... their parent elements are active.
glenn: We could do that, being
aware of the potential additional time taken to
... advance the specification.
nigel: Note that there's no
feature designator right now for nested times in TTML.
... I would add a feature designator for the new flat timing
model to allow
... profiling for implementations that only support flat
timing, which would be
... much simpler to write.
... This also would offer a path to a nice solution for the
first problem, which
... would simply be to allow a document's active period to be
defined by begin
... and end/dur elements on the body element.
andreas: You could simply profile out nested timed elements.
nigel: You could but then you
would need a different way to define the document
... timeline.
rohit: From a use case perspective I prefer flat timing.
dae: I don't see a use case for nested timing.
nigel: If we decided to adopt this then I would volunteer to do the editing work.
glenn: Post TTML2 it might be
more feasible to identify some specific extensions
... like a new timing model and write a spec just for that, in
a modular approach.
... We would have to put a framework in place in order to deal
with the use
... of modules.
pierre: I've never seen nested
timings used, and probably hardly any
... implementations do it properly.
... I've never seen content for distribution that has nested
timing.
... I think our time is better spent clarifying the timing
model.
glenn: I've read the SMIL timing
and synchronisation section probably 20 times
... and implemented it at least 3 times, and every time I have
different questions
... and implementations, so I think it's difficult to get it
right.
... Absent some reviewed test content I don't think we have
dealt with the questoin
... of correctness in a way that's satisfactory.
nigel: As a minimum I think we need a feature designator for nested timing.
andreas: Yes.
pierre: Why not just require non-use of nested times?
rohit: I think you can specify
that by saying that on the traversal from root to
... leaf only one element specifies a begin or end time.
nigel: From the discussion, I
think we're not generally supportive of adding
... a flat timing model now but we are interested in
reproducing the SMIL semantics
... and making them normative in TTML2.
glenn: That would take a lot of
time, so I'm thinking it should be a post-TTML2
... task because there are too many things that are higher
priority.
... I wouldn't object to anyone else going ahead and doing that
work but
... I'm not sure I would have time to review it and sign off on
it.
andreas: The first thing is that
SMIL is hard to understand for everyone; the
... second is if we have any existing problems that we need to
solve. If not, then
... is there an urgent need to clarify it in TTML2? Perhaps the
clarifications could
... be done in a separate document for example.
nigel: We could certainly do that as a Working Group Note say.
pierre: The situation in most implementations is probably that there are bugs.
rohit: People who author do so with a "flat timing" mindset.
pierre: Most players assume that,
and are just based on leaf elements having
... begin and end attributes.
... My suggestion for going beyond that is if there's part of
the industry that
... wants more than a flat simple model then getting out of
SMIL would help
... get beyond that. If we don't care about that for now then
we don't have to
... do anything for TTML2.
glenn: There are not a lot of
timing tests in the TTML test suite.
... but there are a few that would be useful to run through
existing code.
rohit: One possibility is that
you produce ISD sequence and check if two
... implementations produce identical ISD sequences.
nigel: By the way I still have a
problem with making the ISD serialisation normative in the
spec.
... it's a useful concept but I don't think it needs to be
normative.
glenn: I'd be prepared to make it informative.
nigel: Going back to my first
point, I would like to be able to indicate without
... changing the SMIL timing semantics or the syncbase the time
from which
... any given document defines some output behaviour.
glenn: You could just use the first ISD time.
nigel: That only defines the time
at which some content is displayed. I want to
... be able to define a time at which the document becomes
active even if at
... the beginning for some period there is no content
displayed.
andreas: [explains concept on whiteboard]
glenn: It sounds like you want to
introduce the idea of a supra-document timeline
... that covers multiple documents' timelines.
... [expresses problem as needing to put documents onto a
separate timeline via the whiteboard]
andreas: What problems exist with the current mechanism?
nigel: It would solve some
specific cases for assembling live subtitles onto some
... kind of "global" timeline, also potentially for feeding
into a packaging mechanism.
... I would make an "entry point" and "exit point" parameter on
the tt element,
... which would be optional. It would not modify any of the
existing time
... resolution or computation semantics, but effectively tell
the presentation
... processor to "seek" into a particular moment on the
document timeline, and
... "stop" on a different moment, if specified.
andreas: [expresses concern that this could duplicate functionality in other layers]
rohit: This also has some analogies in IMF for example.
nigel: I would make this optional
so that it can be used when there is no external
... wrapper format.
andreas: Possibly it would be interesting to view this as a proposal.
nigel: Ok I'll do that! [break for coffee, return at 1550]
andreas: Over coffee I had
another idea that might solve your use case Nigel...
... If there's no wrapping information there's no way to get
the information for external processing context.
... So what you could do is define a new element outside the tt
element that could be used as a wrapper,
... then have a tt element inside it. So you just define a
wrapper element for the tt document.
... This could be a short note or whatever defining the new
element and the semantic.
nigel: Ok, why would that be better than having a parameter on the tt element?
andreas: The semantic of the tt element doesn't change at all, and it would work for any kind of document.
rohit: This would make TTML2 documents look very different from TTML1 documents.
andreas: You could wrap TTML1
documents in this also.
... And it doesn't conflict with current semantics.
nigel: One issue with this is
that the active begin and end times should be in the document's
timebase and
... you would have to inspect the contents to discover what the
outer wrapper values actually mean.
... As a general concept I can see it could be useful but for
this it feels to me on first glance a bit "heavy".
nigel: https://github.com/w3c/ttml2/issues/128
... The issue here is how you use the condition mechanism to
set different attributes on regions or styles
... for example based on an externally passed in parameter or
media query.
glenn: Style attributes can point to multiple styles.
nigel: True, but region attributes cannot.
glenn: I need to review this and
think about some alternative solutions. Region can refer to
style elements.
... That's probably what I would do. It would be useful to put
some motivational examples on to
... describe why one would use condition.
... I do have some open questions by what it means 'ignore the
semantics' when the condition is false.
... For example let's say you have a chain of styles that refer
to each other, if one of the middle ones in the
... chain has a false condition do you ignore it and all the
rest of the chain, or just the styles defined on that
... style element. I haven't decided in my mind the best
approach to that.
... For every element we probably have to say something about
what it means to ignore that content.
rohit: One use case would be on the content side, to replace the "forced" functionality.
nigel: Agreed.
... Glenn you mentioned recently that adopting the 'modify'
semantic for inline anonymous region would
... require a reversal of the direction of reference. Does that
have any impact here?
glenn: The way that content and
animation are associated using xlink:href to point from an
animation to
... content, in SVG. When we started with TTML2 animation we
started with that same approach. The SVG
... spec probably defines SMIL animation better than SMIL
does.
... We changed it so that content elements point at animate
elements, so to pick up an animation for an
... out of line animation then the content would have an
animate attribute pointing at the id for the animate
element.
... If we want to animate the current region then the logical
place for the animation would be as a child
... element of the content, for example a <p
tts:extent="..." etc.> you would synthesise a set element
that
... is a child of a p, but targeting the region of the p not
the p itself. Now we need the animate element to
... point at the element to be animated.
... I don't really like using xlink for this purpose so I am
contemplating using a target attribute on the animate
element.
... However we do have xlink already because we added support
URL linking, so using the xlink version would
... be feasible here and may be desirable for consistency.
nigel: In that case you could
resolve this issue by having set elements that change region
attributes as well
... as condition attributes, so that would effectively
conditionally apply styling etc to regions using that
mechanism.
... The next question is does a set element have to have
timing?
glenn: No, it is a timed element
so it has times whether defined or not, but it could have
implied times
... that would be inherited from its parent.
nigel: Presumably its 'rehomed' parent not its lexical parent, the animation element?
glenn: That's a good point.
nigel: I've added a note to the
issue on github there.
... https://github.com/w3c/ttml2/issues/168
glenn: I think we already have consensus on doing this.
nigel: I don't have any specific
proposals for this but have been wondering if there are any
options for
... structuring the TTML2 spec to reference TTML1 and add to
it, for example. I think it's almost certainly
... not something that we would agree to right now, but it's
occurred to me that we could consider it.
group: [discussion of possibilities, predictable lack of willingness to vary from current path]
andreas: For implementers it might be helpful to have an EBNF notation for TTML1 and TTML2.
glenn: I would leave that as an
exercise for the reader. It would not add any precision because
all the
... information is already present for every syntactic feature.
For example for attribute values we use a more
... general EBNF but for element definitions I used a different
syntax, I think from how SVG and SMIL did it.
... Points at §2.3 for a definition.
nigel: Are we going to hit an
accessibility problem with the spec by using colours only to
indicate
... deprecated or obsoleted features?
glenn: Whenever there is one it is also written out in the specification text.
nigel: Ok there's no problem there then.
rohit: Does this cover the expression syntax too? Or is that classic EBNF? if it is we should call it out.
glenn: Actually I think we
followed CSS, where for example || means "in any order" and
&& means a particular
... order (but we don't happen to use any of those).
... I guess we should check if we say in the conventions if we
make use of those.
rohit: I don't think we do. We should be explicit that we're using EBNF or whatever.
nigel: Please could you add an issue to the github repository for that please Rohit?
rohit: Sure, more than happy.
rohit: https://github.com/w3c/ttml2/issues/168
glenn: Mike Dolan's response to
this was that it should be illegal or an error. I think we can
easily update
... the formula in Annex N to accommodate fractional seconds in
clock-time expression in smpte mode.
... If it is allowed it should probably only be permitted in
smpte continuousmode, since they by definition
... can not be labels as are used in smpte discontinuous
mode.
nigel: I've heard a question like
this before. I think you have to quantise to a specific frame
value, and I don't
... know how you choose whether to use floor or ceiling or
whatever to do it.
glenn: [Go to H.3 in TTML2]
clearly you could end up with fractional frames, and it does
not look like we
... have defined any floor or ceiling rules here.
nigel: Whatever we do we could
end up generating a frame value that turns out not to be valid
according to
... dropMode, so I'm beginning to come round to Mike's point of
view that we should just not allow this and
... consider it to be an error, since this seems to be
nonsensical.
rohit: That sounds like a resolution.
nigel: It would also be coincident with EBU-TT (not permitting fractional seconds in smpte timebase)
rohit: Do we also not allow offset time expressions with anything other than ms and t metrics?
nigel: You are also permitted fractions in offset times.
rohit: Then exclude fraction components too.
glenn: I noticed another problem
in H.3 - it does not refer to subframes, but we do have a
subframe component.
... That was intended to match an earlier smpte spec that
allows you to specify field numbers.
nigel: I don't see this problem -
subframes are counted in H.3
... I would propose to prohibit offset-time expressions in
TTML2 even if that's a breaking change. It would be better for
the world! At least we would put it out for review.
glenn: I would accept a "shall not" when version="2" for TTML2.
nigel: I've updated the issue with this.
rohit: Re notation, I created https://github.com/w3c/ttml2/issues/186
nigel: We have already discussed
this last year and have https://github.com/w3c/ttml2/issues/122
... I propose that we move on unless there's a change to what
we agreed - we just need to create a pull
... request for this and do it.
glenn: In the context of entry
and exit time parameters it would be preferable to have them
all either in
... the metadata namespace or the parameter namespace.
nigel: Arguably there's a
philosophical difference since a processor would not take
action based on the
... sequence id and number when processing a single document,
but it would to based on the entry and
... exit time parameters.
nigel: I made a submission early
on Monday morning for requirements for audio description.
... Describes the requirements document; [describes expected
TTML2 structure on flipchart]
... It seems that TTML2 could easily be expanded to fit these
requirements by adding pan and gain
... attributes, an audio mixing model and an additional
interpolation mode for animate. BBC has a
... prototype AD mixer using the Web Audio API that could
easily be modified to run off a TTML2 document
... that supports these extra features.
glenn: TTV can validate the audio element so that could be another implementation.
nigel: There's currently no AD
document spec other than a proprietary one that I'm aware of so
this would
... be helpful to the world also.
... If anyone has interest in taking this further please
respond to my reflector email with any comments
... on the requirements or any other implementation
thoughts.
<glenn> +Present glenn
andreas: Having raised this in
yesterday's Web & TV IG joint meeting the question is what
role this group
... would want to play.
glenn: I think it would have to play a major role.
andreas: Tomorrow there will be
an unconference session on this. I think it would be good if
not only
... driven by TTWG.
glenn: +1
andreas: But also not a lot of
people will want to do the work and have the expertise so they
may well point
... to this group. So tomorrow if there is interest to move
this forward one proposal would be that the
... requirements would be documented and taken to the Web &
TV IG.
nigel: To clarify: ask them to validate the requirements?
andreas: I'm not sure how this
would work - we may possibly document requirements and
possible
... solutions, and then discuss there for contacting other
working groups from W3C that are dealing with
... the HTML specs.
<glenn> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2-api/Overview.html
nigel: We would need some active
participants from Web & TV IG to take this forward
otherwise it could be
... that nothing happens until next year's TPAC! Maybe we need
to go more directly to e.g. Web App WG.
andreas: I was wondering if the
attendees of tomorrow's session might be able to bring some
work to this
... working group?
nigel: I wonder if we could reuse the TTCG for this?
andreas: I would rather set draft
a document in the TTWG and encourage others to join. We might
isolate
... this work from the rest of the group's work. This was
similarly an issue with the mapping document work.
nigel: It's not in our Charter so
we would need to publish as a Note only, or if we want a Rec
then recharter,
... or use this group as an incubator and donate a document to
another group that might have it in scope
... of their charter.
thierry: We could set up a new CG
for this - it would be more neutral than doing it in TTWG and
wouldn't
... have the same encumbrances for joining.
andreas: Yes, we could do that.
nigel: We're really out of time for this, but Glenn are there any editorial actions you would like help with?
glenn: No, not right now, I will ask when there are some.
nigel: Okay, thanks.
nigel: Thanks everyone - we've
covered a huge amount over two days including every topic we
had on our
... agenda and more besides, with a really constructive
atmosphere.
Glenn: That's thanks to your chairing.
Andreas: Thanks for chairing!
nigel: [blushes] Thanks everyone, have a great rest of TPAC everyone. [adjourns meeting]