Log: https://www.w3.org/2019/10/03-tt-irc
<glenn> irc only
Nigel: Anything for WebVTT?
Gary: No, nothing to discuss
Nigel: Then we have 2 TTML2 issues, and maybe we can quickly resolve the editorial issue about apostrophes too.
… Plus one IMSC issue.
… In AOB I've included the Charter, but more pressingly the upcoming DST change.
… Is there any other business to cover?
Pierre: [wants to cover the font issue already on the agenda for IMSC]
github: https://github.com/w3c/ttml2/pull/1162
Nigel: [summarises issue]
Pierre: My understanding is the proposal is to revert to the constraints of TTML1
… which as was pointed out by many leads to some unexpected outcomes in some corner cases.
<glenn> We have an approval on this already, so given there was no inclination to accept my suggestion to go further, we can go with what we have now.
Nigel: This PR removes any sense of definition that an out of line [thing] must have an xml:id and a [thing] without
… an xml:id is not an "out of line" [thing].
… That brings it into line with TTML1.
Pierre: Right, I think this is good to go.
Nigel: Any other views or questions?
Cyril: So we're favouring consistency with TTML1 even though we know there is a weird behaviour.
… Glenn suggested an option to edit TTML1. Is that an option?
Pierre: Unless there's a concrete use case I think we should not bother.
… There's more risk and effort backporting something to TTML1 than leaving it as is.
Nigel: I agree I haven't seen a concrete use case.
Pierre: There's a bunch of unexpected behaviours but every time we've run into one we've decided that
… if there's no use case we should accept it, and we should continue doing that.
Cyril: I don't know if it is a concrete use case but clearly [scribe missed due to audio break-up]
… we should at least have tests and check that it is consistent.
Pierre: I really like that idea, it's like what we did with some timing corner cases.
Nigel: Glenn already mentioned on the issue that he could create validation and presentation tests.
Nigel: I think we have consensus to go ahead with this if there are no other points?
<glenn> I need to add tests for this PR before merging anyway, so I can add something for bare and alone unidentified region
Cyril: Yes
… A lone unidentified region means nothing will ever be displayed.
Pierre: That's right, we should create a test like this, it's an excellent idea.
PROPOSAL: Proceed with this PR as is and add associated tests.
Nigel: Any objections?
Resolved: Proceed with this PR as is and add associated tests.
github: https://github.com/w3c/ttml2/issues/1120
Nigel: The question here is do we have consensus to move this issue to IMSC?
Cyril: Yes from me, at least.
PROPOSAL: Move this issue to IMSC
Nigel: Any objections?
Resolved: Move this issue to IMSC
Pierre: I can do this now, to IMSC repo?
Nigel: Yes
Pierre: Done!
github: https://github.com/w3c/ttml2/pull/1170
Nigel: Seeking a view from TTML editors?
Pierre: It's a pain to do this. There are 250 changes.
Cyril: It's difficult, I agree with Nigel that it will not be easy for other Editors to remember it and they might forget to do it.
… But I also think that Glenn is doing all the editing these days and we heavily rely on him so if it hinders him
… from doing his job we should accept the change. What he said is also correct that future editors can revert the change.
<glenn> Without this change, I cannot do any further edits.
Cyril: On the editorial side I would approve the request.
… The burden will be on Glenn to maintain it if other Editors contribute and use ' instead of '
<glenn> And it is a trivial change using M-x query replace.
PROPOSAL: Accept this pull request
<glenn> Sure, that's reasonable.
Nigel: Any objections?
Pierre: I don't object to this change but the characterisation on the pull request is wrong - it is not trivial.
Resolved: Accept this pull request
Nigel: I will press the Approve button.
<glenn> Thanks
Nigel: Done
github: https://github.com/w3c/imsc/pull/485
Nigel: I saw a potential for differing interpretations here, and proposed some options.
Pierre: I think we should go with bytes transferred.
Nigel: That's fine, but given the "loaded" terminology from WOFF, maybe we should use a different non-conflicting term.
… WOFF says "loaded" is post-decompression.
Pierre: [Wonders what the HTTP spec calls this]
Cyril: What happens if HTTP does gzip compression? Do we count it before de-compression or after?
<glenn> <data/> has a well defined @size attr that applies when one has <font><source><data/></source></font>
Pierre: The link above defines transfer length
… the wording specifies the post-gzip decompression size.
… Let's look at the size attribute in data in TTML2
Nigel: It has length not size, I think we mean that.
<glenn> yes, @length that is
Pierre: It talks about the number of decoded bytes
Nigel: Presumably that must be post-decompression for it to make any sense
Pierre: I think we should keep it simple and use transfer-length.
<glenn> actually, @length is only used with simple data embedding; so it would not apply to sourced embeddings; however, the model may be useful
Pierre: This is after any transfer coding, i.e. after gzip.
… What about entity length?
… This is section 7.2, before any transfer-codings have been applied.
Nigel: What is a transfer-coding?
Pierre: like gzip
<glenn> I would prefer that length mean post-transfer-encoding processing, i.e., entity length
Cyril: Side question: do we have any tools for verifying against the HRM?
Pierre: I'm not aware of an open source tool that does it, but I have not checked TTV recently.
<glenn> by which I really mean post-decoding of any transfer-encoding
Cyril: We could be looking for a solution that will never be used.
Pierre: Even though it is not formally implemented, the goal is to prevent somebody from doing something stupid
… like providing a 100MB or 1GB font resource and wondering why the client fails.
… It's setting reasonable limits.
Cyril: We don't need the HRM for that though?
Pierre: No but it's the right place in the spec for it, to Glenn's point.
… Here I think we're just looking for the right term.
… In the case of HTTP it is called the entity-length.
Cyril: You could say that if you download everything locally then it should be that.
Pierre: Nigel was pointing out that "loaded" has a definition in WOFF.
<glenn> if "entity length" means the number of bytes in a resource after removing any transfer encoding, then that is what I would suggest be used
Cyril: I would say we note that we don't mean the WOFF term.
Nigel: I still think that would be vague.
<glenn> we should not tie this constraint to the semantics of internal compression support in a given font format
Nigel: I think we're in the right territory with entity-length and transfer-length and just need to work out which one we want.
Pierre: Is there anything else blocking this PR?
Nigel: Nothing else as far as I can tell.
Pierre: I'm going to try to come up with some text right now.
Nigel: Looks like transfer-length could be zipped, whereas the entity-length is pre-transfer-coding, and therefore,
… assuming that the post-transfer-decoding generates the same bytes as the pre-transfer-coding, then entity-length
… is what we want.
Pierre: [working on an update that might be ready in a few seconds]
<glenn> notes that constraints on image length is based on Decoded Image Buffer size, which suggest something like entity length
Pierre: [pushes the change]
Nigel: [reviews change]
Pierre: I think that addresses the issue you raised Nigel.
Nigel: Yes
Pierre: I plan to defer other issues.
<glenn> just approved
Nigel: Just looking at the timeline of this PR, the key date was 14 days ago when the change was submitted to
… address the TPAC meeting resolution.
Pierre: Yes
Nigel: Does anyone need time to review this latest change before we merge it?
Cyril: Can I have until the end of the day?
Pierre: Absolutely.
… Assuming there's no major substantive change I'll work on an FPWD package, which may need some editorial changes,
… to address publication checker issues, in which case I'll open another pull request and request quick review.
Nigel: That seems reasonable.
Pierre: All the other issues filed I will schedule for next WD and start working on them.
SUMMARY: Change accepted by those in the meeting, PR can be merged no earlier than end of current working day.
<glenn> btw, I posted some recent issues against IMSC 1.2, which may require substantive changes
Cyril: Did Vladimir review this pull request?
Nigel: I don't think so.
Cyril: We should at least ping him.
Pierre: For the feature in general or the specific change?
Cyril: He may have a valuable comment, but we shouldn't delay FPWD.
Pierre: I agree, how do we do it. I can send him an email?
Cyril: Yes go ahead. I'll talk to him about it next week too.
Nigel: I proposed 2 options on the agenda.
… [summarises agenda proposals]
… We can't have it so everyone wins here.
Cyril: If it goes 1 hour earlier, then until mid-December I would not be able to attend.
Pierre: I've moved my schedule around so joining an hour earlier might be very difficult for me.
Atsushi: I can manage 1 hour later in JST.
Nigel: Thank you, in that case I think we will adopt proposal 1, to keep the same local time and make UTC track the DST change in the US.
… I'll send that out and if any non-attendees here have a comment to make then they can do so on the reflector.
Atsushi: No further update from me.
Nigel: We've completed our agenda, thank you everyone.
… Please do add agenda topics to next week's agenda issue on the ttwg repo.
… [adjourns meeting]