See also: IRC log
<scribe> scribe: nigel
Nigel: Today we have TTML1 3rd Ed
CR, TTML2, IMSC - general actions and issues.
... There are one or two issues/pulls marked for Agenda.
Glenn: I'd like to raise a question on TTML1 about what we should call the CR.
<plh> https://w3c.github.io/transitions/nextstep.html?shortname=ttml1
Philippe: It's just "CR".
Glenn: Pubrules has "First Public
CR", which I selected for TTML2 last night, which worked,
... whereas I noticed that Pierre just used "Candidate
Recommendation" for TTML1 3rd Ed,
... so we should be consistent.
Philippe: I agree.
... I think FPCR is for a CR without a WD. That's not the case
for TTML1, which should just be "CR".
Nigel: Anything else for the agenda?
group: [silence]
Philippe: Is Charter on the agenda?
Nigel: Not right now.
Philippe: Can we touch base on it at the end?
Nigel: Yes
Nigel: What's the status of TTML1 3rd Ed?
Pierre: All substantive issues
have been resolved, and all that's left open are editorial
issues.
... I think we're ready to publish as CR - we should plan on
publishing in 2 weeks,
... merging editorial issues today and starting the 2 week
clock.
Nigel: Makes sense to me. I added this to the agenda:
PROPOSAL: transition to CR of TTML1 3rd Edition based on build available at https://rawgit.com/w3c/ttml1/TTML1-3ED-CR1-build/index.html
<plh> https://www.w3.org/Guide/transitions?profile=CR&cr=rec-update
Philippe: You're not adding features, but you are making substantive changes?
Nigel: Correct
Philippe: I posted a link to the
transition requirements for that, above
... You don't have to publish a WD, you go directly to
CR.
... It could be pretty fast, in general the expectation is that
you're ready to move out of CR
... when you enter CR, because you're just folding errata into
the document. In terms of
... Wide Review, you've published errata already, or you prove
that you have had the right
... people looking at the errata. It should be a pretty short
CR period, 20 days, and after
... 20 days you would go directly to PR.
Nigel: In this case it seems
sensible to avoid a test suite and implementation report
but
... instead to point to existing implementations that already
exhibit the behaviour being
... clarified by the substantive changes.
Philippe: Yes that's right, the
expectation is that there are already implementations.
... You need to back this up with some facts, could be based on
tests or on something else.
... The Directors won't mind what you use. You would need to
provide evidence such as
... an implementer report saying that they already do it.
... There is a desire to make it very easy to update Recs to
make them reflect reality.
Pierre: I believe IMSC.js already matches the proposed 3rd Ed.
Glenn: Same for TTT.
Philippe: Record that in the minutes and you can point the Director to it.
Nigel: Done!
... We have 4 open pull requests, two editorial, and one that
brings in the 2nd Ed errata,
... and a final one to generate a CR version.
Philippe: You don't need to resolve the issues to publish as CR, they can be made at PR.
Nigel: I'm going to propose that
we merge the open pull requests, and resolve to publish
... as CR.
Pierre: I'll take care of the merges.
Nigel: Thank you.
Glenn: No problem.
RESOLUTION: After merging the currently open pull requests, request transition of TTML1 3rd Ed to CR.
Philippe: A reminder: you can publish a new Rec any time if the changes are only editorial.
Nigel: Good to know.
Glenn: I was reviewing the status
- I notice that the link to the implementation report
doesn't
... point to anything.
Nigel: Following the discussion
above, we need to modify pull #343 so we do not point to
... an implementation report but instead will demonstrate that
the updates reflect current
... practice by reference to existing implementations.
... Do we need to be clearer about the exit criteria?
Philippe: You're already asserting that you've met exit criteria by that statement.
Nigel: And the earliest exit date?
<plh> https://w3c.github.io/spec-releases/milestones/?cr=2018-03-15&noFPWD=true
Philippe: 28 days from
publication, which would be April 26th and Rec on May 31
based
... on publication on 15th March. You need to send your
transition to PR request no later
... than April 19.
<plh> Deadline for comments: April 12, 2018
Pierre: I'll replace the exit criteria line and earliest exit date according to what I see here.
Nigel: Anything else on TTML1?
Pierre: No, thanks for your help on this.
Philippe: Anything I can do to make it easier!
Glenn: Thank you Pierre for your editing work
Nigel: We have one agenda topic for today:
github: https://github.com/w3c/ttml2/issues/683
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/683
Glenn: This is a CR2 issue, so we
don't have to resolve it today. In TTML1 we did require
... support for the profile mechanism in all conformant
processors, which included all the
... related syntax and semantics.
... My position is that we should have the same level of
mandate for TTML2 upgraded to
... the TTML2 level of semantics particularly the introduction
of the new contentProfiles
... and processorProfiles attributes. I agree that there may be
some aspects of how it is
... currently defined in terms of features that would allow us
to take out a couple of those
... features, such as authorial ways of specifying
combinatorial methods. As long as the
... default semantics for those parameters are implemented as a
default scenario then I can
... see scaling back what #profile-version-2 means.
... As to the issue of whether a profile is mandated now, I was
referring to a conversation we
... had about the version parameter, if there was a requirement
for some version 2 feature,
... I remember a fairly unanimous position by the WG that all
documents should specify
... profile, which I agreed with. Although I agree we did not
translate that to normative
... language in the spec that mandates a profile attribute be
present, because we have a
... defaulting mechanism. We may need to revisit that as an
issue in CR2, if it is mandatory
... for a document instance to specify a profile. I'm flexible
no that right now.
... I definitely think that TTML2 should have similar parity to
TTML1 with the requirement
... for contenrProfiles and processorProfiles attributes. If we
let implementations have a
... free pass on that it doesn't accomplish our goals.
Pierre: Is there one of those
features that specifically requires the profile
processing
... algorithm including the defaulting? As long as that's
required then we're good.
... TTML2 has really improved the profile derivation
algorithm.
Glenn: The way that those
semantics are written, it does not require a processor
that
... supports profiles to dereference and parse a specified
profile document, in case it might
... not be available. Is it legitimate for a processor to
completely ignore an embedded profile
... in a document though? My current position is that is not
permissible, it should at least
... acknowledge and implement the semantics of profile if a
required feature is not supported.
Pierre: Your argument is if you
don't mandate say the contentProfiles features as part of
... the transformation profile then by default it doesn't
matter what someone write in there?
Glenn: Exactly.
... At the baseline, recognising the semantics of the default
is the baseline, but on top of
... that we at least need to follow TTML1 for support for
embedded profiles.
Pierre: These are required only in the baseline transformation and presentation profiles.
Glenn: Any processor in TTML
terms that ignores an internal profile is not a conformant
processor.
... On the other hand if the document points to an external
profile the processor could avoid
... getting it and then be conformant.
Pierre: IMSC 1 has prohibited those internal profiles.
Glenn: Then you're okay. SMPTE-TT does allow them.
Pierre: There's a way to bypass
the profile mechanism, which is what a hypothetical
... processor would do if it did not support profiles because
of knowledge embedded in the
... document processing context.
Nigel: That's my concern, that a
TTML2 processor that does not implement profile features
... might not be considered a TTML2 processor.
Glenn: Maybe with some notes we
can finagle this so that a processor that always does
... an override is not deemed non-compliant.
SUMMARY: Add informative text explaining how a processor that does not support the "required" profile features can nevertheless be considered a conformant TTML2 processor.
Nigel: There are 8 issues marked for "agenda", 7 of which relate to yesterday's joint call with APA.
Nigel: Effectively we discussed
only one issue, and I got the feeling that the others are
not
... considered so important, but Janina did say she would go
back and check them.
Pierre: That was my feeling as well.
Nigel: The main concern was that
the spec should not prevent implementations from
... allowing some kinds of customisation or adaptation for
accessibility needs, with the example
... provided being increasing the font size.
... I think we took an action to add informative text.
Pierre: Specifically to link to the MAUR, pointing authors and implementers to that spec.
Andreas: I'm not sure if this
belongs in IMSC, TTML or any of the specifications. I agree
with
... some of the comments from yesterday, that for an
implementer, some guidance about
... achieving e.g. customisation of font size with TTML or IMSC
is useful. It is not completely
... arbitrary what kind of customisation is needed - mostly
font size, colour and background colour.
... Possibly not in that spec but in some customisation
guidance you could point implementers
... to a strategy how to achieve that and what to take care
about. For example for font size
... you need to ignore any kind of specified font size and
apply just one to all of the elements.
... I'm not sure at the moment how this should look concretely,
but I'm sure we could help
... implementers to achieve such a feature.
Nigel: It is difficult when the problem space is open ended and so is the authoring practice.
Glenn: That's in the document
processing context in TTML1. I know Mike was in agreement with
that
... following analysis of the US requirements at that time.
Pierre: In the US there are legal
requirements.
... As I mentioned it would be incredibly helpful for someone
to do some analysis of the
... global requirements. I'm fairly convinced that neither IMSC
nor TTML is the right place
... to do that. The APA group is better placed to take that
on.
Andreas: I do not completely
agree here - the regulation is diverse, but I think you will
find
... font size in nearly all the customisation requirements that
exist. Some hints about what
... you should take care about can be given by the spec.
... For example you need to know that regions don't dynamically
grow with font size, which
... may be different in TTML to other specs . How you customise
based on TTML is something
... we can help with.
Glenn: I'm sceptical but I
suppose it doesn't hurt to look at it yet again.
... The document processing context can determine anything out
of the author's knowledge.
... Screen readers have very different formatting requirements
from CSS based browsers.
Pierre: Andreas's very specific
point is something we can act on - it is useful not just
for
... accessibility but for any author. We can just file that as
an issue and deal with it.
... That's very different to the generic question of how to
deal with customisation to satisfy
... various regulatory and user preference. As someone
mentioned yesterday, one possible
... solution is to show the subtitles on a different device,
which is done in cinemas. The
... broader question of customisation - I'm more than sceptical
that we can solve this.
... I'd like to know if the WG approves of the draft
disposition I've added to the issues.
github: https://github.com/w3c/imsc/issues/321
Nigel: There's an outstanding question which we didn't cover yesterday.
Pierre: Rather than the HTML alt
attribute where the recommendation is for it to be
present
... even if it is empty, we took a different route. I don't see
the need to change anything here.
... In addition, ittm:altText is deprecated so if there's
something to improve it should be done
... in TTML2. My recommendation is to dispose to make no change
or reject.
Nigel: Any other views?
Glenn: Are there two different altText attributes, one in itts: and one in ittm:?
Pierre: No that was a mistake.
Glenn: We went a different route
to HTML, we're saying it's metadata and there is no
... semantic processing requirement.
Pierre: Importantly it is not
equivalent to HTML. alt is mandatory in HTML but can be
empty.
... Here we say that it can be omitted if there's nothing to
say. I think that's functionally
... equivalent, so there's no need to change anything.
... The spec already notes that it is _not_ the same as HTML
alt.
Nigel: Is anyone proposing a change to the spec in response to this issue?
group: [no]
RESOLUTION: The WG disposes that `ittm:altText` is not equivalent to HTML5 `@alt`. Whereas HTML5 `@alt` is required but allows empty values, `ittm:altText` is absent when there is no value. `ittm:altText` is deprecated and specified only for backwards compatibility; it is replaced by the altText named metadata item in TTML2.
github: https://github.com/w3c/imsc/issues/320
Pierre: I have proposed to defer to IMSCvNext, and my comment can be used as the disposition.
Nigel: that's https://github.com/w3c/imsc/issues/320#issuecomment-363529705?
Pierre: Yes
RESOLUTION: WG disposition is as per https://github.com/w3c/imsc/issues/320#issuecomment-363529705
github: https://github.com/w3c/imsc/issues/319
Pierre: I think this is a simple
misunderstanding because SVGs are not permitted, only
PNGs,
... so the comment does not apply.
... We should defer this in case we ever go down the path of
permitting SVGs.
Nigel: Yes
RESOLUTION: WG disposes to defer this until such time as SVG images are supported.
github: https://github.com/w3c/imsc/issues/318
Nigel: It looks like we simply think the proposal is a bad idea.
Pierre: Absolutely, and that's reflecting what the industry is overwhelmingly saying right now.
Nigel: Looking at the comment, I
think it doesn't say that the association data needs to
be
... inside document instances, but that it needs to be
specified.
Pierre: The specification is not the right place to document it - it is out of scope.
Nigel: Yes, that's what I was thinking too.
RESOLUTION: The WG considers the method to signal any association between document instances to be out of scope of the specification.
github: https://github.com/w3c/imsc/issues/317
Pierre: This is not an issue because we do not use colour to signal deprecation in IMSC 1.1.
Nigel: In fact we do not use colour alone to signal deprecation in any of our specifications.
RESOLUTION: WG agrees with the comment, and notes that the TTWG does not use colour alone to signal deprecation in any specification.
github: https://github.com/w3c/imsc/issues/316
Nigel: This is what we largely discussed yesterday.
Nigel: Specifically, call out:
"JF agrees with the proposition that an informative note citing
this MAUR document would improve the caption-related
specifications."
... We could do that by modifying appendix D to include MAUR
considerations additionally.
Pierre: Sounds good to me.
... I'll prepare a pull request.
SUMMARY: @palemieux to prepare a pull request adding reference to MAUR.
github-bot, end topic
github: https://github.com/w3c/imsc/issues/315
Pierre: We had disagreement over pull request #326 that we should discuss now.
Pierre and Nigel: [discuss stuff already in the pull request]
Pierre: [proposed an edited version combining best of both proposals]
Nigel: Obviously if Image is used
because semantics not available in TTML are needed then
... it is no longer feasible to distribute Text and Image
Profile documents representing the same content.
Pierre: I think we cover the
point about distributing both text and image versions of the
same
... content sufficiently.
Nigel: Ok, the updated version
works for me.
... I've approved it.
... I'll ping the commenter to request review of the pull
request now that we think
... we know what we want to say.
RESOLUTION: WG disposition is to make the edits
as per pull request #326.
... @nigelmegitt to prompt the commenter for a review of the
pull request
github: https://github.com/w3c/imsc/issues/236
Pierre: This is an issue that we seem to come back to regularly.
Glenn: I predicted this would happen.
Pierre: My challenge is I don't
understand what the commenter wants.
... TTML1 and TTML2 already require support for Unicode
characters, so an implementation
... cannot reject a document because it does not accept a
unicode character.
Glenn: That's correct. It need not have rendering support or fonts.
Pierre: The spec is trying to be
helpful to implementers who do want to support particular
... languages or scripts. My suggestion is to organise a call
with i18n and try to get down
... to what they are trying to achieve. We seem to be talking
past each other.
Nigel: I can take an action to try to set that up.
Glenn: My response would be "No.
Font and unicode rendering capabilities are an implementation
dependent property in TTML1."
... Of course in TTML2 with downloadable fonts that opens
things up a bit, but generally
... you cannot support a complex script without adding code, so
just adding a Mongolian
... font won't cut it.
... I would suggest focusing on the characters aspect not the
rendering aspect.
Philippe: Can I try asking a few
questions to see if I can channel Richard?
... Right now are you saying you don't expect implementations
to support UTF-8 necessarily?
Pierre: No, IMSC1 requires support for UTF-8 and TTML requires support for Unicode.
Philippe: Are you saying you should not use a character outside the encoding you are using?
Pierre: No, the purpose of the
annex is to help an implementer select which particular
... character they should render. Noone renders all Unicode
characters. They make a decision
... on which set of characters they render based on
requirements such as territory.
... This section is to help implementers.
Philippe: Right now it is worded from the point of view of the author not the implementer.
Pierre: Originally it was a
Processor recommendation, and I think Dave Singer got
really
... upset by that, so we changed it to an authoring
requirement.
... In my mind this is really a processor requirement.
Philippe: r12a's suggestion is also a suggestion for implementers.
Pierre: Yes, but if we change to
a processor requirement we might get the same objections
... as we had before. For all intents and purposes they are
equivalent.
Philippe: I think we should invite @r12a to this conversation.
Pierre: We're definitely not saying that some scripts do not need to be supported.
Glenn: "Supports unicode" is an
overloaded phrase. It just means support for the
character
... semantics irrelevant of their formatting.
Philippe: In that case the treatment would be the same for all characters. Why only those?
Glenn: Yes, that's why I suggested not having this section in the first place.
Nigel: I'll invite him to a discussion.
Philippe: I haven't had time to talk to Thierry about this - are you aware of any movement
Nigel: No, the action was with
Thierry to organise time with him, me and Dave, so far we
... haven't found a mutually acceptable time to meet.
Glenn: [discussion with Philippe about publishing TTML2 CR mechanics]
Nigel: Philippe, please can you
take care of the transition request?
... We already have the resolutions in place.
Philippe: Yes, I'll do things on
my side, assuming I can do it today the earliest
publication
... date is 8th March.
... I'll look in the minutes for the resolution.
Glenn: The CfC ends on Monday.
Philippe: If I make the transition request on Tuesday then we will publish on March 13.
Glenn: I'll put that date in the document, plus 4 weeks later (April 10th) for the end of comments period.
Philippe: Nigel, send me a ping if I don't make the transition request on Tuesday.
Nigel: Thanks everyone for attending today. [adjourns meeting]