See also: IRC log
<scribe> scribe: nigel
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.
Nigel: The draft schedule has been published, as linked on the agenda:
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.
Nigel: We have 15 open items labelled as agenda in ttml2:
github: 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
github: 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.
github: 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.
github: 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.
github: 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
github: 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
github: https://github.com/w3c/ttml2/issues/695
SUMMARY: As per https://github.com/w3c/ttml2/issues/694#issuecomment-389905466
github-bot, end topic
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
github: https://github.com/w3c/ttml2/issues/763
RESOLUTION: Do this, as agreed in today's meeting.
github-bot, end topic
github: 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
github: 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
github: 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
Nigel: Thanks everyone. Reminder: no meeting next week. [adjourns meeting]