- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 3 Feb 2022 17:52:53 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <F17AE3BD-B064-40CC-A2A0-CF58B8C4D440@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2022/02/03-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
03 February 2022
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2022/01/20-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/209
[4] https://www.w3.org/2022/02/03-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Gary, Nigel, Philippe, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
cyril, nigel
Contents
1. [5]This meeting
2. [6]IMSC HRM
1. [7]Status on HR and WR
2. [8]HR Issues
3. [9]Rechartering status update
4. [10]Meeting close
Meeting minutes
This meeting
Nigel: Today we have IMSC HRM - Wide Review comms, and HR
issues if there are any to discuss
… And Rechartering status.
… Any other business?
Atsushi: I believe Philippe will join for the charter
discussion.
Nigel: Thanks
Cyril: We could talk about Dubbing and AD requirements
Nigel: OK that'll be an AOB topic
IMSC HRM
Status on HR and WR
Nigel: We completed w3c/imsc-hrm#12 and associated
separated-out issues.
… I think we are almost ready with the text to send to ask for
Wide Review, and the recipients.
… I sent an email out to the member reflector before the call.
… I was a bit blunt but maybe we can discuss the point about
mentioning an implementation, Andreas.
Andreas: I think that mentioning the validator would help
reviewers.
Pierre: I see no harm in mentioning it.
… Reviewing the Privacy folks' comments, a pointer to an
implementation might
… help people to understand what it does.
… Just pointing to it as an example might help people
understand what the spec is and how it works.
Nigel: It's a good point that we got strong feedback asking to
explain what IMSC-HRM is and what would run it.
Pierre: We can write stuff but an implementation speaks a
thousand words.
Andreas: This is exactly what I was thinking.
Pierre: Instead of writing a long intro that won't be read,
it's easy to click a link and see how it works.
… There's no rendering, just validation.
Nigel: Good points. The HR folk are only going to review the
spec, not the implementation,
… so we will have to write some introductory matter to resolve
their questions.
Pierre: Hopefully we will discuss the HR issues this call.
Nigel: I think there's a small tweak to the WR text to explain
that the HRM specifies how a validator must work,
… and doesn't in itself do anything.
Pierre: Let's not make it more complicated.
Nigel: Summary: I need to do a small amount of editing to match
what we just discussed.
… But do we need to make any spec changes before we request
wide review and send this out?
HR Issues
[11]IMSC-HRM issues
[11] https://github.com/w3c/imsc-hrm/issues
Nigel: There's a common theme of needing better
introductory/explanatory text.
… I don't think #30 is a real issue, just needs explaining.
Pierre: Agree, #30 doesn't seem to be an issue.
Nigel: OK, so I think the question is Do we need to do the
explanatory informative text changes before requesting WR
… or do we send as is and add text to the message?
Pierre: I don't think we need to make those changes before
sending out - the expected recipient will already know IMSC.
Nigel: OK, any other thoughts?
… I'm hearing nothing, so will go ahead with the spec as is.
… The other question for WR is the timeline, how long do we
give for responses?
… I think 6 weeks is a practical minimum, 8 might be easier for
the recipients. Any thoughts?
Pierre: I'd err on the side of longer, so .. 8 seems fine.
Nigel: Any more bids?
…
… I think we're there, thank you.
… Anyone want to raise any of the issues?
Pierre: I'm not super excited by writing an introduction but..
Do you feel it's necessary? Feels like it is.
… I'd like feedback on that before I spend time doing it. Is it
needed, what should it contain?
Nigel: Yes, I think it is needed, and it doesn't need a lot.
Pierre: Maybe a picture that shows where it fits in the overall
chain?
Nigel: That would be good, yes.
… I was also thinking that the feedback says the implementation
model is unclear.
… That can easily be addressed by saying, even in the Abstract,
that the specification defines behaviour
… of a validating processor.
Pierre: Thanks, I can write that up.
Nigel: I think this is the key thing that threw the reviewers.
Andreas: I'm not sure if this is the right time, but there is
still this issue we started, #12, for preparing the HR.
… There's a comment about how much customisation is in scope of
the HRM
… and if we should add an informative note about it.
… There were responses from Nigel and Pierre.
… It would be good to have a brief conversation about it.
Pierre: I think that got lost because it wasn't opened as a
separate issue. I missed that when I was reviewing the issues.
Andreas: Sorry, I proposed it but you're right I will do that.
Pierre: I was not ignoring it, it just fell off my radar.
… If you can open a separate issue and we can address it, that
would be awesome.
Andreas: Nonetheless we can have a discussion about it.
… The question in general is if customisation of an IMSC
document when it is rendered should be taken into
… consideration by an author. Should the author, when creating
the document, knowing certain values for styling and
customisation,
… test the document against the HRM with those customisation
values?
… There are two comments where Nigel and Pierre agree that
customisation is not in scope of the HRM.
… But then I think Nigel's comment that in general an
informative note would be possible or may help, but
… you do not agree that it is a problem on the authoring side
but actually on the side of the implementer.
… The implementer should make sure that every document would
pass the HRM together with the customisation options.
Nigel: Slight tweak - I would say the implementer has to make
sure that every document that passes the HRM plays successfully
… even if customisation options are applied.
… The goal is to ensure a good audience experience that matches
the authorial intent.
… The HRM only checks documents as supplied.
Andreas: How can an implementer test that their player works
with customisations? They need to know what inputs to accept.
Pierre: I would generate maximally complex documents and verify
that my software works with each of the customisation options.
Andreas: As Nigel said, I had the same idea and that makes
total sense, how an implementer would be able to test it.
… I think that is a good way to do it.
… A separate issue we could think about is offering those kinds
of test documents.
… My question is maybe answered already.
… If you are in a closed system like the BBC and iPlayer or
whatever, and they offer customisation options, the
… documents are authored in the same environment that also
decides on the customisation options.
… There's a close link between them.
… Thinking about it, it makes more sense that the implementer
ensures that the documents present than that the author does
it.
Pierre: The maximally complex documents are orthogonal to
customisation options because they
… deal with values that are known before rendering.
… Anyone can generate a set of maximally complex documents
independently of the customisation options they offer.
… We could offer those documents.
… We could consider that, or at least an example.
Nigel: We will have to generate tests at some point.
… By the way, the BBC's iPlayer allows text size customisation
but it only ever makes text smaller, so it wouldn't
… cause more complexity under the HRM!
Pierre: The world is far from agreeing on customisation options
right now.
… Andreas, please could you open an issue?
Andreas: Yes I will do it.
Nigel: Thank you.
Rechartering status update
Philippe: The Charter has been reviewed by W3M.
… When I was talking with Atsushi there was some confusion.
… Then early last week I went through the comments with him.
… One of the things that is problematic in the proposed charter
is related to success criteria.
… They are a bit loosey-goosey.
… Reminder:
<plh> [12]https://w3c.github.io/charter-timed-text/
[12] https://w3c.github.io/charter-timed-text/
Philippe: The problem that we have is that it is not clear if
we can expect for each normative feature that
… we will have at least two independent implementations.
Nigel: Aha, let's do this conversation!
Philippe: Section 3.1
<plh> In order to advance to Proposed Recommendation, each
normative specification is expected to have at least two
independent implementations of every feature defined in the
specification.
Nigel: Two independent implementations is not a Process
requirement, it's on the list of questions the Director will
ask.
Philippe: That is correct, but if they do not exist then the
Director will ask for a good rationale.
nigel: we totally understood that when we wrote this
… this has caused some difficulties in the past
… to push something that seemed reasonable to us through the
process
… part of what we did knowingly here when we wrote it in the
charter
… we thought that if it made sense for the AC then the Director
should be ok with it
plh: the sentence that I pasted, can we add that at the
beginning of the section?
nigel: no
… we have described that interpretation of that sentence and
… the process is confusing as to what is "2 independent
implementations"
… and with the way we wrote it, it may be that we'll have 2
implementations
plh: but it may not and that's the problem
nigel: if independently by 2 separate processes, valid content
is created that matches the specifications
… and an implementation matches the specification
… that is demonstrating common understanding of the
specification
plh: I disagree
… we don't test HTML by saying there is a producer and consumer
… and that is good enough
… I don't claim HTML is tested for everything
… but I think this section is setting the bar too low
… we are having debates with the AC to starting REC track when
there are not 2 independent commitments to implement
… if you don't want to add the sentence, W3M will discuss but
they may not agree
nigel: maybe we need to have the conversation with them
pal: let's have that discussion
… the fundamental issue is that we are imposing requirements on
this group that are not in the process
… and if it's true that the only acceptable criteria for W3C is
2 independentimplementations, that should be in the process
… because it's not there right now
… I'll be happy to write up on this
nigel: I think it's also worth noting that there is background
here
… I raised it in the process before, asking to define it more
precisely
… and at every stage, there has been push back
… so it's up to the group to decide and the AC to review
… if it's W3M pushing it, I do question if it's the role of W3M
plh: the Director is delegating the submission of Charters to
AC to W3M
… W3M is not acting in a vaccum
pal: do you need a 2nd implementation when it's an open source
one
… back in the days, 2 closed-source implementations was good
plh: the draft doesn't mention open source
nigel: it does, it's very explicit in the last sentence of §3.1
plh: it does not say all features will be covered by that?
nigel: is this about all features?
plh: the WOFF2 spec was approved as REC and there was a single
implementation of it because open source and used by every one
nigel: it seems that the objection has narrowed down
plh: we always have trouble to define appropriate
implementation experience
… if you tell me there is going to be a common open source
implementation used by every one
… that's a different story
… just because Blink implements a feature and is open source
does not mean it's sufficient
… the virtue of being open source is not enough
… if it's a reference implementation and used by everyone
… that's better, closer to WOFF2
pal: I think we should leave it to what the process says
… but in this case, if it helps to mention that there will be a
common open source implementation
nigel: does it have to be a reference implementation?
plh: open source is enough if used by everybody
cyril: it's vague to me
plh: on purpose, we don't want to constrain the groups too much
… the starting point is 2 independent implementations
… but it can be modified
… I can only define it by examples
… for example WOFF2
nigel: pal is suggesting we meet with W3M
nigel: gkatsev any thoughts?
gkatsev: nothing to add
gkatsev: I agree with you nigel
nigel: I'll happily have the conversation with W3M
… what's the minimum changes to make W3M happy
plh: I will have the conversation, I understand better the
story
… there is going to be one implementation that everybody will
use
… I will talk to Ralph to see what changes he suggests
… I can give you an example of a spec blocked despite having
many implementations
nigel: was there anything else?
plh: the media wg is not listed in the W3C groups? should it be
a dependency?
nigel: good point, we can add that easily
Meeting close
Nigel: Thanks everyone, we're slightly over time. [adjourns
meeting]
Minutes manually created (not a transcript), formatted by
[13]scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).
[13] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 3 February 2022 17:53:16 UTC