Meeting minutes
This meeting
Nigel: Today we have IMSC-HRM (PR publication?)
… DAPT issues and pull requests
… Upcoming DST changes
… Anything else for the agenda, or to make sure we cover in the topics mentioned?
no other business
IMSC-HRM
Atsushi: PR was published today. End of review is March 28/29 (depending on time zone)
… We need to get some AC rep reviews, so please ask your reps to submit a review.
IMSC-HRM Proposed Recommendation
Nigel: That's great news, thank you.
… Apologies from me that we had a bit of a rocky time getting to this point!
Atsushi: Also apologies from me that I haven't built a proper set of materials for final review before I
… submitted the transition request.
Nigel: No need, we thought we had done that!
… Anyway, thank you to everyone for getting us to this point,
… and reinforce the message - get AC reviews on the WBS poll they have received, please.
… I think this is now out of our hands! Is there anything else to say about it?
… Just one thing from me. In the WBS poll it mentions that there is one open issue.
… In that issue I made a comment proposing to defer taking any action, so I don't know if we should
… say anything about that in the WBS?
Atsushi: There is no reason to restate that it is not intended to be included in this version, because
… that's implied by PR publication, that there are no more changes planned.
Nigel: OK.
… Anybody clicking on the link to the issue will see that anyway.
Pierre: Thanks everybody, I will merge the pull request to reflect the PR publication.
Nigel: Thanks.
DAPT issues and pull requests for discussion
Cyril: I wonder if we can aim for a CR date, since we are getting very close?
… We had a list of issues marked as Must Have for CR.
… We should review and see if they are still Must Have.
Nigel: Good point. I think the proposal with all of those issues marked Must Have for CR
… is to make them "at risk" features, which is a pull request I think I should raise.
… I think we pencilled in a date for getting to CR before, I can't recall when.
Cyril: Is it reasonable to ask for a CfC at the next meeting, 2 weeks from now?
Nigel: Looking at the list of open issues, I don't think we have a proposal for all the issues, and I think we
… need one.
Cyril: Perhaps we can have an Editors meeting to generate proposals on those and see if we can do a CfC in
… next meeting?
Nigel: Ok, happy to try for that.
Cyril: Andreas, any issues to be addressed before CR. Others?
Andreas: No I don't think so.
Pierre: I don't have any strong feelings one way or the other but my experience is that making changes
… after CR is a lot harder, or you have to be prepared to do multiple CRs, which is probably easier now.
Cyril: Thank you Pierre. At the same time if we think we're going to make a better spec every time we're just
… delaying.
Pierre: You're preaching to the choir! It's good to have a deadline.
Atsushi: Making changes after the first CRS: If we add substantial changes we need to have a review
… of the changes before the next CRS or before transitioning to PR.
… Also we need to identify any specific at-risk sections.
… I'm not sure about the potential changes or developments. I don't think we need to mark them
… as at risk though. In any case, a delta review is not a full review, but is usually done over specific
… changed items. I believe it is not so heavy as first CR publication.
Andreas: I definitely don't want to hold back the publication.
… I remember we had some issues where we said we may have different opinions but we want implementation experience.
… Do we have to look at these again?
… Also, when I do my reviews I take time to look over the complete spec to see all changes together.
… In the last weeks and months the spec has changed considerably, I'm sure for the better.
… We need to allow time to make it possible to have a complete review.
… That could be the CfC, I don't know. Just a thought.
Nigel: There are probably a number of pull requests that need to be opened and merged quite soon to deal with some issues.
… I think they can be rolled into a CfC as well.
Cyril: I think an editor's call can result in pull requests and the CfC can be pending review of them.
… I don't mind 2 or 4 weeks but I would like to get us started.
Nigel: Agreed!
Cyril: I don't think we're missing any features. In the past month we've been clarifying things but
… not adding any features, just making sure things work together.
Nigel: Yes
… That feels achievable to me. Editor's call tomorrow or next week, then PRs out, then CfC for CR publication request.
Clarifying what is normatively permitted in a DAPT document
Nigel: Two related comments:
https://
Nigel: The topic here is thus:
… Right now DAPT defines a data model and a mapping from that model into TTML,
… plus a set of formal TTML features and extensions that are optional or required for processors.
… In issue #192 Clarify language application and inheritance model we had a conversation about
… whether we should say that language is inherited from an element that otherwise doesn't look like it can
… have language specified on it, i.e. Script Event Description inheriting language from Script Event
… The other point is in pull request #158 clarify what spans are possible in a text and how they are handled
… Cyril asked about bidirectional mapping e.g. what if the TTML elements representing a Character, contain more than the few elements specified in the spec
… I made a proposal that the TTML2 features and extensions dispositions are the normative specification.
… The other thing I think we should take care about is the Data Model section is normative
… and we may need to be careful about whether the diagram is considered normative or not.
Cyril: I understand the commonality between these two things. I think they can still be considered separately.
Andreas: I think you summarised the main issue from my perspective.
… There is a lot more possible in the syntax representation than the data model.
… That may be confusing for the user. xml:lang is just an example. You can use it on body and div
… but it's not mentioned in the spec.
… Some people might use it but implementers might ignore it.
… The relationship between data model and syntax representation may need to be made clear.
… Either say that more might be in the document than in the data model,
… or recommend that people write TTML documents that conform to the data model.
… At least some clarifying text would be useful.
Cyril: On the xml:lang question I think an easy solution would be to allow language on script events.
… It wouldn't hurt and would make it easy.
… On the span question, my point in the pull request is that the text goes beyond what the rest of the spec does.
… Instead of saying the data model is represented by, the current text says how you go from the representation
… back to the data model. I think this is the only place we do that, so I think that's the question.
… I understand it's a TTML2 profile, but at the same time the idea is it should be simple and people should
… be able to implement the data model not the whole of TTML2 so I wouldn't be against more restrictions
… to avoid allowing things that cannot be mapped back to the data model.
Nigel: Do you think the data model should be normative?
Cyril: I thought it was?
Nigel: We generally avoid normative language in the data model, and put it mostly in the representation.
Cyril: I recognise we are doing two things at the same time, and its a recipe for mismatch.
… We should strive to make them match but I agree with Andreas's point we should recommend adhering to the
… model but strictly speaking be prepared a document that goes beyond the data model because the TTML2
… syntax permits it.
Andreas: I agree with Cyril, at least with the option, to just allow in the syntax what is in the data model.
… I'm not sure how much work it would be to make this, because maybe several parts of the spec are affected.
… It makes the implementation easier.
… This is something people complain about with TTML, with some of the existing profiles.
… That would be the strongest solution maybe.
… Another would be a weaker recommendation to use it like the data model says.
Nigel: Couple of points.
… First I think we should explicitly state that the diagram is informative, in case there's an unintended
… clash between the diagram and the text.
… Second, I am wary of making implementations more complex rather than less complex by introducing more
… conditions on what is permitted on specific elements. For example, it's easy to implement generic
… xml:lang inheritance when it can be set on every element in the tree, but if you restrict to only certain
… element types then that adds implementation complexity.
… I think we need to tread the line carefully.
… There definitely are cases where we would want specific restrictions.
… Options I've heard so far (maybe not mutually exclusive):
… 1. Add additional restrictions via extension features
… 2. Make data model diagram informative
… 3. Recommend only making TTML2 documents that match the data model
… any others?
Cyril: I think we should do some sort of analysis of the possible differences.
… An alternative would be to say not that we put restrictions in the syntax, but indicate processing
… behaviours when encountering syntax that does not adhere to the data model, but that is TTML acceptable,
… maybe recommend that processors may or should ignore it, to allow a simplified implementation.
… One example: today we say a script is made of a list of script events where each is a div with a specific syntax.
… What if you encounter an extra div that is used for some other purpose and does not match the requirements of a Script Event?
… I think processor-recommended behaviour might be a good option.
Andreas: That's what I think Nigel meant by making things more complex.
… For example different processor behaviour for DAPT processors than generic TTML processors may be a problem.
… With xml:lang, if you ignore it on body or div then it may not work, and that would add complexity.
Cyril: I understand that, I think we all agree we don't want that behaviour.
… Maybe there are cases where this could be applicable.
Nigel: My other suggestion is to clarify that the TTML2 feature support required by the specification defines
… the processor behaviour, even if there's a difference from the data model.
… In the example that Cyril gave before of a non-Script Event div, if an implementation doesn't know what to do
… with it I think I'm not that unhappy with it being an implementation behaviour, for example in an authoring tool.
Andreas: I think a clear guideline is needed for implementers.
… I agree with Cyril's proposal to do some analysis.
… If we say that TTML2 governs if there are differences it could lead to a sense of lack of clarity or uncertainty,
… and make people look more deeply into TTML2 to get these cases.
Cyril: I wonder if we should add to the "is represented by" some statement about processing behaviour
… if other elements or attributes are encountered then the extensibility clause applies, or whatever.
… I wonder if a way to be exhaustive would be to do that systematically for every section, to make sure we don't
… miss anything.
Nigel: I think it's best to do this before CR, but I think doing this puts the 2 week suggestion under threat!
Cyril: I get that - this one is a true CR must have I would say.
Pierre: When was the last draft published?
Nigel: 15th February
Cyril: We publish on every pull request merge
… I propose to open a new issue to try and address this, identifying potential gaps between syntax capabilities
… and the model.
… That's an action for me.
… Are we okay to merge the pull request?
Nigel: I've approved this, I think we're fine unless anyone objects.
Cyril: I can open the issue and merge the pull request with a note that further discussion will continue on the issue.
Nigel: Sounds good to me.
Cyril: On the xml:lang, would there be any objection to allowing Language on the Script Event?
Nigel: I think it's premature
Pierre: I've lived through that painfully in IMSC. Is it limited today?
Cyril: in XML syntax no, but in data model yes.
Pierre: My experience with IMSC: I'd treat the two completely separately.
… The xml:lang in XML has a specific set of rules for inheritance. I would not try to restrict that at all.
… Just follow the inheritance rules in the XML, where every element in the hierarchy has a computed value
… of xml:lang, and then when you map that back to the model you use the computed value.
… Trying to limit it in XML is super hard. Just let it be and use the computed value to infer the values in the model.
Nigel: I think you've pointed the way forward there.
Pierre: Let's say the data model says there's no Language on an element , you just ignore it on things where it's not in the data model.
Nigel: I think that's it - stuff can be in the syntax but only has significance on objects in the data model.
Pierre: I think that's the idea in TTML - applies to xml:space and everything else really.
Nigel: Thanks we're out of time on this but that's a good point to end this discussion.
DST changes
Pierre: my input is 7am Pacific and 10am Pacific are impossible for me, but 8am and 9am are fine.
Nigel: We're out of time today so will have to move this offline.
Cyril: Same for me as Pierre - 7am Pacific is a stretch but 8am or 9am works.
Nigel: I'll have to do the mapping to understand what that means in practice
… I think in previous years we have tracked America on this change because it's not so onerous in Europe.
Atsushi: I wondered which direction things would go here.
Nigel: You've got i18n too, which must have the same problem.
Atsushi: Usually i18n sticks to UK.
Nigel: You could end up with a clash I think.
Meeting close
Nigel: Thanks everyone, apologies that we've run over today. [adjourns meeting]