See also: IRC log
<trackbot> Date: 03 September 2015
nigel: Goes through agenda. Any particularly urgent topics?
mike: ATSC liaison.
nigel: Okay, and is there any other business?
pal: I'll only be available for the first 45 minutes so if we could cover the IMSC issues sooner that would be ideal.
group: no AOB
action-418?
<trackbot> action-418 -- Nigel Megitt to Send response back to atsc as per https://lists.w3.org/archives/member/member-tt/2015aug/0019.html -- due 2015-09-03 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/418
nigel: David Singer raised a
concern with the agreed text that it wasn't as clear as it
could be
... about what we were asking ATSC.
... He suggested changing "However, we would like to better
understand the authoring requirement for a color palette beyond
sRGB."
... to "However, we would like to understand your need to
express colors outside the gamut of sRGB, or if there would be
difficulty mapping sRGB colors into the chosen output color
space."
... That was a change to
https://lists.w3.org/Archives/Member/member-tt/2015Aug/0019.html
mike: I don't object to the changes, and I'm happy to explain this at the other end.
nigel: If there are no other changes, I will send this by the end of my working day today.
pal: Okay, that's fine by me.
Action-418: Send revised text as at https://lists.w3.org/Archives/Member/member-tt/2015Sep/0000.html
<trackbot> Notes added to Action-418 Send response back to atsc as per https://lists.w3.org/archives/member/member-tt/2015aug/0019.html.
Action-417?
<trackbot> Action-417 -- Pierre-Anthony Lemieux to Create ticket with unicode for cldr proposal, or add to existing one. -- due 2015-08-27 -- CLOSED
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/417
nigel: This has been done - it's at http://unicode.org/cldr/trac/ticket/8915
pal: There's nothing more to add on this for now.
nigel: I looked at the status of
this and the milestone it has been set for is for the release
in 6 months time.
... They seem to operate on a half-yearly cycle, and I guess
we'll be too late for the release in 2 weeks.
action-419?
<trackbot> action-419 -- Mike Dolan to Add other ttml profiles to the codecsregistry wiki page -- due 2015-09-03 -- PENDINGREVIEW
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/419
mike: I've added all the ones I
know about. The EBU ones took a little digging because
they
... hadn't been published yet, but I got the URLs from
Andreas.
... One question back to EBU and DECE and David Singer is: is
it sufficient to get to the basic
... profile or do we need to signal version level
granularity?
https://www.w3.org/wiki/TTML/CodecsRegistry
mike: I don't recall if the EBU
designators are what they sent me or what I made up.
... For the DECE ones there's a symbolic section to put version
in. It's almost not a question
... for W3C. We should have a consistent policy and cooperation
with MPEG on how granular
... the designator needs to be. We either need an algorithm
like we did for DECE, but then you
... wouldn't be able to discriminate the version from the short
name.
Andreas: What is the reason behind the limitation to 4 characters. Is it strict?
mike: It's desirable, because if
we want to move this to the MP4A they would have to be 4
character codes.
... As far as our registry goes it just has to be a small
length. This might be relevant because
... currently there are a lot of missing standardised codes for
codecs, like for HEVC and other things.
... The original MPEG approach was for RFC 6391, and every time
we wanted a new version we
... had to publish a new document.
Andreas: I wonder which has more
importance. The other question is if we have a
requirement
... to signal the version of the TTML profile through the
identifier. I think we do have that
... requirement. TTML has the advantage that it can limit its
own profile to tt.. with the number
... at the end. I think some signalling of versions should be
possible in the identifier. That's
... important, especially if there's a major version
change.
mike: I see that. I think that's
the question. If we want to have a short name that signals
that
... then we can start with 1 and hope we don't run out of 1..F
numbers.
pal: What about 2x 4c codes, one for format and one for version?
mike: Are you suggesting overloading the 2nd 4c code?
Andreas: the reason if I
understood right for the 4c code is that it would be easier to
move the
... codes to another registry later, that has the strict
limitation of 4 characters.
mike: Exactly. I'd like to engage
David on this, so we can continue this offline with him
wearing
... his MPEG hat and see what he thinks is advisable. In the
meantime Andreas do you want me
... to modify the table?
Andreas: I think it would be good
to use the URIs we defined for EBU-TT-D, and for EBU-TT
... Nigel, Frans and I need to check what we will use.
Frans: Yes.
Andreas: We'll send you an email
possibly today or tomorrow.
... With the profile definition, we had a discussion earlier.
What I understood from Glenn was
... that a profile definition could be a document that
restricts the profile of TTML.
nigel: I think the confusion here
is that we did agree to map an identifier to a
specification
... without a TTML profile definition document.
... There are already some entries in the table with n/a on the
Profile Definition column.
mike: That's right. If Profile
Definition Documents get created later they can be added to
the
... table later.
Andreas: Makes sense.
nigel: I'd like to close the action and if there are more changes to make then track them separately.
mike: Clearly there's more work to be done, with an action on myself, Andreas and David to talk more about the version topic.
close Action-419
<trackbot> Closed Action-419.
nigel: Thank you!
pal: I think I captured all of Glenn's input as separate issues starting with Issue-404.
issue-404?
<trackbot> issue-404 -- Where is #image feature defined? -- pending review
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/404
pal: Glenn asked where the #image
feature is defined. That is in SMPTE-TT so ST2052-1.
... The way it works in the document is that #image is defined
relative to the smpte-tt extension
... namespace, and in §6.3 the namespace is defined, so I think
that's pretty straightforward.
... I don't know what to say more than that so unless Glenn has
more specifics I think that's fine as is.
issue-405?
<trackbot> issue-405 -- why is #nested-span prohibited on image profile? -- pending review
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/405
pal: Glenn noticed that the span
content element is forbidden, and asked why nested span
is
... also prohibited. I think the answer is that one of the
goals was to list explicitly every feature
... and whether it is allowed or not allowed to reduce any
potential ambiguity.
... Again, unless Glenn has a more specific concern my
inclination is to do nothing.
issue-406?
<trackbot> issue-406 -- #lineBreak-uax14 is never 'used' by a document? -- raised
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/406
pal: Glenn points out that
documents never use the feature because it impacts only
the
... presentation processor. The question I have is: if I read
TTML1 correctly, this instruction is
... sent to the processor through the presence of a feature
designator in a profile attached to
... the TTML document. This is unusual maybe. One question is:
what is the default? If nothing
... is specified is the implementation not supposed to support
uax-14 or is there no default?
... Since Glenn isn't on the call I'll email him.
mike: I took this as a more
generic comment not specific to this feature. What you say
seems
... really odd to me. I thought it was about the choice of
English "used" vs "shall".
pal: If you read TTML1 §9.4 it
says that if a profile requires the usage of the feature ...
then
... the processor shall use it.
mike: So it's a parameter?
pal: That's what's weird - it isn't a parameter.
mike: So it is pretty
special.
... I think we need Glenn to sort this out. It's odd.
pal: I was really surprised that
it isn't a ttp: parameter.
... The secondary question for EBU, DECE and others is: what is
the default? If you don't get
... a profile document with the #lineBreak-uax14 in what should
the processor do?
mike: I understand the comment
now because we don't have a profile document in IMSC 1
... so this could never be interpreted as anything other than
the default, which is undefined.
pal: Thanks for the summary! I'll ask Glenn, otherwise I can't make progress on it.
reopen issue-406
<trackbot> Re-opened issue-406.
<scribe> ACTION: pal follow up with Glenn on issue-406 [recorded in http://www.w3.org/2015/09/03-tt-minutes.html#action01]
<trackbot> Created ACTION-420 - Follow up with glenn on issue-406 [on Pierre-Anthony Lemieux - due 2015-09-10].
issue-407?
<trackbot> issue-407 -- Excluding #bidi and #direction on image profile is inconsistent -- raised
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/407
nigel: On the linebreak-uax14, I
had taken it to mean that processors that don't implement
... the algorithm shouldn't process documents that require it,
but those that do implement
... the algorithm can process any document.
pal: On issue-407, the point that Glenn raised is that's it is inconsistent. My action is to propose some concrete changes.
Andreas: Is it writingMode or
direction? I think direction and bidi are a pair, but
writingMode
... can be used independently of bidi.
pal: The #bidi feature depends on
#direction, #unicodeBidi and #writingMode-horizontal.
... I have to dig into this and figure out exactly what's
happening. The fundamental issue
... that Glenn is pointing out is that the #bidi feature says
"shall not be used" and yet
... #writingMode-horizontal is allowed. The second issue is
that #bidi is supported if it
... supports all the other features. If may be possible to
support a subset of the other features.
Andreas: That's my understanding
- I see no contradiction because if the #unicode-bidi
feature
... is not supported you don't care what's there, and
#writingMode-horizontal makes no reference
... to #unicodeBidi. I can't see the problem.
pal: I understand Glenn's problem
to be that it says "Shall Not be used" and one
interpretation
... is that it means that none of the subsidiary features can
be used. The other interpretation
... is yours, which is to say as soon as one of the subsidiary
features is not supported then bidi
... is not supported. Maybe there's a better way of wording the
current table.
reopen issue-407
<trackbot> Re-opened issue-407.
issue-408?
<trackbot> issue-408 -- Initial value of color -- pending review
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/408
pal: Glenn says it doesn't make
sense to define a default colour of white. I see nothing in
TTML1
... that prevents an application from defining the initial
value of tts:color. The IMSC 1 spec
... just does that. I see no reason it can't be done.
mike: Taking a pedantic approach,
there's a distinction between a profile and an
application.
... Clearly an application needs to define a default colour.
The question is whether you can
... define it in a profile. I can see Glenn's point although I
don't agree.
nigel: That's interesting. I
quite like the TTML1 approach of not defining a default colour,
because
... it doesn't make sense given video of unknown colour.
pal: The initial value of the tts:color attribute is considered to be implementation dependent.
mike: Then I take exception to
Glenn's comment and I think it's okay to define a default
color
... in a profile. Profiles have the right to do that - see
SDP-US for example.
pal: Unless Glenn can point to a conformance issue my inclination is to do nothing on that one.
Courtney: I'm just finishing
formatting the document and should be able to post it
maybe
... tomorrow, so I'll work with Thierry to figure out the next
step.
tmichel: Yeah, sure, when you're done ping me and we'll see where to publish, and go for it.
nigel: Shortly before the meeting
I sent round a tiny update to Andreas's proposal.
... I added to the What? section:
... "The default onenter() handler in the HTMLCue interface
would attach the cue data to the target element; conversely the
default onexit() handler would clear the target element's
HTML."
Andreas: I did not check on the
interface, but that's fine for me. I think it's fine to give
more
... concrete information regarding the HTMLCue interface. From
my side it would be good to
... go ahead.
Action-415?
<trackbot> Action-415 -- Thierry Michel to Send nigel email addresses of htmlcue proposal reviewers -- due 2015-08-27 -- CLOSED
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/415
action-416:
<trackbot> action-416 -- Nigel Megitt to Edit proposal and send to htmlcue proposal reviewers as listed by tmichel, following action-415 -- due 2015-08-27 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/416
action-416: [meeting 2015-09-03] Go ahead with Nigel's proposed edit
<trackbot> Notes added to action-416 Edit proposal and send to htmlcue proposal reviewers as listed by tmichel, following action-415.
nigel: I'll give people a short
opportunity to respond to this before sending hopefully early
next week
... in case there are any other comments from those who
couldn't attend today.
nigel: Unless someone wants to
step in and chair then our next meeting will be Thursday 17th
September.
... That's what we'll do then unless I hear otherwise.
... We're out of time so I'll adjourn now - see you in two
weeks if not at IBC!
... Thanks everyone. [adjourns meeting]