Clarify language application and inheritance model

[nigelmegitt]

          > Oh I see. Formally, Script Events do have a computed language regardless of whether they have an xml:lang attribute, and that might be inherited from the document level.

My view here is that we should go with the text in this pull request and if anyone asks about this subtlety we can consider amending or adding extra explanation.

Thanks, @nigelmegitt I think we should be clear about how language information is applied and inherited. From the class model (at least from what I can see) there is no other way to inherit the language information other than from the document level.

Originally posted by @andreastai in #181 (comment)

[nigelmegitt]

Just reviewed this issue to see if I could work out what change might be needed. @andreastai am I right in thinking that you're suggesting an informative section specifically about how language is specified in a document instance, or do you think normative text is needed now?

[cconcolato]

Reading the latest text, I wonder if the issue is still relevant. I find that the language property and inheritance are clear now.

[nigelmegitt]

@andreastai would you be able to re-visit this and see if you agree with #192 (comment) also?

[andreastai]

In the latest editor draft it says:

In the absence of an xml:lang attribute the language of the Script Event Description is inherited from the parent Script Event object.

Correct me if I am wrong: Because language can not be specified on a script event object (or in TTML Syntax on the div element), In the absence of an xml:lang attribute the language of an Script Event Description is always the value of the default language that is specified on the <tt> element. So from a practical perspective, it is more helpful that this relationship is highlighted.

Or is xml:lang allowed on a div?

[nigelmegitt]

I think we may need to clarify or explain better what the implications of the specification are in terms of what is normatively permitted in a DAPT document, compared with what the data model suggests is permitted.

In my view it is permitted to put xml:lang on a <div>, because we have not excluded it using an extension feature. And doing so would not be helpful.

Even if it is currently the case that the Script Event always inherits its language from some other parent, it is not wrong to say that it is the immediate source of inheritance for the Script Event Description. Wording it this way allows us flexibility in case we ever think of a use case for setting language directly on a Script Event, and adding this to the data model.

[andreastai]

@nigelmegitt

I think we may need to clarify or explain better what the implications of the specification are in terms of what is normatively permitted in a DAPT document, compared with what the data model suggests is permitted.

+1

In my view it is permitted to put xml:lang on a

, because we have not excluded it using an extension feature. And doing so would not be helpful.

OK. It may need to be discussed how to make this transparent....

Even if it is currently the case that the Script Event always inherits its language from some other parent, it is not wrong to say that it is the immediate source of inheritance for the Script Event Description. Wording it this way allows us flexibility in case we ever think of a use case for setting language directly on a Script Event, and adding this to the data model.

Formally this is correct. But from a practical view it would help to mention that you have to look out for the default language on the root element.

[css-meeting-bot]

The Timed Text Working Group just discussed Clarify language application and inheritance model w3c/dapt#192, and agreed to the following:

• SUMMARY: Add Language to Script Event as an optional property

The full IRC log of that discussion

<nigel> Topic: Clarify language application and inheritance model #192
<nigel> github: https://github.com//issues/192
<atai> q+
<nigel> Andreas: We discussed this last time and I think the conclusion was that we should add
<nigel> .. lang to Script Event.
<nigel> Nigel: That's easy, we can do that.
<nigel> .. Thank you for the reminder!
<nigel> SUMMARY: Add Language to Script Event as an optional property
<nigel> Andreas: My recollection is we think that makes sense, Cyril suggested it, nobody objected.
<nigel> .. My only question is what happens if xml:lang is on the <body> element?
<nigel> Nigel: We discussed in relation to #214 about computing values and then applying them where appropriate.
<nigel> Pierre: It's a two step process - first compute the value of xml:lang on every element, then when you map
<nigel> .. those elements to your model, you get the values of xml:lang on the objects where you care about it.
<nigel> .. Would you like me to add a note to the ticket?
<nigel> Nigel: Yes please, on 214.
<nigel> Pierre: OK
<nigel> Nigel: Thank you, that would be really helpful.
<nigel> Pierre: It works in both directions. If you map the model to XML you can just specify it on elements where it applies,
<nigel> .. because that will always override the inheritance.
<nigel> .. You can make another pass and simplify the serialisation using inheritance, but that's optional.
<nigel> Nigel: [nods]
<nigel> Pierre: I suffered through that on TTML validation parsing. There's no way to finesse it. There are always corner cases.
<nigel> .. One fun one in TTML - you have to do xml:lang inheritance before ISD processing, because you end up
<nigel> .. moving body under region as part of the ISD generation algorithm so if you haven't computed it already
<nigel> .. then you might end up with the wrong value.
<nigel> Nigel: That's a really good point.
<nigel> .. There's no need for regions in DAPT normally, but it's a gotcha that someone might use them for some reason
<nigel> .. and might put an xml:lang on them, who knows why, and then it needs to work how you just described it Pierre.