nigel: we are still missing Mike so we cannot talk about profile registry
cyril: but I don't think we need to discuss it, I have an action
glenn: I prefer to have a proposal and then discuss based on it
nigel: we will discuss progress towards CR for WebVTT
gkatsev: yes, there is some progress
nigel: 2 issues on TTML 2 that I think need discussion
… we can discuss the region-timing test
… I put charter status update if he joins
… TPAC planning also is on the agenda
… any other business ?
glenn: I'd like to go over PR 1096
nigel: I'm aware that you are waiting for feedback
… ok if we have time
nigel: the review of PR is a bit difficult and we are working on that
gkatsev: the big thing that we last discussed was interop in parsing of region lines
… spec says integer, Safari and Firefox do different things
… I spoke with FF and they are fine with rounding
… so I have a change for that
… borrowed from the HTML spec
… Silvia approved it
… if any body has feedback
… I have updated the snapshot for at-risk
… it should be reviewed
<gkatsev> update region line parsing
<gkatsev> new snapshot
nigel: PR preview does not seem to work
… but there is a link in 460
gkatsev: maybe because it's a change to the archive
<plh> 45211
nigel: process-wise we will review those and when there is consensus, merge them and propose new CR
… is that the plan?
gkatsev: yes
… the CR stuff is in the snapshot #460 but because there are changes that we want to make permanently, I created a separate PR for the main spec
nigel: those changes from 470 are also in 460 ?
gkatsev: yes
nigel: we'll cover the issues first
… 943 ?
<nigel> github: https://github.com/w3c/ttml2/issues/943
nigel: this issue is about allowing zero point to be valid
… it is not at the moment
… glenn's proposal is to permit it
… there is a PR for this
glenn: I restarted the original PR that had been done last year
… I updated based on the current master
nigel: this means that a previous non-conformant document would become conformant
glenn: technically yes
… but it was never the intention to make that non-conformant
<nigel> xs:decimal definition
cyril: is '0.' allowed in xs:decimal?
cyril: it seems that it is allowed according to section "3.2.3.1 Lexical representation"
nigel: but the fact that the . is the last character is a bit confusing
gkatsev: but it says that trailing 0 are optional
glenn: we changed the schema since then to use xs:string
… that change was based on the comment of July 21, last year
… we just need to widen the expression for non negative real
nigel: this change makes non negative real, the + becomes a *?
glenn: no it adds a new line
… you need the full stop to denote it's a real number
nigel: ok, it makes sense
… the idea of making non negative real coincident with xs:decimal makes sense
… it makes it easier to write the schema
… seems like a good change to me
cyril: is it affecting only gain and pan?
nigel: a lot of things
… lengths, gain, pan, ...
… pitch, percentage uses number
… a lot of things would be affected by this
pal: I'm looking at ttval
… so now non-negative real always has a dot
… but not a dot by itself
nigel: it's good to look at implementation
… just checking EBU-TT impl, 1. would not match, but 1.0 would
pal: it seems ttval would reject 0. but I need to check
nigel: it might make some existing implementations non conformant
… I'm beginning to think it's a problem
glenn: there is no requirement to backport it to TTML1
… it would potentially make validation tools not implementing 2nd ed more restrictive
… not sure what the roll out status of TTML2 in the industry
… but that would improve the status of interop
nigel: that would be a change for IMSC 1.1 also
cyril: I would say we shouldn't do syntactic changes unless it's broken
pal: if we have several such changes, we could accumulate them and wait
… it would make it easier to include this one
glenn: I'm not sure I agree that it's a breaking change
nigel: it's not a document breaking change, but an implementation breaking change
cyril: I think people should look at their implementations and we can take a decision based on that
nigel: if this would be the only syntactical change, then it might not be worth
glenn: we already approved some changes
cyril: it would be good to have a list of those
glenn: we changed the content body to add audio
nigel: summary: group to study implementation impact and add review comments
pal: and if we do it, we should have a test for that
<nigel> github: https://github.com/w3c/ttml2/issues/961
nigel: a year ago, we discussed xml:base on the chunk element
… with no apparent use
… actually, xml:base is used to process condition
… so it was proposed to remove condition
… assuming positions haven't changed, it's to remove both, on the purpose that they do not serve any purpose
glenn: the PR that I raised is a resurrection of the one last year
… there is a significant difference in putting condition on chunk vs. source
cyril: would there be an interop problem if I used them?
glenn: it's quite dangerous, and you should not do that
… I think that was an error when we authored it
nigel: is it safe to say that there are other ways to do the same thing?
… like putting condition on something else
glenn: yes
… you could have a multi-entry source
… I could dream-up use cases, not obvious that might use that
… but I'm pretty convinced that it's dangerous, security impact
… because you cannot decode the bytes until presentation time
… and so cannot determine that you have a valid resource
cyril: I don't have a strong opinion on this, as we have not implemented it
… but we should refrain from making changes unless it's broken
… we could add a note without making changes
glenn: my claim is that it is broken
nigel: despite my comment in the issue, I think I've changed my mind and agree with Glenn
… if you are worried of buffer overflow, that can happen with chunks or sources, regardless of whether condition is used
pal: I don't have a strong opinion on this
cyril: chances that people have authored documents with this feature is low
… and it would not require people to change their implementation
… so I'm fine with it
pal: we really need tests
… maybe that will limit us
nigel: right, we should have tests with PR asking changes
… because it will speed up CR processing
pal: and helps people testing their implementation
nigel: I'm hearing consensus to approve it and write tests for it
pal: please include a test before merging the PR
nigel: yes, good rule
glenn: tests are not in the same repo
pal: we could link PRs
glenn: I have no problem creating tests for these
Resolved: we approve the PR and write tests for it
nigel: in the past, our team contact had prepared a wiki page
… with draft agenda topics
… there is also a proposal to have a joint meeting with CSS WG
… and there is an issue on the TTWG repo #52
<nigel> Discussion points for CSS WG at TPAC 2019
nigel: gathering discussion points for CSS WG at TPAC 2019
… Atsushi could you create a similar looking wiki page
atsushi: we should have a page for last year
… is it ok to do something like that?
nigel: yes
<atsushi> 2018
<nigel> Action for Atushi to Create a TPAC 2019 wiki page
pal: I'll be there only tuesday to thursday
nigel: I'm not here next week
… unless someone wants to chair, i'll cancel next week
<nigel> log: https://www.w3.org/2019/07/18-tt-irc