See also: IRC log
<scribe> scribe: Nigel
nigel: [runs through proposed
agenda]
... AOB?
group: no AOB
nigel: Goes through action items.
action-383?
<trackbot> action-383 -- Glenn Adams to Missing XML declaration -- due 2015-04-30 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/383
glenn: I believe I've closed that because it was essentially a byte order mark issue that was appearing and should not have been.
action-383: [Meeting 2016-02-25] Glenn notes that this was completed; the cause was an erroneous byte order mark that has now been removed.
<trackbot> Notes added to action-383 Missing XML declaration.
close action-383
<trackbot> Closed action-383.
nigel: The status here is that we have a draft PR doc that Pierre has generated, and a meeting with the Director scheduled.
tmichel: I think we need to have
a new draft with 2 small changes.
... 1. The CR version date (for the previous version) was wrong
due to a bug - it should be 28 January 2016.
... (it currently says 2015).
... 2. The end of the PR review should not end before the 8th
April, for 2 reasons: first we need a 4 week PR review
... and second the IPR exclusion period. Currently it says
April 1 so that needs to be changed.
pal: Thank you, I'll do that immediately.
tmichel: It's not really urgent but I would prefer to have everything fixed for the Director.
pal: I'll get it to you in the next few minutes.
tmichel: Then I'll post it to the
URL I used before, and after the Director's call move to the
publication date. I think
... we had agreed 8th March. I don't think we can do better
than that.
pal: Fine with me.
tmichel: We'll know the final date of publication after the Director's meeting.
PROPOSAL: The group requests transition of IMSC 1 to Proposed Recommendation.
glenn: I have a comment on the
summary of substantive changes. On the second item, issue #146,
I suggest
... removing the adjective "incongruous".
... Also just to note that you'll probably be asked why they
are substantive. I personally would not have called
... either of them substantive, but if you want to you'd better
have a rationale for why they are substantive.
https://www.w3.org/TR/2016/PR-ttml-imsc1-20160302/substantive-changes-summary.txt
nigel: I'm happy to make the case
that by the precise wording of the Process they do count as
substantive even
... though by most ordinary standards they are not substantive
and therefore we are happy to include them
... directly in the PR.
glenn: You might also note that some members do not consider them to be substantive.
nigel: Yes, good idea.
https://www.w3.org/2015/Process-20150901/#substantive-change
nigel: Let's double check these.
https://github.com/w3c/imsc/issues/136
glenn: I'm basing my comment on
the wording "clearly" in point 3 of ยง6.2.5
... For this issue I would say that the previous language was
simply erroneous and it's a correction.
https://github.com/w3c/imsc/issues/146
nigel: Here we have removed a term that did not have a defined meaning.
tmichel: I need to know if these are substantive changes before making the request for transition, which I would like to do.
nigel: Any other views?
pal: I'm happy either to remove
them from the list of substantive changes or to explain them.
Regardless, they
... are extremely small changes that have no practical impacts
whatsoever.
glenn: That's my main point here.
The reason for calling things out is if there is going to be a
potential controversy about the change
... that will require further input from the community. I think
we can agree that these changes will not
... produce any impact on the community.
... It's not productive to have a further delay based on these
changes, I think we can agree.
tmichel: I also believe this will not trigger a new CR, but it will show to the Director that we are not hiding anything.
nigel: I'm checking this in detail. The resolution to #136 clearly modifies conformance language so I think we have to keep it in.
pal: Can we make a resolution that the group does not believe that these changes are practically substantive?
glenn: That would be helpful in
explaining to the Director.
... Here I think our intention originally was to capture the
circumstances for documents that have content in them.
... That still applies. Another way to change the language is
to modify the constraint to say it only applies when
... the document instance has content in it.
PROPOSAL: Amend the resolution to state that the group does not believe that the changes for issues #136 and #146 have practical impact or are inconsistent with the previously published CR.
pal: Even if they are considered
substantive based on the Process there's no benefit in going to
CR again.
... The group is not saying this is a huge change but it's
going to be okay. The consensus is that it has no impact.
tmichel: I support the view that even if the Process says these issues are substantive and we have to report them then we can explain that the group believes there is no practical impact.
pal: It may be helpful if Glenn could post his view to the reflector so we can point to it.
nigel: What I'd like to do is to make resolutions matching both of the above proposals, and take this to the Director.
glenn: I second that.
RESOLUTION: The group does not believe that the changes for issues #136 and #146 have practical impact or are inconsistent with the previously published CR.
<inserted> --
RESOLUTION: The group requests transition of IMSC 1 to Proposed Recommendation.
nigel: Thank you Pierre for your work on this.
tmichel: +1. And we'll be one of the first groups to use the new styling, just after CSSWG probably.
nigel: There is an open Pull
Request from BBC: https://github.com/w3c/charter-drafts/pull/19
... I've not seen any comments on this so far.
pal: Instead of a PR on behalf of MovieLabs I filed some issues on https://github.com/w3c/charter-drafts/issues
nigel: You may find that some of
those are addressed by the BBC's PR.
... Can we consider which license to use - Document or
Software?
pal: In my opinion for IMSC 1 and all work derived from TTML I strongly recommend using the Document license.
glenn: I would concur.
nigel: I'm happy with that.
... That leaves the remaining Rec track deliverables. It
doesn't feel appropriate with the folk present here to impose a
decision.
pal: Can we decide on a document by document basis?
tmichel: It can be document by document.
nigel: Okay so we need a view for
WebVTT.
... Do we only need the license for Rec track docs or all
docs?
tmichel: I'll check and get back to you.
nigel: Any other points on the
charter?
... Pierre, I'll review the issues and check for alignment with
the BBC PR.
pal: So who would take the next pass at editing the charter, plh or tmichel?
tmichel: I can do that.
nigel: I can't merge PRs on this repo - only staff can edit the document I believe.
pal: We need to know when the PR has been merged and when we should review etc.
tmichel: I can do that I
think.
... You want me to make a new PR or to merge the current
PR?
nigel: I'll tell tmichel when I've added notes to the BBC PR describing which issues it closes.
tmichel: Ok
nigel: Can I just clarify that there's no semantic to allow the background box height of inline areas to be set to the line height?
glenn: There's a preliminary
question about what the correct default behaviour is as implied
by the current spec
... language. I have not been able to determine that yet.
nigel: We did do some investigation with XSL-FO and CSS and decided that the box height is not the line height.
glenn: I did some playing around
with Chrome and Firefox and what they are doing is the same but
seems to be
... highly illogical. It may be that the code is not documented
effectively. The first thing we need to do is to answer
... the question what is the current specification semantic,
for example how does leading or multiple font sizes
... on a line impact it? If the answer is that the
implementations don't follow any reasonable interpretation of
what
... we think is defined then we might have to define it better
on our part as the default behaviour. If we want a
... variation from the default behaviour then we need to define
it. I pointed out an issue I raised on Batik, the SVG
... renderer. I realised that I needed to define both
background height and inline height separately.
nigel: I'll post up on the issue any links I've found in researching this so far.
glenn: Keep in mind that this is a different issue from the question of what lineHeight means.
nigel: We're over time so I'll adjourn the meeting now - meet same time next week. Thanks very much everyone [adjourns meeting]