See also: IRC log
<scribe> scribe: nigel
Nigel: Today we need to move forward with IMSC and TTML. I will briefly mention TPAC. Any specific points to cover, or other business?
Mike: The IMSC 1 issue regarding SDP-US
Nigel: I've had confirmation from
the newly re-chartered Media and Entertainment IG (was Web and
TV)
... that we can meet them jointly for 30 minutes on the
Monday.
... I proposed a draft agenda of an update on subtitle and
caption work including TTML2, IMSC 1.0.1, industry
adoption
... Seek input on IMSC 2 requirements
... Gauge interest in a possible profile of TTML2 for AD
... plus any other topics of interest.
... I suggested afternoon would be better than morning in case
there's any last minute preparation to done.
action-497?
<trackbot> action-497 -- Nigel Megitt to Invite csswg to joint meeting at tpac 2017, with list of topics. -- due 2017-06-15 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/497
Nigel: I haven't progressed this
yet.
... I will gather together the details as discussed last week
and hopefully progress that in the next week.
... Registration is now open, as are the preferred rates for
hotels - early booking is recommended.
action-498?
<trackbot> action-498 -- Nigel Megitt to Invite i18n to discuss imsc 1.0.1 issues -- due 2017-06-15 -- PENDINGREVIEW
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/498
Nigel: I did invite Richard and
Addison but they have not either joined or said they would be
(un)able to do so.
... However there has been some discussion offline.
Pierre: I suggested it would be
easier to have the discussion live but we can go ahead and try
to propose a solution and disposition
... and deal with the response.
... I'm fairly confident that the root of the issues is mainly
a misunderstanding of the specification.
Nigel: Some of the github issues have been discussed offline.
Pierre: By the way I'm not
blaming anyone, but conflating reference fonts with recommended
character sets is a problem.
... They are really separate. I hope I clarified some of that.
Specifically the idea of recommended sets is for author to have
confidence
... that characters for a particular language will be displayed
and for implementers to have confidence that they are
supporting the
... correct code points. Separately and independently there are
a set of reference fonts that are specified, but the choice of
recommended character
... sets was made independently of the reference fonts. And the
"rendering fidelity" associated with recommended character sets
is whether they
... display at all, period, whereas for reference fonts it is
about metrics, line breaking positions etc. So I think this is
where the misunderstanding lies.
... So in a pull request I tried to clarify it. At some point
we have to propose something and let them restart the
discussion if they feel the issue is not
... resolved.
Mike: I'm sympathetic - this is a complicated topic, but I also believe the spec is clear. I think we have done what we can.
Clarified the requirement for processors to implement reference fonts #245
Nigel: This is for #237 and #241.
Pierre: It has also been discussed in relation to #236.
Nigel: From the discussion are there more changes you want to apply to resolve the misunderstandings?
Pierre: Maybe less not
more!
... The note "Since the flow of text..." is the one we maybe
need to work on.
Nigel: Did you see my proposed alternate wording?
https://github.com/w3c/imsc/pull/245/files#r121123051
Pierre: I'm fine with it - I hope
people won't read too much into it.
... It's not only the flow of text but also the background, the
effective size of the subtitle.
Mike: Yes, line height, characters per line.
Pierre: Gaps between lines.
Mike: It's sweeping so having the
reference font is critical.
... From a web browser perspective some of this must seem
strange, but for this application the web approach doesn't
really work.
... I don't know how you say that in a note!
Nigel: So "flow of text" is too generic?
Pierre: Or not broad enough. It
is the whole appearance of the subtitle - I think that's a true
statement. We could try to list it all but
... evidently it is not obvious.
Nigel: The other thing we maybe
need to clarify is the scenarios where reference fonts apply -
it maybe does not jump out
... enough that reference fonts only come into play for a very
specific subset of computed values of tts:fontFamily.
Pierre: That's extremely explicit
though. Without Richard on the call I think we're grasping at
straws.
... In light of what we just talk about what should we do? Have
a more generic note about the appearance of the subtitle?
Nigel: Yes, if you want to try to craft that I'd be happy to review it.
Pierre: I'll do it now and we can
review it later.
... My recommendation is to apply the pull request and propose
it as a disposition and get the response.
Nigel: I think that's fair. Any other views?
Mike: No.
Attribute syntax definition: missing spaces #221
Pierre: Option 2 was preferred
and there was no reaction against it, so I've drafted a pull
request on that basis assuming that TTML1 will
... clarify that spaces are in fact permitted, and rejiggered
IMSC to take that into account.
Pierre: This PR puts references into TTML1 for the sections on attribute syntax, and IMSC assumes it is permitted and says "you should not do that" (in document instances).
Nigel: I see you've specified no white space between digit tokens... That's not to say you can't distinguish numerator from denominator!
Pierre: No just between digits.
If you look say at %age in TTML1 it is clear that no LWSP is
permitted between them.
... It is obvious to me, but it was obvious that there would be
no spaces between fontFamily components, so I'd rather err on
the side of completeness.
Nigel: +1
... Do you want to merge that then?
Pierre: Yes
Nigel: okay, nobody has any objections, go ahead.
Pierre: Done.
Nigel: We have one more, which is #242:
-> https://github.com/w3c/imsc/pull/242 Discourage the use of tab characters in <p> and <span> #242
Pierre: That's one day away from the 14 days and there have been no comments.
Nigel: I've just approved it by
review.
... When it comes to Dispositions the main one we need to
address is ARIB since all the other comments are W3
internal.
IMSC 1.0.1 comments tracker wiki page
Nigel: Thierry the ARIB liaison has listed on that wiki page that it is under review and not edited in the spec.
Thierry: That was the status about a week ago.
Nigel: I'm puzzled I thought it had been done.
Pierre: Yes, they are #227 and
#228 and they have been merged and are ready for review.
... The proposed email states that.
... You said that you and Thierry would review and send it
after this meeting.
Nigel: The last email in the thread is:
https://lists.w3.org/Archives/Public/public-tt/2017Jun/0066.html
Nigel: OK I see. Does anyone have any comments or changes on the proposed response and dispositions?
group: [silence]
Nigel: In that case let us take that as approval!
Thierry: OK I will send that.
Nigel: Thank you.
Thierry: Just one thing - is 1 week response time enough?
Nigel: I think 1 week is very short.
Pierre: Do we have to get a response? Or can we proceed with no response after some time?
Thierry: The best is a response, but if not then we can go ahead to the Director in any case.
Pierre: Can we work backwards from when we want to publish the CR?
Nigel: I don't want to have our TTML2 and IMSC 1.0.1 publications clash.
Thierry: Only one is a transition - the other is just another WD.
Pierre: How about transitioning on July 6? Mid-July would not work for me.
Thierry: We can go straight to PR if we have implementation experience already. I've seen that before.
Nigel: I thought the Process sets
a minimum duration for CR? But if not, then okay fine.
... I believe we have one implementation of fillLineGap
already, and implementing activeArea is trivial.
Thierry: I'll check the process.
Nigel: [also checks] - the 4 week
minimum appears to be for getting comments on the way into CR
not on the way out.
... In that case when are other implementations expected?
... I'm happy either way - we can go straight to PR otherwise
CR.
Pierre: We can review that on July 6.
Nigel: July 6 is 3 weeks out, so we could offer 2 weeks.
Pierre: Then we could plan on transitioning on June 30.
Nigel: Accepting TTML2 is a WD
only, it is much bigger so I would rather not schedule 2
document publications on the same day - I would rather wait
until
... July 6 for IMSC.
... If we say that then we need a resolution to publish IMSC
1.0.1 as a CR (or PR) no later than next week's meeting.
... That gives us this coming week to mop up any remaining open
issues.
... Thierry can we say 2 weeks for the disposition
response?
Thierry: Yes
Pierre: I would say explicitly the date we plan to transition.
Thierry: We need to have the response before meeting the Director.
Pierre: Okay then 2 weeks for sure. I would be explicit about the planned transition dates too.
Nigel: I'm happy with the 2 weeks but I don't agree that we should include more dates of planned transitions etc - just say when we need the response back.
Pierre: Okay I'm fine with that too.
SDP-US is listed as a normative reference, but it is not #246
Mike: This was prompted by a
discussion with someone who thought that SDP-US is critical to
implementation of IMSC1. However
... implementation of SDP-US is not critical at all, so the
normative reference is an error.
Pierre: Does a normative reference imply complete implementation of the referenced document or just the relevant bits?
Mike: The latter.
Pierre: That's my understanding too. The current text says "if the document conforms to SDP-US you shouldn't use ttp:profile".
Mike: That's poor choice of words
and not IMSC1's business.
... Conformance with SDP-US is not IMSC1's business. If you
want an SDP-US document do that. This is just a declarative
note.
Pierre: So you're arguing that's a statement not a conformance clause?
Mike: Yes absolutely. If you want
to go there (and I don't), it's a declarative note only. It is
not a conformance term for IMSC 1 and has nothing to do
with
... IMSC 1 conformance.
Pierre: My thinking is: as
currently written it is evidently misleading, but not wrong. If
we are going to move the normative reference to an informative
one then
... we should change this clause and remove any
conformance.
Mike: I don't think we should wander into conformance here.
Nigel: There is also Annex I
about compatibility with other TTML-based specifications.
... Effectively the same wording is duplicated there.
... And that's a useful service given the design goal to be a
superset.
Pierre: Looking at §6.9 Profile
Signaling...
... SDP-US prohibits the ttp:profile attribute from being
present.
... In order for me to evaluate the clause in §6.9 I need to go
and read SDP-US.
Mike: And it shouldn't make me do that.
Pierre: That's the root cause of this. You're suggesting that we should change the wording to be informative and move the reference to the non-normative section?
Mike: Yes, I'd like to refactor
this to remove the normative reference.
... The ramifications are editorial: the use of SHOULD
originally was a bad choice.
Pierre: Section I.3 has the declarative statement.
Nigel: Just checking all the other references to SDP-US, they all seem to be declarative.
Pierre: We could reword §6.9 to match §I.3.
Mike: Why do we need to repeat it?
Pierre: Because it is important to clarify the profile signalling from TTML1.
Mike: I'm okay either a) deleting
the sentence or b) restating it as a declarative
statement.
... There are a number of ways to remove this from the
normative references.
Nigel: I don't have any objection
to removing it from normative references. By the way it is only
a WG Note, so it's a bit odd for us to normatively
... reference it anyhow, I'm not sure how that slipped by.
Pierre: It could be just a missing ! - I can prepare a pull request.
Mike: I do believe this was just a mistake.
Pierre: I believe we will have to list this as a substantive change even though it has no conformance impact.
Nigel: I agree.
Pierre: I will prepare a pull request later today, if you could review it and let me know if there are any issues.
Mike: Thanks guys.
Pierre: Shall we go back to #245 which I have now updated?
Nigel: Given the time let's do
that offline please.
... Summarising for the minutes, we have done what we can on
the i18n issues, agreed the disposition response and made a
plan
... to make the resolution to transition to CR or possibly even
PR in next week's meeting for a July 6 publication target.
Nigel: We said we would publish
the WD for wide review by June 30, and that we would need a 2
week review period to approve it.
... We have a number of open pull requests now and no final
draft of the WD to review.
... We also a number of open issues.
... I wanted to propose that we merge all the current open pull
requests and turn that into a draft that the group can
... review prior to approving publication for wide review. That
gives a 2 week review period for everyone. How does that grab
everyone?
Mike: Okay for me.
Nigel: Clearly we can still make
further changes prior to CR, or resolve issues with this
version by pull requests in the next few days as long as there
is
... positive review from enough key people, and no negative
comments.
Dae: I'm more interested in the deadline than having 2 full weeks. 1 week review is enough for me.
Pierre: Movielabs will abstain on this at this time.
Thierry: The proposal sounds reasonable to me.
Nigel: OK then I think we're
agreed.
... I will ask Glenn to progress that.
... Let's go through the pull requests then.
Issue 0384 streaming ttml appendix #389
Nigel: It's appendix R
... I didn't quite do what we said last week in that I didn't
reference the TTML1 appendix but left it in as a
subsection.
... I did that on the basis of one of Glenn's comments on the
issue.
Mike: I would rather do what we said last week and diminish the relevance of the section that isn't common practice by making it a reference back to TTML1.
Nigel: I have limited time
available in the short term to fix this so unless there are
strong objections to what we have I propose to keep it as
is,
... or otherwise I'd welcome if anyone else wants to implement
the reference change.
Mike: I haven't had time to check the detail on the rest of this.
Nigel: Unless there are any more issues or pull requests to discuss let's return to the IMSC topic.
Pierre: On the SDP-US issue the sentence above about EBU-TT-D has the same issue. I'm wondering if we should change that too.
Nigel: That's true.
Pierre: I'm thinking of dealing with that at the same time.
Mike: Having parallel language would probably be the best thing to do but since EBU-TT-D and SMPTE-TT are essential I'm not pushing for that.
Pierre: I'm asking for permission to make the two bullets consistent in language.
Nigel: I agree - please change "should not be present" to "is not present" for EBU-TT-D.
Mike: I'm happy with that.
Pierre: Okay I will do that and you'll see the pull request later today. Thank you.
Nigel: We're out of agenda, also time. Thanks everyone. [adjourns meeting]