See also: IRC log
<nigel> Agenda: https://github.com/w3c/ttwg/issues/55
nigel: we are very few
... I pull out a couple of substantive issues for TTML2
... Test work
... TTML Live extension module draft got pushed a couple of
days ago
... AOB: Charter update
... any AOB?
<nigel> github: https://github.com/w3c/ttml2/issues/1013
nigel: I assume Glenn that there is nothing to do except implement it editorially
glenn: I marked it substantive
because ...
... it's asking for a default behavior that is not currently
the case
nigel: it's implemented in one
place at least as requested
... but the spec change is probably substantive, I agree
glenn: you're asking that if no
src is present, it default to speech
... ,. and even if there is no audio
nigel: when speak is used
glenn: you could have a top level body element with an audio child
nigel: if you add in an audio
element referring to the speech at the body level, you can't
independently control the gain of the audio programme down in
the hierarchy
... that's a common use case, duck the programme audio but not
the speech
... you need to bring the speech synthesis further in the
document tree
... but it becomes very verbose
glenn: if you wanted to alter the
gain on a leaf span, with speak=normal
... could you not put gain on that span and it would control
the gain of what got contributed and picked up at the high
level
nigel: no it would control the
gain of everything mixed in
... not the differential gain
glenn: I think to study it more
and start implementing a PR
... I agree that right now it's not concretely defined
... given the minimum implementations out there, if you have
one implementation that does that, it is probably the right way
to go
nigel: we may have tests for that
glenn: you contributed those audio tests
nigel: yes
... I'll check
<nigel> ttml2-tests/presentation/valid/ttml2-prstn-audio-speak-on-span.xml test
nigel: this one does not contain
audio
... and that test passed in our implementation, it did speak
it
... the test matches what I'm asking to be specified now
glenn: I'll add that to my work list
<nigel> github: https://github.com/w3c/ttml2/issues/1022
nigel: raised by Glenn initially,
edited by me
... I thought this was merged
glenn: I'm not sure if the
constraint on the use of type has been
... it may be that there is no further action
... I need to check
... I'll post a PR
... if needed
nigel: can you add details in the issue about what was merged already
glenn: yes
nigel: there was an issue 1, to
add a readme and populate the repo
... glenn suggested to add TTV tests
... in the context that these tests are not CR tests
... glenn did and you cannot identify their source
... there is a comment regarding pending tests waiting
approval
... there are lots of validation and presentation tests, a
script as well
glenn: basically, I used the same
structure that we have in the TTML2 test repository
... I tweaked the readme file a bit
... but it's the same structure and convention
... the tests themselves don't identify the source
... use the appropriate license
... the next thing I need to do is take that test from IMSC on
region timing test
... and put that in using the same conventions
... it's on my list
... I want to review the original test suite
... to make sure that these tests include the same
content
... since we did not have validation test concept in TTML1
initially
... there are about 300 tests that I added, coming from TTV and
TTPE
nigel: I agree we need to check
that the TTML1 CR initial tests are in
... we have a bunch of IMSC tests and they are a subset of the
TTML1 tests
... perhaps we should point to them too
glenn: the IMSC test suite exist
independently
... it focuses on IMSC features that are new
... as well as on the constraints model that IMSC puts in
place
... we could incorporate some tests from there with minor
massaging
... there is probably some redundancy that is not harmful
... we'd have to look at the IMSC tests on a case by case
basis
... to make sure that there is nothing that would be
problematic for TTML1 processors
... in theory they should not be
... moving forward we can incrementally add new tests
nigel: any other question?
<nigel> TTML Live Extensions Module README
nigel: I have pushed (after
Cyril's approval to get past the branch protection) 3
documents
... we can use them as a basis to raise issues
... I have some editor's notes to make changes in the
guide
... the TTML live extension module is done, pending
comments
... also the TTML live carriage over websocket
... the one that does need some work is the guide
... this structure of having a guide separate from the main
spec
... is based on the request from the group to pare down the
specification only to the normative parts
... I'm interested if more needs to be pruned out or more
added
... we can shift content between documents
... I plan to bring examples from the EBU document into the
guide
... I'd like to add this to the agenda for TPAC
... so people have about a month to review it
pal: is there a place where one
can find a link to all TTML repos
... I'm looking at the wiki, under publications, and can't find
it
<nigel> TTWG Home page including repos
nigel: the home page contains all
the repos
... I need to add the Karaoke, the Live module, ...
pal: it'd be good to have all the modules on which we are working
<glenn> try https://github.com/search?q=org%3Aw3c+tt&unscoped_q=tt etc
<nigel> Action on Nigel to add new repos to the home page
nigel: in terms of details
regarding the live extension, I created the new features for
the live extensions in the TTML features namespace
... I didn't do in the EBU namespace or some other
namespace
... I just use the feature namespace directly
cyril: I did the same in the karaoke module
glenn: so there is the definition of the underlying features (element types, attribute types) and you used the existing namespaces for that?
nigel: I was talking about the feature designation
glenn: you put that in the standard features namespace not the extension namespace
nigel: right
glenn: and about the underlying features?
nigel: I kept them in the source
EBU namespaces
... there are only attributes, no new elements
glenn: that might be a
problem
... to put the feature designation in the standard namespace
while using non-TTML namespaces for the underlying features
nigel: I did not think it would be a problem, but please review and explain why it would be a problem
pal: EBU is giving up the control of those elements?
nigel: yes, for this work
pal: it'd be good to have confirmation for that
nigel: not everything in EBU namespaces would move under W3C's control
glenn: if you propose to include underlying features defined under EBU controlled namespaces, it makes me uncomfortable
nigel: anything under these
specifications is being contributed by EBU
... no doubt in my mind
... if we need to extend in the future, we might want to add it
in the same namespace, but EBU might not be happy with
that
... is that the problem?
pal: I'm not sure I see a
scenario where we need to use names for other things that those
that were transferred
... extensions will be in W3C namespaces
... I don't see a risk
... but we need a formal communication from EBU explicitly
saying we transfer control of these
elements/attributes/features
nigel: I agree
... to glenn's point, I feel that the namespace of the feature
designator can be separate from the namespace of the referenced
vocabulary
glenn: one thing that would make me more comfortable is if you used the extensions namespace instead of the features namespace
nigel: that's not the point of how we do modules
glenn: [explaining extension
catalog]
... I don't have a definitive comment to make right now
... need to review carefully
nigel: exactly
glenn: can you include in your explainer the rationale for using the TTML namespaces
<inserted> for _not_ using the TTML namespaces for the vocabulary
nigel: to preserve existing implementation
glenn: also add the rationale for using the features namespace and not the extensions one
nigel: because we are defining the module
pal: on that point, that's for me
interop standpoint
... there would be no downside in having it in the extensions
namespace
nigel: I can't think of a problem
pal: there is a features and extensions bucket
nigel: I consider them separate
by namespace only, no difference
... anyway, my main point was to highlight the fact that the
specs were here for people to review before TPAC
<nigel> Proposed Charter (diff)
nigel: the thing to note is that
the new TTWG charter as been put for AC review
... please encourage your AC rep to look through that and
provide feedback and vote
... do look at the details of it
... it has been tweaked
pal: can you summarize them?
nigel: the coordination and
review bits
... there was a discussion about readopting the template
text
pal: I'll do a manual diff
nigel: the one issue that I had
was that the template text said that before entering CR you
have to do Horizontal Review
... they clarified that by saying "first entering CR". That 3
months means we need to ask for HR on new documents very
soon.
pal: if they insist on that, we should do FPWD
nigel: but maybe we can do the HR
on ED
... any other question?
nigel: we have a wiki page
... I've not seen any edit
... do we want to have a meeting in a call the week after
TPAC
... I'll take views, don't have a strong opinion
... any views?
cyril: no objection
nigel: let's cancel the call the week after TPAC
cyril: ok
nigel: next week I'm not
available
... if anybody wants to chair let me know
... otherwise it may get cancelled
... ping me in the next 24h
... Gary might be back
pal: my regrets for next week
nigel: thanks everybody, adjourned