- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 27 Jul 2017 15:59:49 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D59FCC5D.4557F%nigel.megitt@bbc.co.uk>
Thanks all for attending today's meeting. Minutes can be found in HTML format at https://www.w3.org/2017/07/27-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
27 Jul 2017
See also: [2]IRC log
[2] http://www.w3.org/2017/07/27-tt-irc
Attendees
Present
Andreas, Mike, Nigel, Thierry, Pierre
Regrets
Dae, Glenn
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TAG Report/CSS styling equivalents of TTML2 and
IMSC features
3. [6]TTML1 & TTML2 issues, actions, PRs, editorial
actions etc
4. [7]HDR in PNG
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: Not much for TPAC, there's the TAG meeting to discuss,
as far as I know there's not
... been much activity on WebVTT or IMSC. We might discuss the
issue recently raised about
... TTML1 including things defined in the TT namespace by other
specs.
... We published the HDR in PNG Note.
... Any thing anyone particularly wants to cover, or "other
business"?
group: [silence]
TAG Report/CSS styling equivalents of TTML2 and IMSC features
Nigel: I sent a summary of yesterday's meeting to the reflector
yesterday. Getting an hour
... of TAG time to discuss TTML2 was quite a luxury.
... One of the key things is a recommendation to base TTML2
styling semantics normatively
... on CSS where possible, and it's acceptable in W3C for a
Recommendation to reference
... normatively another spec in CR. CSSWG publishes annual
snapshots of what they consider
... stable and the recommendation is to use the most recent one
of those as the basis.
Pierre: It's strange because things can change after the
reference has been made.
Thierry: It's been this way for a while. I think the snapshots
all point to CRs, but it is still
... possible that things could be removed from those CRs.
Mike: It's important to reference with stable URLs.
Nigel: All the documents on /TR have dated URLs, so they are
stable and persistent.
Thierry: [confirms this]
Nigel: From a personal perspective I don't think this is a very
consistent message - the
... CSS specs that are stuck in CR are there because the test
suites are not complete, but
... we are being encouraged to reference them because the
semantics are better defined,
... even though interoperability has not been demonstrated.
... The counter-argument is that if we don't move with the
times we will be left behind,
... and the times are very much moving away from XSL-FO towards
CSS.
Andreas: Note that things do change in CR - look at TTML1 for
example.
Nigel: That [referencing CSS for styling semantics] was the
main action for us. The other was very positive, that they
agreed that
... the styling requirements for subtitles and captions should
be met by CSS.
... It turns out that the CSSWG is meeting in Paris next week
and they've invited me to
... join remotely some time on Friday next week.
... The idea is that I relay the TAG's message and hopefully
decide on some actions resulting,
... so that when I invite CSSWG to a joint meeting probably on
the Friday of TPAC (to avoid
... clashing with the AC) that meeting can be a progress
follow-up rather than a kick-off.
Pierre: Thanks Nigel for doing this - it is a step in the right
direction.
... We now need to convince the folk from CSS.
Nigel: Yes! Hopefully the CSS Requirements wiki will help. You
may have noticed that
... I didn't try to map ipd, bpd, origin and position, and that
was because I think it depends
... on the chosen layout used in CSS. If anyone wants to
describe the layout requirements
... and map them to CSS layout, that would be really helpful.
Last time we discussed this
... I think Pierre said "flex" was the best way.
Pierre: Specifically to align divs and other block level
elements, yes.
Nigel: Is there already work we can effectively copy across,
saying "here's the layout
... algorithm and in that algorithm this is how ipd, bpd,
origin and position are mapped"?
Pierre: Yes. Before spending a lot of time crafting a proposal,
I'd like to know we have
... agreement to work alongside CSS.
Nigel: I think we can save a lot of time if we already know of
a good layout mapping
... and can remove a topic for discussion because the layout
requirements are already met.
... Or if they are not met, then we need to highlight that.
... I'm asking for help really in completing that part of the
wiki page.
Pierre: I think flex works for the root container, but I need
to go back and check it exactly.
... Flex is used in imsc.js for positioning the root container
in the page and also for
... displayAlign. That's really where it's not possible to
emulate displayAlign other than using flex.
Nigel: Do you put each div and p in a separate flex box?
Pierre: Just the div, it doesn't matter for p because the flex
controls the flow of all block
... level elements.
[10]IMSC.JS code
[10] https://github.com/sandflow/imscJS/blob/master/src/main/js/html.js
Pierre: Around line 465 shows how displayAlign is turned into
flex. It's really straightforward.
Nigel: How do you do positioning?
Pierre: The top left is positioned absolutely. Origin and
extent are dealt with as absolute
... positioning in pixels.
Nigel: That's a start, thank you - I am not sure how things
like ipd and bpd fit into that.
Pierre: I haven't tried that, I don't know.
Nigel: Those were the main points. I did also cover the issue
of TextTrackCues and the
... problem that we've had, and they gave some pointers there,
like talking to the HTMLWG
... and making sure there are issues raised against the
browsers that don't support
... direct instantiation of TextTrackCue.
Andreas: What I need to do is check with the TPAC2016 breakout
session participants on
... how to use the WICG to come to a solution, and I plan to do
this before TPAC, hopefully
... in the next month. That's not necessarily something for the
TTWG for the moment but
... its useful possibly to follow that discussion. That's the
missing action from my side and
... how I imagine the next steps on this topic.
Nigel: While we're on the topic of other groups, I've been
invited to the horizontal review
... session of the Privacy WG later today.
... Thierry, you've done some work on the self-review
questionnaire?
Thierry: Yes I sent it to Glenn and Nigel for review so its
still pending.
Nigel: [reads through] That all looks fine, I'll forward to the
reflector.
Mike: There was IETF feedback on an IANA media registration
unrelated to TTML that XML
... that permits foreign namespace content could undo some of
those provisions.
Nigel: The draft form response is at:
[11]Draft Security and Privacy Questionnaire response for TTML2
[11] https://lists.w3.org/Archives/Public/public-tt/2017Jul/0066.html
Mike: I'll take a look at that offline and post any comments.
By the way all your answers seem fine to me - that was just a
general comment.
Nigel: Thanks, reviews appreciated.
TTML1 & TTML2 issues, actions, PRs, editorial actions etc
[12]Use of attributes in TTML namespace but NOT defined in
TTML1 #251
[12] https://github.com/w3c/ttml1/issues/251
Nigel: I think the question is if anything defined in the TT
namespace is permitted
... according to the grammar of TTML1, in a TTML1 document
instance.
Andreas: Not only that but also who is allowed to define things
in the TT namespace.
Nigel: I take the view that the TT namespace can only be
changed by us.
Andreas: There are two points: one is where the syntax and
grammar is defined, which
... is testable for conformance. In this respect it doesn't
matter where the attribute is
... defined in the TT Style namespace for example. On the other
hand the semantic meaning
... and where the attribute is defined is a different matter.
... My question is more just for the syntax on testing and
validity conformance if it would be
... an error to have tts:foo or whatever and if it is valid
against this grammar.
Mike: We discussed this a couple of months ago.
Nigel: Did we? I thought we discussed foreign namespace stuff?
Pierre: We discussed elements.
Mike: We dismissed attributes because we were clear about it,
so it was a short discussion.
... I'm not sure how we got here, can someone help?
Andreas: As Pierre asked, it just says "{any attribute in TT
Style namespace}" but it doesn't
... define where the contents of that namespace are defined. I
cannot find any specification
... text that says that.
Nigel: In §5.1:
[13]https://www.w3.org/TR/ttml1/#vocabulary-namespaces
... it says "All TTML Namespaces are mutable [NSState]; all
undefined names in these namespaces are reserved for future
standardization by the W3C."
... This closes down part of the problem space, about who can
define, but it doesn't
... explain if TTML2 defined style attributes in the TT Style
namespace are included in a
... TTML1 document instance.
[13] https://www.w3.org/TR/ttml1/#vocabulary-namespaces
Pierre: There are two orthogonal things: who gets to define new
attributes in the tts namespace,
... and what is the behaviour of TTML1 parsers when they
encounter attributes in the tts
... namespace if they do not know them. The phrase "any
attribute in TT style namespace"
... can be interpreted narrowly as just in this specification
or broadly as anything defined
... anywhere in the tts namespace. That's how I read it for
what it's worth.
Andreas: I agree with that interpretation. The two things need
to be separated. I also put
... this question in the tracker because it relates to IMSC and
how IMSC attributes are handled,
... and I asked myself if IMSC and TTML have different
strategies for this. As I read it an
... IMSC processor needs to at least accept any attribute in
the itts or any other namespace
... defined by IMSC, so the current 1.0.1 additions would not
break any IMSC processor.
... I wondered if that interpretation is the same as in TTML1
that any TTML1 processor
... shall not stop processing when it encounters an attribute
in the TTML namespace that
... it does not recognise. Of course it would have no meaning
but it would be allowed
... syntactically.
Nigel: That's interesting - were you thinking about TTML1
processors dealing with
... TTML2 document instances?
Andreas: Yes partly, and there are other constellations where
this comes into play. IMSC
... doesn't allow any TTML namespace attributes but it does
allow any itts or ittp namespace
... attributes. Then what happens if an IMSC processor
encounters a TTML document with
... syntax for which support is not required by IMSC?
... This is more about standard conformance of documents. Then
the question is how
... should a processor handle a document that may not conform
to the grammar.
... If you have the position that a non-conformant document is
allowed to stop processing
... because of its non-conformance, that may be implemented in
some places.
Mike: I agree with that. Then what's the concern? It arguably
confuses TTML1 conformance.
... I see the things that you've pointed out, but is there any
disagreement in the intent?
... Is there anyone who thinks that a TTML1 document is
conformant with lots of tts things
... that are not defined in TTML1?
Pierre: That was how I read it.
Nigel: Me too, and I think it's probably a good thing. That's
because it allows TTML2
... document instances to be processed by TTML1 processors
simply by ignoring the
... unrecognised syntax. There's also separately the profile
mechanism for tightening up
... what's allowed.
Mike: I'm not seeing a problem here. A TTML1 document
containing non-TTML1 syntax
... in the tts namespace shouldn't be considered a conformant
TTML1 document.
Andreas: Would a TTML1 processor be allowed to process that
document or shall it reject it?
Mike: Why would a real processor do that? My answer based on
the spec is that it could.
Andreas: Then the second question is with IMSC without, say,
itts:lineGap. So would a current
... IMSC1 processor be allowed to stop processing because it
encounters attributes in
... itts namespace not in the IMSC1 spec?
Mike: We started with a TTML question and now we have moved to
IMSC - that's a different question.
Andreas: You're right they're two different but related specs
but I wanted to know if they
... take the same approach and check the understanding.
Pierre: I would have to study IMSC1 to check that.
The namespaces defined by this specification are mutable
[namespaceState]; all undefined names in these namespaces are
reserved for future standardization by the W3C.
Nigel: The section on Namespaces in IMSC 1 says: the above.
... It also says "A Document Instance may contain elements and
attributes that are neither specifically permitted nor
forbidden by a profile."
Andreas: This wording is not explicit in TTML.
Nigel: It is quite useful.
... I also see that in the Conformance section the normative
provisions from TTML1 apply,
... which deals with the syntax, but the semantic support is
only required for things specified
... as permitted by the profile.
Mike: That's what it should say.
Andreas: But if there are TT namespace attributes that affect
the presentation then there's
... no contract to do something acceptable, so it should be
okay to stop processing. I can
... see it the other way around that it's better to do
something than nothing.
Mike: It's the difference between the explicit or implicitly
signalled profile. If a document
... claims to be 1.0.1 document and it has a bunch of other
stuff in it then its an invalid document.
Nigel: I don't agree.
Mike: I don't think the intent was to allow arbitrary
attributes and claim conformance with TTML1.
... If that were hypothetically true then yeah maybe the
presentation wouldn't be as intended.
Nigel: But this is exactly how web specs work - processors need
to be forgiving to
... unrecognised syntax and future specs may define things. The
idea is that older
... processors should try to do something at least okay with
the subset of syntax they do
... support even if it's not ideal. For example tts:ruby
attributes would be ignored by a TTML1
... processor and would lead to radically different
presentation but hopefully it wouldn't
... be completely useless.
Mike: I wouldn't expect a TTML1 processor to process documents
with tts namespace attributes from TTML2.
Pierre: How would you expect new attributes to be added?
Mike: It's not sufficient only to have the namespace, so the
profiling or versioning mechanism
... would need to be used. There shouldn't be any expectation
on a TTML1 decoder to do a
... successful processing job on TTML2 documents.
Pierre: That would mean that a TTML1 document would be
considered non-conformant
... from a specification standpoint if it had a tts: attribute
not in TTML1?
Mike: Correct, that's my view.
Pierre: Then what if I want in TTML1.1 to add an attribute that
is supplementary in such a
... way that it would not break TTML1 processors - how would I
do that?
Mike: One option is to create extensions in another namespace.
In TTML2 we chose not
... to do that but to reuse the TTML1 namespace and this
creates that side effect.
Pierre: Thanks, I think I understand. What coloured my
interpretation is that web standards
... tend to be really loose and allow things in the same
namespace.
Mike: I don't disagree with that - we're talking about specs
not processors.
Pierre: So to add any new feature a new namespace is needed to
avoid breaking conformance?
Mike: There are concrete examples in other places that use XML
that do exactly that. They
... create new features in new namespaces.
Nigel: I want to avoid content providers having to provide
processor-version-specific
... documents, which the new namespace idea can do.
Pierre: The mutable namespace statement makes this more
confusing.
Andreas: I wanted to raise this not to pursue one particular
outcome but to establish if
... there is a common reading of the spec; it is clear from
this discussion that there is not.
... Then we may need to add something to TTML1 or not depending
on what our view is.
Nigel: I think we've gone as far as we can on this for the time
being without Glenn's input.
HDR in PNG
Nigel: We published this Note at
[14]https://www.w3.org/TR/png-hdr-pq/
[14] https://www.w3.org/TR/png-hdr-pq/
Pierre: Someone noticed a typo. How do we deal with that?
Thierry: Publication of a WG Note is really easy so we can do
it whenever we like. It's just
... a matter of a WG decision how to proceed.
Pierre: It's literally a typo.
Nigel: I think just fix it and publish - it's completely
obvious what the typo is, so nobody
... is going to be upset with it being fixed in place.
Pierre: I'll try the auto publishing system - Thierry I may
need your help!
Thierry: okay!
Nigel: Thanks all, we've run out of agenda for today. I'm not
around on 17th and 24th August
... so if anyone wants to step in and chair, let me know,
otherwise the default will be we
... have no meetings those weeks. Thanks everyone! [adjourns
meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [15]scribe.perl version
1.152 ([16]CVS log)
$Date: 2017/07/27 15:57:34 $
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 27 July 2017 16:00:20 UTC