See also: IRC log
<scribe> scribe: nigel
Nigel: We have possible regrets
from Cyril.
... For today, [iterates through agenda]. Any particular points
to make sure we cover, or other business?
Thierry: No.
Gary: No.
Nigel: Okay let's get
going.
... In the light of the low attendance (maybe people were
confused about the start time today?) let's do
... what we can for now.
Nigel: This may affect WebVTT?
Gary: Yes, I think most of the
bugs have been transferred but its possible some old things
could have
... been forgotten.
Thierry: I just saw the message
this morning about Mercurial and Bugzilla. I know they will be
archived
... but I don't know more.
... We have not used it for any TTML based work so this goes
back some time.
Gary: I went to the page and it
says its an archived snapshot so maybe its fine to see stuff
that existed
... but not add new things.
... Also the newest bug on VTT there is 2015, so I'm not sure
how relevant it is.
Thierry: I think Silvia handled it.
Nigel: OK unless someone says otherwise, let's assume there's no action to take.
Nigel: I am 99% sure we
transferred all the Mercurial content to GitHub already.
Certainly the
... GitHub ttml1 repo contains what used to be in the TTML
Mercurial repo, since it was created by
... transfer from Mercurial. For example the draft API docs are
in there, and the requirements docs.
... So I don't think there's any work to do there.
Thierry: I can't think of more on the top of my head.
Gary: There is one old draft spec
on the TTCG about 608 to VTT that seems to be on Mercurial that
may
... be useful to capture.
<gkatsev> https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html
<gkatsev> https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/
Nigel: I see there's a sketch of an authoring guideline.
Gary: We can probably drop
that.
... There's also an old version of the region spec.
Nigel: That's all in the WebVTT spec now isn't it?
Gary: Yes, exactly.
Nigel: Is it worth creating a repo for the 608 one?
Gary: We can just grab it and add
it to the VTT repo as a supplement, just to keep it
visible.
... I think it's outdated and needs to be updated.
Nigel: OK, do you want to do that?
Gary: Sure!
Nigel: Thank you.
Nigel: We've not used the decommissioned CVS for anything have we?
Thierry: No I don't think so. It's different to the CVS for our W3C site, for example
Nigel: Great, so we don't need to do anything there.
Nigel: On the Implementation Report, any answers to the Netflix questions about Japanese language support?
Gary: There is support for ruby
positioning, ta te chu yoko (text combine upright) in
WebVTT
... because they are permitted CSS, but no browser has
implemented it.
... There is browser support for bouten (text-emphasis in CSS)
but it is not on the whitelist for WebVTT.
... Then slanted text: I'm not sure what is necessary for it,
but it seems potentially possible in CSS with
... tranform(skew) but that is definitely not
whitelisted.
... I think Japanese support is important but I don't think it
should hold up getting the current CR
... through into PR, and then the Japanese support can come as
the next thing that I work on.
Nigel: That's clear, thank
you.
... Does that mean web platform tests for ruby positioning
fail?
Gary: There are no tests for it at the moment, and it is something we can potentially add now.
Nigel: I think it makes sense to
do that because it is whitelisted CSS.
... Do you think any implementations might pass that?
Gary: I could likely get it working in vtt.js.
Nigel: I wonder if it might work on iOS.
Gary: Also the cue setting of
vertical is sort-of available. Firefox and Chrome position it
wierdly and
... Safari inverts the two vertical options - it's possible
that can be fixed quickly so I will ping Eric and hope
... it does not hold anything up.
Nigel: That's definitely not one of those WebVTT non-intuitive oddities?
Gary: I'll check but I don't
think so.
... Chrome puts it in the middle. Firefox puts it on the
correct side but indented quite a lot, like a quarter
... of the way in from the side.
Nigel: Thanks for that. Moving on
to the CR publication.
... I see that we published the CR today.
Nigel: There are some things that
need fixing and can hopefully be done in-place.
... The Latest Version link takes you to the old one, https://www.w3.org/TR/webvtt1/
... And I noticed that the changes and diff links are not up to
date, in the SoTD.
Nigel: The addition of at risk features is not listed.
Gary: Yes
Nigel: And the diff is the diff to the old version.
Gary: And it doesn't include the at risk piece.
Nigel: Yes
Nigel: I don't know why this diff
was done in this style, it's odd. We normally see the HTML
diff
... generated by the W3 diff service, which gives nice looking
HTML output.
... It doesn't seem like an Editorial change is needed, can you
please look at it Thierry?
Thierry: I will look into it.
Nigel: There's one other point -
the Editor has not been updated!
... Silvia raised this already, she needs to be moved to the
former Editors list and Gary added as the
... current Editor.
Thierry: As a matter of fact
today I updated the publication on the wiki page - it says
Silvia but when
... I saw the published version I left it like that, because
that reflects what it says.
... Sorry Gary!
Gary: It's ok, I was just focused on getting the CR out there.
Nigel: Thank you Pierre for preparing a simpler charter draft for us to work on.
Charter draft pull request #47
Nigel: Pierre and I had a bit of
discussion offline and I think you processed my comments
before
... opening the pull request?
Pierre: I did one of them, we can go over the other two now.
Nigel: Yes please.
Pierre: One of your comments was
about the sentence present before that mentioned adopting
features
... from other groups like SMPTE, EBU etc.
Nigel: Yes
Pierre: I don't think that's a
scope issue, fairly certain it's not a success criteria
issue.
... So I think it's more of a coordination and dependency issue
with other groups.
... I added a sentence under 4.2 instead.
Nigel: It's good to have that in
4.2, but my request to add it to Scope follows a conversation I
had with
... Philippe, in which I was discussing adoption of live
contribution functionality from EBU, and he said
... no member submission, for example, was needed, because it
was clearly in scope of the WG to do this
... based on the Charter.
... I think we may need explicit permission here rather than
relying on implicit acceptance.
Pierre: We should state the work
we are going to do rather than having an obtuse unmeasurable
statement.
... If we want to work on live contribution we should add it to
the deliverables.
Nigel: On the obtuse and unmeasurable...
Pierre: it's obtuse in the light of what you just said, before I just thought it was unmeasurable.
Nigel: Like you say, it's not a
success criterion, rather it's a permission, so yes, it is
unmeasurable because
... it doesn't require us to do anything.
... I see that the Scope as drafted here already allows for
prepared and live formats, and the
... Deliverables allows for development of new technical
reports, Rec or non-Rec.
... So I think we're probably covered on that point.
... Any other comments about the freedom and permission to do
new stuff?
group: [no other comments]
Pierre: The next question is why
list existing technical reports?
... I guess there are some weird rules about IP where you have
to list WDs, which the team addresses.
... Take SDP-US, why should the group address that
explicitly?
... You pointed out the wiki has that list. I looked at it and
it is not complete.
... If I were reviewing a Charter I think it would be important
to put that list somewhere.
... It's okay for it to be the wiki, my preference would be the
wiki, but the wiki is not complete.
... How do we deal with this?
Nigel: The obvious thing, regardless of the Charter is to complete the wiki list. Thierry?
Thierry: What is the delta?
Pierre: All the Notes and Recs
the WG has produced.
... We can just point to the wiki then from the Charter.
Thierry: Okay, I don't know if that's do-able.
Pierre: The alternative is to
list them in the Charter. The downside is the list may
become
... obsolete when new documents are added.
Nigel: Yes
Thierry: That's the drawback with a frozen document like the Charter.
Pierre: We can delete that then?
Nigel: I think we do need to say
we can update or publish new versions of existing publications,
and
... I prefer to point to the list on the wiki
Pierre: Just pushing that change right now.
Nigel: The wiki list is pretty good, I'm not sure what's missing.
Pierre: I found one at
least...
... The role registry for example.
Thierry: There's a colour code
showing if the spec is done (green), ongoing (yelllow), notes
(blue), abandoned (grey)
... maybe I should highlight it better. Then there's the status
column, Rec/CR/WG Note etc.
Pierre: I pushed that change.
Nigel: Looks good to me, thank you.
Thierry: I will add the role registry.
Nigel: I wonder if the RDF from /TR would help.
scribe: It has Notes in but not the publishing WG by the looks of things.
Thierry: The Role registry is only on the wiki, which is why it is not there.
<tm> https://www.w3.org/wiki/TimedText
Thierry: This shows publications including the Role registry in the wiki. Should I have a link to that wiki page?
Nigel: I would say so.
<tm> https://www.w3.org/wiki/TTML/RoleRegistry
Pierre: Or turn it into a WG Note, I'm happy either way.
Nigel: The wording "entertainment
chain" needs a bit of wordsmithing, to include any media
context
... The only other point I'd make is the scope is restricted to
formats, but should it include APIs, for example?
Pierre: I kept that because it seems core to the existing scope.
Nigel: I agree the current scope does say formats.
Pierre: To mimic the broader
mission we should allow ourselves to publish other
specifications.
... First line would become:
... This group is chartered to develop specifications used for
the representation of timed text in online media.
Nigel: Any objections to
that?
...
... Okay, go for it.
Pierre: Alright.
Nigel: I had a question. The
current draft charter has, under Deliverables, "Normative
Specifications" and
... "Other Deliverables". Is it important to keep that? The
draft we're working on here replaces them with
... Technical Reports, and Other Deliverables.
Thierry: I don't know what a normative specification is, I know what a normative section is.
Glenn: That's a good point,
specifications aren't normative in themselves.
... Say Rec track if that's what you mean.
Nigel: We don't even need to do that.
Pierre: I've done another push to
fix the scope as discussed.
... On the "entertainment chain" point, we can just remove that
sub-clause...
Nigel: Yes, do that (enthusiastically)!
Pierre: Alright, done.
Nigel: Brilliant. I suggest we merge this and use it as the basis for a new review.
Pierre: +1
Nigel: Any objections to merging this?
group: [no objections]
Nigel: Okay please merge
it.
... Still to do, after our review, is addressing the Chair
section and basis documents for listed
... deliverables, which Philippe tells me are both jobs for W3
staff.
Pierre: I will merge that.
Nigel: Thank you Pierre for your work here!
Nigel: Unless anyone has anything
to discuss here, I think the only thing is to note that we are
half
... way through the Decision review period for publishing a new
version of the Note and addressing
... issue 71 later.
Pierre: Tuesday to Thursday is the best I can do at TPAC.
Glenn: Have we signed up to Thursday and Friday?
Nigel: Yes, so far.
... If we scheduled our meeting for Tuesday and Thursday we
would likely clash with AC on both days.
Glenn: Pull #30?
github: https://github.com/w3c/ttml3/pull/30
Glenn: I don't know what we're
waiting on for this.
... We discussed it, and Pierre preferred not to define public
and private, which are gone. I'm just waiting
... for an approval. It's fine to consider backporting this to
TTML2, but I want it wrapped up in TTML3
... first. If it satisfies concerns about new functionality
then that may be something to discuss later.
Pierre: The spec still references private modules.
Glenn: Yes, just in prose, not as a defined term. That was intentional.
Pierre: I'm happy to file a
separate issue on TTML2.
... What I find really hard is not being able to do a diff.
Reviewing the snippets out of context is really hard.
... Any plans to get a diff working?
Glenn: There used to be a W3 diff
service. I haven't tried it for a while, but last year it
wasn't working at all
... and the only way I could get a diff was to request Philippe
to do it manually and send me a link, which
... was inefficient. If the service is working then someone has
it working somewhere. I agree with you it
... would be nice to have it working, but it's orthogonal to
this particular issue.
Nigel: This is important for
working group effectiveness. We already build the spec onto a
different branch.
... all that is needed is to present it in a useful form.
Thierry, can you follow up with Philippe on this?
Thierry: There have been many
requests about the diff tool not working, but the systems teams
has
... not yet resolved that issue.
Nigel: That is part of the
problem, but this is broader than that. The PR-Preview tool can
generate diffs,
... but we can't use it here, which is the painful part.
... It's hard to know what more to do.
... Perhaps we can use htmlpreview.github.io
Pierre: I do have a technical
question about this pull request.
... Document conformance: How does pruning for conformance work
in the context of modules?
... Section 4 step 1.
... It currently refers to vocabulary in section 5 Vocabulary,
but that's no longer true.
Glenn: The pull request modifies
the text in section 4. It effectively incorporates the language
into the
... previous sentence by saying it is defined in terms of a
collection of functional modules.
... It doesn't distinguish between internal and external
modules.
Pierre: The requirement for this
to work, profiles of TTML have to implicitly or explicitly
define the
... collection of functional modules that they support.
Glenn: Yes, and right now I think
that's how they work, and it is implicit at this point.
... All of the feature designators in TTML2 for example can be
associated with some internal module,
... in terms of element and attribute definitions.
... Then there's the additional loosey-goosey link between
modules and schemas.
... The language in 4.1 has always been rather general and I
didn't want to make it less general.
... I also wanted to introduce modules and have it cover the
existing functionality as well as new functionality.
... That language is simpler than what was there previously and
works at least in my mind.
Nigel: There's a lot more
complexity about relating profiles to vocabulary which I don't
think we can
... really address in 4.1 without getting very verbose. This is
probably as good as we can get.
Pierre: Section 5 is still referenced from 4.2 and 4.3.
Glenn: Is that a barrier to resolving this pull request?
Pierre: It's a copy-paste wouldn't you say, would you be able to address it?
Glenn: I see what you mean, not
just referencing 5 Vocabulary.
... I agree and will make that change before I merge it.
Pierre: Fine with me.
Glenn: Thanks for pointing that out.
Pierre: I'm hunting for every reference to section 5 for vocabulary.
Glenn: I'll make those changes and merge if there are no objections.
Nigel: Yes, I've heard no
objections, go ahead and do that please.
... If more issues get raised on the merged text we can address
them later.
github: https://github.com/w3c/ttml2/pull/1050
Glenn: The only comment is to ask if there are any tests, and I don't think we can test it.
Nigel: That's right, so this is a normative change that we cannot test?
Glenn: That's right, it's an
ambiguity being resolved. If it is possible to demonstrate that
an implementation
... ignores this, but how could you test it?
... You could create content but only that implementation could
look at the results and see if they
... satisfy the test. We could create the test without the
sample output.
Nigel: We don't always define the test output as a sample though?
Glenn: We always do for
presentation tests. There's no validation to be done because
it's never specified.
... I think we should go ahead and accept it and we will have
to describe this as a category of substantive
... changes that we cannot test except by reference to
undefined external behaviour.
Nigel: I think that's true, but if we can't test it doesn't that mean we don't need the change?
Glenn: No it's important to
clarify it. In the future we might define the actuate and type
attributes, in which
... case we would have something testable.
Nigel: Can we move on then?
Glenn: Can you add an approval?
Nigel: Yes. Just for the record, any objection to merging this normative change without a test?
group: [no objection]
RESOLUTION: Merge this pull request
Nigel: I've approved it.
Glenn: Thank you.
github: https://github.com/w3c/ttml2/pull/1049
Nigel: I think we need language
here like under tts:extent that describes errors for validation
processing
... and ignoring for presentation processing.
Glenn: If we make that change
here we need to do it elsewhere in the spec too. For
example
... in rubyPosition, where we did not call out validation
processing vs presentation processing.
Nigel: Yes, it would be good to make that kind of change here too.
Glenn: If you'd like to file an
issue asking to qualify the phrase "considered an error" with
"with respect
... to validation processing" elsewhere in the spec, but I
would rather not deal with it here.
Nigel: I'd rather get this right
first time.
... We could do that, it may generate some additional test
cases.
Glenn: Can you take off your change request here and then deal with that in another issue and pull request?
Nigel: I'm a bit grumpy about this but yes, okay.
Nigel: Thanks everyone, we're
slightly over time, so I'll adjourn now. Hopefully we can fit
our work into
... a 1 hour meeting next week. [adjourns meeting]