- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 11 Apr 2024 16:11:18 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <904AB2BE-1148-4E16-842A-FCFA2168929D@bbc.co.uk>
Thanks all for attending today’s TTWG call. Minutes can be found in HTML format at https://www.w3.org/2024/04/11-tt-minutes.html
In plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
11 April 2024
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2024/03/28-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/279
[4] https://www.w3.org/2024/04/11-tt-irc
Attendees
Present
Atsushi, Cyril, Gary, Matt, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]IMSC-HRM
3. [7]DAPT
1. [8]Replace workflowType with represents w3c/dapt#217
2. [9]Add informative section about mapping from TTML to
the DAPT data model w3c/dapt#216
4. [10]AOB
5. [11]Meeting close
Meeting minutes
This meeting
Nigel: Today we have IMSC-HRM and a couple of pull requests on
DAPT.
… Anything else for the agenda, or points to make sure we get
to?
Cyril: AOB - NAB is coming and we're organising an event we can
mention
Nigel: Thank you
IMSC-HRM
Nigel: The AC Review poll closed, no objections.
… I think we need a pull request to address the proposed
changes?
Atsushi: Yes. I believe we are waiting. Once the pull request
is raised and all comments are satisfied
… we can go to publication. The changes are just suggestions
and are all editorial,
… so it would be possible to go directly to Rec but it would be
better to deal with the suggestions and comments.
Nigel: Pierre, are you okay to open a pull request for those?
[12]A few minor editorial suggestions w3c/imsc-hrm#79
[12] https://github.com/w3c/imsc-hrm/issues/79
Pierre: I was just waiting to make sure there were no other
comments.
… I will prepare the pull request straight away.
Nigel: Thank you.
… Anything else to say about this?
nothing more
DAPT
[13]Issues labelled "agenda"
[13] https://github.com/w3c/dapt/labels/agenda
Nigel: We discussed these two last time but there were no
concrete actions,
… and we said we would continue the discussion on the pull
requests, but we didn't actually do that,
… so I put them back on the agenda. Hope that's ok!
Replace workflowType with represents [14]w3c/dapt#217
[14] https://github.com/w3c/dapt/issues/217
github: [15]w3c/dapt#217
[15] https://github.com/w3c/dapt/pull/217
Matt: Apologies, I didn't notice anything coming through to me
for the review request.
Nigel: This is about replacing workflowType with represents as
a list of the content types that
… the document represents.
… Last time we talked we agreed to make the
<content-descriptor> into a Registry Table,
… and I made that change after the call.
… We also had it as "alternativeFor" last time and had agreed
to change that into "represents" which I also did.
Matt: [recalls the discussion, agrees with the intent]
Nigel: The question for me now is do I go ahead and merge now
or wait for a review and
… take appropriate response on the basis of that.
Matt: I feel I need to read it.
Cyril: I don't have any change to my pull request approval.
… Just wondering about the granularity of the "represents",
could we use represents on Script Events?
Nigel: Further down the tree?
Cyril: Yes, if you want to know which Script Events actually
correspond to each type, we already have
… Script Event Description which is human readable, and we have
Script Event Type that has a Registry,
… but the values don't align - we have dialogue, spoken text,
on screen text...
Nigel: Ooh I hadn't thought of that. Looking at it, I agree, it
seems like this could be one list.
Matt: I'm happy with the general approach.
Cyril: I'm thinking - if you were to replace the values of
represents by the values of Script Event Type...
… If you made a set of the Script Event Types in the document,
would that work?
Nigel: I see 3 options.
… 1. What you said Cyril, allow the event type values to be
coalesced into represents at the document level.
… 2. Add a mapping from event type into a simpler smaller set
of represents values, e.g. title and OnScreenText in event type
… both map to visualText in represents.
… 3. Replace eventType with represents and use the same
registry table for both.
… The nuance is that represents allows a list, whereas
eventType maybe should be a single value.
Cyril: Sorry I only noticed this now. Also the registry table
for script event type needs some descriptions.
… I like the idea of the column for mapping to represents.
… I was wondering what the point of spokenText is?
Nigel: We spent no time looking at the registry table values
for event type, they're just example values.
Cyril: I agree those are the three options, I don't have a
strong view.
… You may not want the same granularity of description at the
document level as at the script event type.
Nigel: That's why I was thinking of the mapping idea.
… I think that if we want to do the mapping, that would be a
new issue and pull request.
Cyril: A 4th option is to not have the document level summary
at all but inspect the document contents
… to see what it contains.
Nigel: That's true, but...
Cyril: In the workflow you want an early indication of the
potential uses of the document.
Nigel: So you're arguing against that previous point?!
Cyril: Yes, I just wanted to note the possibility in case we
want to come back to this in the future.
Nigel: What to do?
… Options:
… 1. Merge now and open a separate issue and pull request to
deal with mapping from script event type to represents
… 2. Go round the loop one more time and try to fix this up
before merging
… 3. Merge now and do nothing about script event type for the
time being.
… By the way we will need to come back to all the Registry
Tables at some point to make sure
… they have the right values. All of the entries are
Provisional right now.
… Any preferences?
… My preference is to merge now and then incrementally improve.
Cyril: We should have an issue that tracks it then.
Nigel: Do you want to open that then?
Cyril: Doing it now.
Matt: Apologies, got to run to another meeting, please prod me
if there's any more review needed. Apologies again for not
noticing this one.
Matt leaves
SUMMARY: Merge pull request, deal with script event type and
represents in a separate issue
Add informative section about mapping from TTML to the DAPT data
model [16]w3c/dapt#216
[16] https://github.com/w3c/dapt/issues/216
github: [17]w3c/dapt#216
[17] https://github.com/w3c/dapt/pull/216
Nigel: From last time, I think the determining factor is if we
need a class of DAPT implementation
… that maps from TTML2 into the DAPT data model. If we do, that
means we need to make these
… provisions normative.
Cyril: Taking a step back, we did this pull request to cover
the case that there is a document that
… conforms to the profile but does not map directly to the DAPT
data model.
… In practice if you have an implementation of DAPT that is
"just" DAPT, which I think will be the majority case,
… then this situation should not happen. You shouldn't end up
with a document that cannot be easily mapped.
Nigel: Yes, to a point.
… The exception could be from the compatibility perspective -
some future version of DAPT adds in a feature
… that we want older DAPT processors to handle gracefully.
… It's not just about TTML2 generically.
Cyril: You're right.
… Thinking out loud, if we added constraints like feature
extensions to restrict a DAPT document
… to correspond only to the DAPT data model, what would be the
problem? Extensibility?
Nigel: Yes, that would be the main one.
… It's really the structural issue of divs containing other
divs or mixed div and p children.
… Which we agreed there could be a future use for.
… If we prohibited that then we wouldn't be able to use that
capability in the future without making a
… breaking version change to DAPT.
… Maybe we could argue that, to make sure that conformant
implementations can deal with those changes,
… that's why we need to make the informative provisions
normative.
Cyril: What about text content anywhere other than p and span?
Nigel: It's allowed in p and span but TTML doesn't allow it
anywhere else.
… Except for metadata elements etc, of course.
Cyril: Ok, thank you.
Nigel: Does that argument about future compat seem correct?
Cyril: Yes. In general I prefer something normative otherwise
there won't be interoperability.
… Does this mean we need a DAPT processor type?
Nigel: No I don't think it does.
Cyril: In §7.2 it defines a DAPT Processor in terms of
conformance to the profile provisions and to the document.
… How would we do that?
Nigel: I'd make extension features referencing the new
normative provisions, so it all ties together.
Cyril: I would like to take a stab at re-writing §5 or
proposing changes.
Nigel: OK, that's fine, otherwise I'd have done it.
Cyril: Not sure when I'll do it.
Nigel: Why don't I do a first pass, and then you can review it?
Cyril: That's fine.
… I think we should move the new section 5 to after the
Constraints section. We're only concerned
… with valid documents, which are defined in the Constraints
section.
… I would start by saying that the processing behaviour for a
processor processing a valid document that
… contains additional content not in the DAPT model is the
following...
… Say there may be conformant DAPT docs that contain more, e.g.
for a new version, or a round trip through
… a generic TTML tool.
… That's how I'd start, by explaining that.
… Once the context is clear I think it's easier to understand.
Nigel: I think it'll be important to say that the graceful
handling feature requirements may be replaced
… in future versions by something that defines some other
behaviour.
Cyril: Did you mention parsing, or just mapping?
Nigel: Just mapping. I think parsing is defined by XML, we're
talking about building a data model from the parsed entities.
Cyril: OK
Pierre: Are you going to take the TTML approach of pruning?
Nigel: I don't think so, not quite
Cyril: For validation purposes, yes.
… But a read/write processor should try to retain unrecognised
vocab
Pierre: The reason for mentioning: if the processor sees
elements or attributes it does not understand then
… there's no hope it can understand how to deal with those
unknown elements.
… If you merely preserve them, that doesn't take into account
the semantics of the unknown elements.
… Generally it's not possible unless you specify extension
rules such as vocabulary in a particular part of the
… model does not affect e.g. timing etc.
… Some things can be preserved with minimal risk, but
everything else, it's hopeless.
Cyril: You can have multiple values of profiles in the
contentProfiles attribute, but if you write back
… a file then you shouldn't write back values of
contentProfiles that you don't understand.
… You could end up with semantically incorrect content.
Nigel: Example is an attribute for number of words, doc says 3,
editor adds 2, saves the value as 3 because it
… doesn't understand it.
Pierre: There's a danger of getting rules that are so complex
that nobody understands them.
Pierre: The TTML model is blunt but straightforward. Just get
rid of everything you don't understand.
… Maybe some stuff could have been kept, but at least it is
predictable.
… When the author wants the document to be compatible with an
older version,
… do it so that when you strip the newer stuff it's still valid
for the older version.
SUMMARY: @nigelmegitt to make edits as discussed, @cconcolato
to review, discussion to continue.
AOB
Cyril: there's an event happening where we're gauging appetite
to talk about live captioning,
… wondering if there's a TTWG view on it. It's on Monday.
Nigel: I don't think I can say anything about this as a Chair
because we've not really discussed it in TTWG.
… But I may be able to say something in my BBC role.
… Can we take this offline please?
Cyril: Can we add this as an AOB for after the meeting so we
can summarise the outcomes?
Nigel: Sounds like a good idea.
Meeting close
Nigel: We're 3 minutes over, thanks everyone! [adjourns
meeting]
Minutes manually created (not a transcript), formatted by
[18]scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).
[18] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 11 April 2024 16:11:28 UTC