- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 17 May 2018 16:43:45 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D7236E2D.5C741%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at: https://www.w3.org/2018/05/17-tt-minutes.html
Reminder: we have no call on 24th May
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
17 May 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/05/17-tt-irc
Attendees
Present
Nigel, Cyril, Glenn
Regrets
Thierry
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This Meeting
2. [5]TPAC 2018
3. [6]TTML2 items labelled as Agenda
4. [7]Rename and refactor module subsections. ttml2#591
5. [8]Generic processor conformance too strict. ttml2#673
6. [9]Move processor conformance out of #validation
ttml2#689
7. [10]The #extent-measure designation includes the value
auto. ttml2#690
8. [11]Move processor conformance out of #validation
ttml2#689
9. [12]Use of PNG image format. ttml2#694
10. [13]Use of HDR images. ttml2#695
11. [14]Negative feature designators aren't future proof.
ttml2#697
12. [15]Rewrite version 1 features as references to
[TTML1]. ttml2#763
13. [16]Disallow `<length> left` and `<length> right`
syntax. ttml2#711
14. [17]Definition of implicit inline region ttml2#727
15. [18]Featurize offset times w/o metric. ttml2#752
16. [19]Meeting close
* [20]Summary of Action Items
* [21]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This Meeting
Nigel: Today, I don't think we have anything to discuss for
Charter, I do need to quickly
... cover TPAC, then I expect the main part of the meeting to
be taken up by the TTML2
... issues marked as agenda.
... Any other business, or particular topics to cover other
than those TTML2 agenda issues?
Cyril: No
Glenn: No
Pierre: [silence - getting coffee?]
Andreas: No
Nigel: Great, let's get going.
TPAC 2018
Nigel: The draft schedule has been published, as linked on the
agenda:
[22]Draft TPAC 2018 schedule
[22] https://www.w3.org/2018/10/TPAC/schedule.html
Nigel: This has us meeting on Monday and Tuesday, and also has
the CSS WG and Media & Entertainment IG
... meeting on Monday (CSS WG also on Tuesday).
... The AD CG has time on the Thursday also.
... My question to you guys is do we want to request a change
to the schedule?
Andreas: I definitely think we should request a change in the
agenda. The M&E especially
... has important stakeholders of TTML and so on, and a really
good opportunity to discuss
... TTML specific issues, and as a representative of a
broadcast organisation I plan to join
... the complete meeting of the M&E IG.
Pierre: The fact that it is at the same time as CSS WG is a
good thing because it guarantees
... that CSS folk will be there so we can ask for an hour joint
meeting and have reduced
... likelihood that we will not be able to get them to join.
... M&E IG is a different matter.
Nigel: I've also been talking to my colleague Chris Needham who
is one of the chairs of
... the M&E IG about them moving potentially.
Andreas: My impression of CSS WG is that they have more than
enough to discuss in their
... two days, so it may be easier to schedule a joint meeting
if we do it on another day.
... The attendance we had last time in the joint session was
sufficient to bring in the major points.
Nigel: I think what I'm hearing is we want to avoid a clash
with M&E and to arrange a joint
... meeting with CSS WG however that is most conveniently
achieved.
... The next question is about our flexibility.
... Could we for example ask to meet on Tuesday and Friday?
Pierre: I could not be present for an entire week at TPAC.
Nigel: Implying Mon/Tue or Thu/Fri?
Pierre: Yes, with a preference for Mon/Tue
Nigel: Any other constraints on us moving the meeting dates?
Andreas: No, I should be available on Mon,Tue, Thu and Fri.
Nigel: Okay if there are no other views that's enough for me to
take back.
TTML2 items labelled as Agenda
Nigel: We have 15 open items labelled as agenda in ttml2:
[23]TTML2 agenda items
[23] https://github.com/w3c/ttml2/labels/agenda
Rename and refactor module subsections. ttml2#591
github: [24]https://github.com/w3c/ttml2/issues/591
[24] https://github.com/w3c/ttml2/issues/591
Glenn: I don't think we need to do this.
Nigel: I see that it's about moving sections around so that
common text does not need
... to be duplicated.
Glenn: This would cause specref links to lose contextual
information.
Nigel: The second part of the issue is that §10.2.1 should
apply to the audio attribute
... vocabulary whereas it currently looks like it does not.
Glenn: This will make the ToC deeper and cause a wide scale
renumbering which would
... invalidate existing references from other specs like IMSC
1.1. I've been trying to maintain
... section numbering referential integrity. Of course we've
had to add new numbers in the
... 10.2 section so those did get renumbered somewhat. I can
see the logic of putting those
... together. It seems like the only reason to do this is to
allow 10.2.1 to apply to both.
Nigel: The audio attribute section does not refer to 10.2.1 and
it is scoped out by the
... section structure. This is the problem.
Glenn: [thinks] What about §10.2.1 is tts-specific?
Nigel: 10.2.x includes the style attribute and everything in
tts namespace,
... whereas 10.3 includes tta namespace.
Glenn: This is editorial only.
Nigel: Are you sure there's nothing substantive implied by the
sectioning?
Glenn: Yes, there's nothing substantive.
... I could put a note in the prologue for section 10 at the
end describing why we have a
... separate section for audio style properties and that these
generic style features apply
... there as well. I don't think there's a problem to solve
here.
Nigel: Why do we have 10.3 at all? Why not just run them into
§10.2?
Glenn: We could do that, but they would all apply at the top of
the list before the tts:
... attributes, using alphabetical ordering.
Cyril: Since this is editorial can we resolve this in CR2 if we
need to?
Nigel: If we can solve it now quickly that would be good. We're
doing this now.
... Any other ideas?
Glenn: Moving the tta: attributes into 10.2 would work
Nigel: Works for me.
Pierre: I don't object.
RESOLUTION: Move the tta: namespace style attributes into §10.2
github-bot, end topic
Generic processor conformance too strict. ttml2#673
github: [25]https://github.com/w3c/ttml2/issues/673
[25] https://github.com/w3c/ttml2/issues/673
Nigel: The summary of this is that it is reasonable to have a
content profile prohibit use
... of features that are mandatory for generic processor
conformance.
Glenn: I don't think we can make them optional because they're
mandatory in TTML1.
... We have another issue that's related, about making
profile-version-2 optional: #683
... In pull #755 I proposed some language in the claims section
that allows for conformance
... without supporting the mandated features. I think that
applies in this context too.
Nigel: Yes, I see that.
Glenn: You're saying you might have a profile that doesn't
support things that seem to be
... mandated by the official minimum profiles, which is not
unreasonable and has been done,
... for example EBU in excluding the profile features. So your
additional comment will be
... dealt with by pull #755.
... Basically a processor can be a ttml processor but cannot
claim conformance as defined
... by the conformance clauses.
... It can claim generic conformance but not one of the two
special ones.
Nigel: But §3.2.1 bullet 4 requires support for everything
listed as M in §E.2.
Glenn: That doesn't mandate support for e.g. #profile.
Nigel: The way I read it is does, because step 4 must be
satisfied, and doesn't refer to
... any profiles, just the specification, and it clearly
relates to things listed as M in §E.2, which
... includes `#profile`.
Glenn: I see what you mean. It's possible that the note is
wrong in the context of such a
... content profile not requiring support for everything listed
as mandatory.
Nigel: Good, we're on the same page in terms of the issue at
this point.
Glenn: Either you have to implement everything even if use is
prohibited by a profile, or
... we somehow relax that language to permit the creation of an
implementation that doesn't
... require support for all those mandatory features.
Nigel: Yes
Glenn: An option is to have a lower case ttml processor
conformance state that does not
... include Generic Processor Conformance.
... Back in TTML1 days we had a huge discussion about minimally
required features. The
... first chink in that was when EBU-TT was created. Just a
historical fact.
... Now with IMSC we seem to be following the same path.
... It looks like we'll need some more thinking on this.
SUMMARY: Issue discussed and mutual understanding improved,
more thought needed.
Move processor conformance out of #validation ttml2#689
github: [26]https://github.com/w3c/ttml2/issues/689
[26] https://github.com/w3c/ttml2/issues/689
Glenn: This is for Pierre who has asked additional questions on
this.
... [summarises comments on the thread] Pierre, do you still
think there's a problem?
Nigel: We can't hear from @palemieux right now, will have to
come back to this one.
The #extent-measure designation includes the value auto. ttml2#690
github: [27]https://github.com/w3c/ttml2/issues/690
[27] https://github.com/w3c/ttml2/issues/690
Glenn: Looks like Pierre responded...
Pierre: Yes, the note would really help. This was caused by the
fact that the terms are
... identical but mean something different depending on the
context.
Glenn: OK
RESOLUTION: Add a note as per the comments in the issue.
Move processor conformance out of #validation ttml2#689
github: [28]https://github.com/w3c/ttml2/issues/689
[28] https://github.com/w3c/ttml2/issues/689
Pierre: I think there is still a problem. We have a conformance
section, §3, where conformance
... of various kinds of processors is defined, and suddenly in
the validation feature there is
... a definition of a validating processor and I don't know why
this is done but not in §3.
Glenn: There is no such thing as a validation processor, though
I did discover two non-normative
... uses of that in the Introduction, which I can remove. A
validating processor is a sub-processing
... step of a content processor, either a transformation or a
presentation processor. There
... is no such thing as a standalone validation processor. It's
an optional bit that gets turned on.
... So there's no need to add a separate definition.
Pierre: An implementation today can be either a transformation
or a presentation processor.
... Why not define a validation processor and an implementation
could be all three at once?
Glenn: There's no need to.
... The only reason for doing so is for the purpose of making
claims. Nobody is going to make
... a validating content processor that is only a validation
processor in my opinion, and if
... they wanted to do so it would be a validating
transformation processor with a yes/no outcome.
... There is no need to add a new class.
Pierre: Then lets remove the words "is a validating content
processor".
Glenn: But that's the point of that section...
Nigel: I'm struggling to see the problem here.
Pierre: The `#validation` feature designators is unique amongst
all the feature designators
... because it imposes more than the processing of vocabulary
but also conformance to
... a particular validating content processor definition. My
suggestion is that if there is really
... such a thing as a validating content processor then it
should be defined in the section
... on conformance. Either way "is a validating content
processor" should be removed, and
... if there is a validating content processor then it should
be added to §3.
Nigel: Okay point 1, why should we not remove bullet 1 from
`#validation`, i.e. remove
... the words "is a validating content processor".
Glenn: This is not the first feature designator that does not
define a syntactic construct,
... e.g. lineBreak-uax14.
... The current specification of ttp:validation does not
mandate support for a validating content processor,
... it defines semantics that apply to a validating content
processor but does not require
... it to be one. I could just move support requirement to
ttp:validation.
Nigel: Isn't support for `#validation` something that implies
that the supporting processor
... is a validating processor?
Glenn: It would mean that logically there is no effect.
... The `#speech` designator uses the same language. We don't
define a conformance
... section for a speech synthesis processor.
Nigel: They aren't identical, you could use the same approach
for speech to validation.
Glenn: There are two things I could do:
... I could use more of the approach taken within `#speech`.
... Or I could use the phrasing from speech to make it explicit
that validation is an optional
... component of any content processor.
Pierre: I still don't understand - the current definition says
"if it is a validating content processor"
... I follow the link to the definition and it doesn't tell me
anything.
Glenn: That's a good point, which I was thinking about. The
real intent is to implement the
... semantics of §5.3.1.
Pierre: Why not just say that, instead of "is a validating
content processor" just say
... "implements the semantics of §5.3 Validation"?
Glenn: I could do that, I would prefer to do it in the
definition of the validating content processor,
... because then I could do the same for the speech processor
to make them congruent.
Pierre: Then the definitions section starts to look like a
conformance section, which is my
... point at the end of the day.
Glenn: You could say that for everything. We are not going to
create a conformance section
... for each of the defined features?
Nigel: Would you accept a change to the definition Pierre?
Pierre: No the feature should just refer to §5.3 directly.
Glenn: [scribe paraphrases: this is about consistency across
the spec]
Nigel: The question is Pierre would you be able to accept the
reference intermediated through the definitions section?
Pierre: I would need to study it further.
SUMMARY: @skynavga to prepare a pull request as per the above
discussion for further review.
github-bot, end topic
Use of PNG image format. ttml2#694
github: [29]https://github.com/w3c/ttml2/issues/694
[29] https://github.com/w3c/ttml2/issues/694
Glenn: For this and #605 Mike has suggested that we define
features, which I'm happy to
... do but I don't know exactly to reference.
... I can't do anything without a proposal for a format
definition document.
... Like the ISO definition and reference number etc. I need
guidance.
Pierre: You can use the definitions from IMSC1.
Glenn: Did you define a feature there?
Pierre: No, but if it had one then we could add it to IMSC.
Glenn: Is there a PNG HDR ref?
Pierre: There's the document we published, which references the
PNG format.
Glenn: I suggest incorporating the reference from the note and
informatively referencing
... the note as additional information.
Pierre: Both the note and IMSC refer to the same W3C PNG
document.
Glenn: Okay. That's fine.
... I have enough info to proceed.
SUMMARY: @skynavga to proceed with the new information provided
above.
github-bot, end topic
Use of HDR images. ttml2#695
github: [30]https://github.com/w3c/ttml2/issues/695
[30] https://github.com/w3c/ttml2/issues/695
SUMMARY: As per
[31]https://github.com/w3c/ttml2/issues/694#issuecomment-389905
466
[31] https://github.com/w3c/ttml2/issues/694#issuecomment-389905466
github-bot, end topic
Negative feature designators aren't future proof. ttml2#697
Nigel: (summarises issue as relating to feature comparison
arithmetic and future proofing_
... possible solutions are to whitelist the syntax and
semantics which I understand is a lot
... of work, or to reference the original definition from
TTML1. I wanted input from the group
... because that pushes the effort onto the reader of the spec
to understand the diff between
... TTML1 and TTML2.
Glenn: There's a separate related issue to reference TTML1
feature designator definitions from
... feature designators that are carried forward into TTML2.
... That bumps the definition back to TTML1 that is already in
the wild.
... The second part is the request to specify attributes and
elements and even listing values.
... That would be a complicated process and prone to error and
ambiguity because you either
... have to repeat the definition or you have to summarise or
paraphrase it which is a
... reduction that might result in ambiguity. It also breaks
the "don't say it twice" rule. While
... we do that in some places already, e.g. adding rw and rh
units to length, which are very
... simple, but for larger features like ruby-reserve or the
tts:ruby attribute it would be
... impractical to paraphrase the meaning of that so we
followed the formula from TTML1.
... We don't call out all the sub-features of the attribute.
... While I admit we already have some features with a
whitelist those are the exception
... rather than the rule and I don't want to set a rule.
Pierre: The large number of features that would be affected can
not be a reason not to do it
... because the obvious answer is to get rid of features that
nobody cares about. Or we can
... do it.
Glenn: We'll be here until next year.
Pierre: Or we can let Nigel do it. The large number of features
cannot be an excuse.
Glenn: The review work would be just as much!
... You've approached this from a generic speculative
perspective. I would rather tackle
... this from a bottom-up perspective where we fix individual
problems where we find them,
... and if we can synthesise a rule then we can apply that.
Nigel: I think the counter to this is to mark feature
combination as at risk.
Glenn: That's reasonable. Do we have a feature for that? I am
thinking we don't.
Pierre: Does your comment Nigel apply to those features worded
as "Notwithstanding the
... above support for xyz is not implied"?
Nigel: I haven't thought about that - the examples I was
thinking of were listed in the issue,
... such as `#textEmphasis-no-color`.
Glenn: Nigel you contend that "all defined values" is
open-ended but I would contend that
... it is not, in that the defined values are those in this
version of the specification.
Nigel: I suppose that's logical and we're referring to TTML1
for TTML1 defined features.
... Logically we could future-proof ourselves against later
versions by specifying TTML2
... for newly introduced features also.
Glenn: We need concrete examples to solve here.
Nigel: Going back to the main question I wanted to ask the
group: is it okay to refer the
... reader back to TTML1 for features defined there? Any
objections to doing that?
group: [silence]
Nigel: I'll take that as assent to adopt that approach then.
RESOLUTION: Mark TTML1 features as relating to the TTML1
definition
SUMMARY: This resolution is logged as #763
github-bot, end topic
Rewrite version 1 features as references to [TTML1]. ttml2#763
github: [32]https://github.com/w3c/ttml2/issues/763
[32] https://github.com/w3c/ttml2/issues/763
RESOLUTION: Do this, as agreed in today's meeting.
github-bot, end topic
Disallow `<length> left` and `<length> right` syntax. ttml2#711
github: [33]https://github.com/w3c/ttml2/issues/711
[33] https://github.com/w3c/ttml2/issues/711
Glenn: The open question is whether to adopt the CSS
restriction on position. My contention
... is that there is no ambiguity.
... Do we want to remove the ability to have vertical first, so
you could not say "top left".
... When both are keywords, English conventions argues for
allowing "top left" and "bottom right"
... but you want to make `top <length>` not permitted?
Pierre: Yes
Glenn: Because in that case the second position length is
horizontal not vertical and you
... want to resolve length as horizontal first and vertical
second.
Pierre: Yes
Glenn: I can implement the CSS restriction if that's what the
group wants. I think I
... implemented this and didn't have any difficulty. I can go
along with that for CSS consistency.
Nigel: I would second that, for CSS consistency. Any objection
to applying the CSS rule here?
group: [no objection]
RESOLUTION: Adopt the CSS constraints on ordering
Definition of implicit inline region ttml2#727
github: [34]https://github.com/w3c/ttml2/issues/727
[34] https://github.com/w3c/ttml2/issues/727
Nigel: The discussion point here relates to the pull request
#731. We don't have implied
... inline regions at all anymore, so the feature designator is
wrong.
Glenn: I guess I could change #region-inline-explicit to
#region-inline.
... I would prefer `#region-animation-implicit` for the other
one.
Nigel: OK
Glenn: I'll address the wording too.
Nigel: Okay, thank you.
SUMMARY: @skynavga to update the pull request as per the
discussion above.
github-bot, end topic
Featurize offset times w/o metric. ttml2#752
github: [35]https://github.com/w3c/ttml2/issues/752
[35] https://github.com/w3c/ttml2/issues/752
Glenn: I'll prepare a pull request to bring this back to TTML1
syntax by removing the
... optionality of metric. Then we can hold off on review until
the pull request stage.
Nigel: Sounds good.
SUMMARY: @skynavga to prepare a pull request to remove the
optionality of metric on time expressions
github-bot, end topic
Meeting close
Nigel: Thanks everyone. Reminder: no meeting next week.
[adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [36]Move the tta: namespace style attributes into §10.2
2. [37]Add a note as per the comments in the issue.
3. [38]Mark TTML1 features as relating to the TTML1 definition
4. [39]Do this, as agreed in today's meeting.
5. [40]Adopt the CSS constraints on ordering
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [41]scribe.perl version
1.152 ([42]CVS log)
$Date: 2018/05/17 16:42:55 $
[41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[42] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 17 May 2018 16:44:15 UTC