Meeting minutes
This meeting
Nigel: Today we have:
… * DAPT - though that's an empty topic I think
… * IMSC 1.3
… * WebVTT
… * Impact of AI technologies on TTWG's mission
… Is there any other business, or things to make sure we cover?
DAPT
Cyril: I see you added another implementation. Still waiting for 1 more for the audio parts?
Nigel: Yes that's right, the EBU's Eurovox product generates DAPT transcripts and translations.
Cyril: That's the only blocker for transition to Rec?
Nigel: Yes, that and final decisions about what to do with the at risk features.
IMSC 1.3
Rec transition AC Review
Nigel: The AC WBS poll is open, please ask your AC rep to vote, if you are in a member organisation!
… I can see that several have voted already.
Namespace document
Nigel: There's a PR open on w3/ns to add the IMSC 1.3 namespace, link in the agenda.
Pierre: It's been merged
Nigel: Great, that's this subtopic closed then!
TTML Profile Registry
Nigel: Should we add IMSC 1.3 Text as im4t?
… I can raise a pull request for that.
Cyril: Why 4?
Nigel: Because 3 is taken up by IMSC 1.2. Because of IMSC 1.0.1 I think
… Any objections?
Cyril: No
no other objections
Nigel: OK I'll do that.
WebVTT
New ATTRIBUTES block
Gary: The main topic is the ATTRIBUTES block PR.
… Background is Apple wanting to add a new metadata type for their Dim Flashing Lights feature.
James: Currently you might see just a warning at the beginning,
… it would be better to take action during the content.
… The metadata issue and PR are pre-requisites for shipping that feature to other platforms
… and to open up VTT metadata to being a broader more reusable metadata structure.
… Sounds like we're really close to a resolution here.
Gary: I think we're close. Thanks for providing a summary of the main open questions.
… The main one is whether to be a new block or part of the header location.
James: [shares window]
github: w3c/
James: If there's no concern of webcompat then I'm not concerned about not having a new block,
… and just moving the newly proposed data into the header.
Simon: That's my preference, it's what that was intended for.
Gary: I think it would be good to have the = permitted even if not recommended.
… I don't know if there's any precedence for this in W3C specs, but in Javascript the __proto property
… was added with a note to tell people not to use it.
Simon: HTML has similar precedent, for various elements that were never standardised but browsers implemented
… were specified in HTML with the "obsolete" status immediately applied.
James: Is that a list, or a recommendation against using any prior non-standard way.
Simon: Here it's using = instead of : as a separator.
James: Use = as a separator but say it's not recommended.
Andreas: For context, is this the same issue that James presented in TPAC in Seville more than 2 years ago?
James: Yes
Andreas: I liked the proposal at the time but haven't followed it.
… We made some comments, but in this case will there be a 2 weeks review period so I can check it?
James: I have some time off next week so can't promise 2 weeks.
Nigel: The TTWG working mode is to treat open (non-Draft) PRs as CfCs, and apply the TTWG Decision policy to them, so if there's an Approve and no Request Changes after 2 weeks, it can be merged.
James: I'm planning to summarise the discussion from today and then add it as a comment to the PR
… So if people want to clarify any details or I've misunderstood then people can see that.
… I'll leave it as a draft PR until then.
Simon: Case sensitivity: currently WebVTT is mainly case sensitive, so it would be consistent to
… be case sensitive here as well. Is there a reason not to be?
Gary: For the attribute names?
Simon: Yes
James: Yes there is pre-existing use by YouTube and others who have capitalised attribute names.
Simon: Are those attribute names the same as the standard ones we're trying to add?
Gary: It depends on which one - like kind etc.
… The case-insensitive part comes up later in the summary of bullets.
… The next point is how we want to define parsing of the attribute names.
… Right now what is implemented is ASCII+, other proposals include XML Name or HTML attribute name.
… My question is: does it need to be ASCII only?
… In WebVTT we already have IDs like cue and region identifier, where any character except --> or space
… is permitted. It already specifies that the cue identifier needs to be unique in the file,
… so the parser would need to do unicode normalisation and other things to make sure the IDs are unique.
James: The only concerns I brought up are bidi and reverse chars, look-alike characters, or zero-width joiners, or emoji variant combinations?
Simon: At the higher level do we need to make it conforming to use non-standard metadata attributes
… in the first place. If not this is moot, we just list the permitted attribute names.
James: The reason for this is, depending on the type that is chosen, I think it is appropriate for the TTWG
… to be the keyholder of what the type is, but once that type is defined it could be some other standards
… body that defines the keys.
… Maybe we don't need to do that.
… At the same time I put in the concept of a custom metadata block that is freeform, not standardisable,
… but parsed, so the implementation could use it.
… If that's the case we should allow freeform characters of whatever character set we define.
Gary: I think it would be helpful to allow custom attributes.
… The reason we had the previous issue is because WebVTT didn't have an official way to include metadata.
… If there was something official then e.g. HLS could have used that for the timestamp map.
… Now I wonder if we want to limit the official names, with an x- prefix, to make it easier for us to add new attributes.
James: Or use the HTML pattern data-
Simon: Or just a - at the beginning, like in HTML.
Gary: In that case would it make sense to point to the HTML attribute parsing, or do we still
… need to specify the - for custom names.
Simon: It's not so much that, which we may need to define ourselves, but we can be aligned that
… no dash means it's defined by the standard.
James: For Gary's question, do we want to point it to the HTML attribute name for parsing?
Simon: I think no.
… We need to ban --> for example, although > is not allowed in attribute names, but it's a different rule.
Gary: We probably want to be similar to how region identifiers are implemented.
Simon: I don't think we need to worry about lookalike characters. These are all possible in identifiers right now
… I think.
Nigel: +1 to aligning with HTML attribute name syntax, because we want to allow the attributes to be reused in HTML.
Simon: Non-standard attributes would be invalid HTML unless they begin with data-
Nigel: OK, imagine people want to push WebVTT attributes into the HTML for their own reasons.
James: Are you proposing some model for tunnelling these attributes through from VTT to HTML?
Nigel: We haven't discussed that as a processing model, but I don't think we need to. But we should
… make the path easy in case people do want to do that.
James: Are we saying any Unicode char except bidi and --> ?
Gary: I think so, yes. Just remove the "ASCII only" part.
… Being case-sensitive is probably easiest. The potential benefit of being case-insensitive is if we were
… to allow language for the lang attribute, because that will allow the current YouTube metadata to work
… without any further work on their part.
Simon: Making YouTube's content magically do something should be a non-goal.
… They can update that in an afternoon. We shouldn't complicate the language for that.
… Maybe that means we should not care about case-insensitive or the = sign either.
… If we were using the ATTRIBUTES block then the existing headers would still do nothing in the standard
… implementation, so we can decide that if the syntax doesn't match then it still does nothing.
… It's not breaking any more than it's broken today if we ignore it.
James: Follow-on question: if any of these attribute lines is invalid do we invalidate the whole block or just that line?
Gary: Just that line. Looking at the HLS timestamp map there is a colon used.
… It wouldn't match exactly, but the attribute name would not just be the [scribe missed]
… The main reason is that it's so ubiquitous in HLS content that having it be valid would be helpful.
Simon: HLS compat is more compelling than YouTube compat.
Gary: Yes. If and when we have a follow-up of a GetAttributes() method then we could decide how to handle
… non-standard attribute names from being returned.
… We could just not worry about them at the moment.
Simon: If the intent is that they should be usable from Javascript then there needs to be a way for them
… to be usable other than fetching and parsing the file again.
Gary: Yes but that doesn't need to be part of this PR.
James: Sounds like we're aligned on 2, moving on, to the question of the reserved key name being lang or language.
Nigel: I can't recall my original comment, and I can't find it!
… Matching HTML attributes in the track element makes sense, I have some recollection that care was needed
… for translation subtitles when indicating the language from which they were translated.
James: I'll see if I can find that comment, but work on the basis of `lang` for now.
… Item 4 is about if `kind` is required, or should `kind: metadata` be required in order to use metadata type.
… I feel that we should require it but if we only require it with a metadata value then it seems complex,
… and I'd appreciate advice on how to do that, if that is what we decide.
Gary: It doesn't seem worth requiring it, to me.
… If you have a type then potentially you could assume kind: metadata but even that seems unnecessary,
… because what if in the feature we decide to have multiple types of captions, or something like that.
… We could extend it for other kinds as well.
James: Then the parsing rule I will attempt to write will be:
… if there is a type, then we would need a kind as well, in order to use the type.
… if there is a type but no kind then the implementation wouldn't be sure how to use it.
… It might be some future type with an unidentified kind.
Simon: Isn't there always a `kind` when sourced from HTML even if it is the default?
James: Yes, so the implementation can fall back.
Simon: Yes, the UA will have a kind even if it is the default.
James: One of the primary use cases is in Apple's services that could be used on other non-Apple hardware
… such as the AppleTV app on another brand of TV, or HBO's content on AppleTV hardware.
… I feel we need to know this outside the context of just the web.
… I'll try to write it up logically in the PR.
Nigel: Until we define a processing model for all this metadata then we should not restrict anything.
… We can add the syntax but then add restrictions later if we define a processing model.
Gary: I was going to say the same thing.
Simon: Just to comment on the processing model, at least for the standard attributes that we're adding then
… it makes sense to specify the processing model in HTML, then you can use the file-provided attributes
… as fallback. Then in WebVTT all you need to do is make that data available so that other specs can look into it.
James: To make sure I understand "the value provided", the kind attribute in HTML would override the value
… in the WebVTT if provided, otherwise the WebVTT value would be used?
Simon: Potentially, yes.
James: So there'd be no need for a parser warning?
Gary: I agree
Nigel: I'd be more concerned about errors than warnings. I'd only expect a warning if there's a SHOULD
… and I don't think there are any here.
James: I'll check that.
Gary: If the line is invalid from a parsing perspective we would skip it.
Simon: But if --> is present then it would be invalid so we would expect some parser message
Gary: Even then the parser might just ignore it and move on.
Simon: Sure, sometimes the parser has errors even if it also ignores.
James: The final point is about the examples, and I'm happy to concede to consensus.
Gary: You could add subtitles to an existing example.
James: Fair point.
Spec ownership and auto-publication status
Nigel: I think we need Atsushi for this.
… For those who haven't been following there was a question about TTWG officially taking ownership of WebVTT.
Gary: There was a CfC that had no objections so we need Atsushi's help to figure out the next steps.
Meeting close
Nigel: Thanks all, we didn't cover the TTWG mission related to AI, for another time when Atsushi is present.
… See you in 2 weeks. [adjourns meeting]