w3c / ttml2

Timed Text Markup Language 2 (TTML2)
https://w3c.github.io/ttml2/
Other
41 stars 16 forks source link

Permit `ttm:role` attribute in `ttm:desc` elements #1247

Closed nigelmegitt closed 3 months ago

nigelmegitt commented 2 years ago

I've seen real world usage of the ttm:role attribute on ttm:desc elements, used to describe the purpose/type of description. Suggest in §14.2.2 adding Metadata Items alongside Content. It could also be useful on Data elements.

nigelmegitt commented 2 years ago

For example: https://w3c.github.io/adpt/#bbc-example-section includes:

      <p xml:id="ad61b" begin="62.24s" end="71.52s">
        <ttm:desc ttm:role="x-shotDescription">SHOT CHANGE: 62.36s Nick Cotton centre screen facing right.</ttm:desc>
css-meeting-bot commented 2 years ago

The Timed Text Working Group just discussed Permit ttm:role attribute in ttm:desc elements w3c/ttml2#1247, and agreed to the following:

The full IRC log of that discussion <nigel> Subtopic: Permit ttm:role attribute in ttm:desc elements w3c/ttml2#1247
<nigel> github: https://github.com/w3c/ttml2/issues/1247
<cyril> nigel: this is a related, but different issue about TTML role
<cyril> ... currently the TTML2 role attribute talks about "content element" (content module, audio, ...)
<cyril> ... it specifically does not apply to a ttm:desc element
<cyril> ... however, this is in use in real world applications
<nigel> q?
<nigel> ack ats
<Zakim> atsushi, you wanted to discuss not sure but registry is normatively referencable???
<cyril> ... so I'm proposing to allow role on the desc
<cyril> atai: I agree
<cyril> ... why do we have the restrictions that metadata cannot be put on some elements
<cyril> ... why not allow all TTM attributes?
<cyril> ... why just for role?
<cyril> nigel: there are only 2
<cyril> ... agent and role
<cyril> ... not sure an agent applies to metadata
<cyril> atai: I do not see a harm
<cyril> ... TTML2 is usually very liberal
<cyril> ... even if it does not make sense now
<cyril> ... for example, agent on a br element
<cyril> nigel: you're probably right
<cyril> ... it would make sense to be consistently liberal
<cyril> hew: there is no high cost to allowing it
<cyril> nigel: there would be an editorial action to double check the schema
<cyril> ... any objections?
<cyril> (silence)
<cyril> RESOLUTION: We update TTML2 to allow metadata attributes on metadata elements
nigelmegitt commented 5 months ago

I've been looking into the semantics of ttm:role specifically.

Currently, a ttm:role attribute on a <metadata> element defines role(s) applicable to the <metadata> element's parent element.

If we make this change, then the slightly unusual scenario occurs that the ttm:role attribute on a child of a <metadata> element would not be "inherited" by that metadata element's children. This is in contrast to ttm:role applied to content elements, where its values do seem to apply to descendant content elements, though this is slightly unclear. See #1271 also.

skynavga commented 5 months ago

I can't envision ttm:role applying to a descendant of a metadata element, at least with respect to the TTML defined metadata vocabulary. Though I suppose one could invent a scenario where it might apply to foreign metadata vocabulary. On the other hand, it was never the intention that ttm:role would semantically apply to metadata; rather, it would apply only to content data.

nigelmegitt commented 5 months ago

My view at the moment is that it would be feasible to allow ttm:role on descendants of metadata, especially since it seems to fulfil a need, hence being used in practice. However, merely permitting it without making any other change would be unwise, not least because the inheritance semantics would become confusing.

Noting that DAPT currently defines a different attribute to fulfil this need, i.e. daptm:descType, I now would argue that is a better solution than trying to make the semantic change of adding ttm:role to descendants of <metadata>.

With that in mind, I would propose closing this issue with no change.

css-meeting-bot commented 4 months ago

The Timed Text Working Group just discussed Permit ttm:role attribute in ttm:desc elements w3c/ttml2#1247, and agreed to the following:

The full IRC log of that discussion <nigel> Subtopic: Permit ttm:role attribute in ttm:desc elements w3c/ttml2#1247
<nigel> github: https://github.com/w3c/ttml2/issues/1247
<cpn> Nigel: I opened this to suggest we allow the ttm:role attribute in ttm:desc attributes. I've seen real world use of this
<cpn> ... We resolved in September 2022 to allow metadata attributes on metadata elements
<cpn> ... I noticed recently that ttm:role doesn't behave as I'd thought. Spec says it's a set of role values that apply to content elements, and it applies to that element and all its descendents.
<cpn> ... So there's no way to invert the application of the role, it's an additive approach rather than an inheritance model that you might have e.g., color or language where what you set locally overrides what's set above.
<cpn> ... Don't think the model is wrong, but it seems bizarre to have role applied to elements in the metadata space
<cpn> Cyril: Why would putting things on the metadata element on a div apply to the div
<cpn> Nigel: That's how it's defined
<cpn> ... (talks through the spec detail)
<cpn> ... "applies semantically to the div element and its descendants as a whole"
<atai> q+
<cpn> ... If we say, the child elements of metadata, e.g., ttm:desc, that doesn't permit a ttm:role attribute. If it should have one we'd have to work out the inheritance model
<cpn> ... There's discussion in the issue. I checked DAPT, it defines a different attribute for the same thing
<cpn> Cyril: So we should restrict the use of ttm:role?
<cpn> Nigel: I think it's fine, but for DAPT we should explain the model
<cpn> ... It's not obvious, which we discovered trying to implement it
<cpn> ... Suggest closing this TTML2 issue with no change.
<cpn> Cyril: What about issue1271?
<cpn> Nigel: It doesn't say what happens in this context. My expectation is they're additive, so in both cases you are specifying roles that apply semantically to the metadata and content elements
<cpn> Andreas: You'd need to define precedence if there are conflicting values
<cpn> Nigel: They're additive rather than conflicting
<cpn> ... It's clear ttm:role on the metadata child does apply to the div element and descendants. But not clear that ...
<cpn> ... Precedence would suggest it could be one or other, but here I think you can both
<cpn> Andreas: Could use exclusive values, just need to be clear how it's managed
<cpn> Nigel: Doesn't have to be mutually exclusive, it could be both values
<cpn> ... Should we allow role on ttm:desc? Options are to keep discussing and come back to it, or decide immediately
<cpn> Cyril: It seems so complex, I'd steer away from ttm:role
<cpn> Nigel: It's actually surprisingly simple, but I understand the reaction
<cpn> ... What to with this issue? I've proposed closing it without change
<cpn> ... Suggest we allow more time for consideration
<nigel> SUMMARY: Allow more time for consideration
css-meeting-bot commented 3 months ago

The Timed Text Working Group just discussed Permit ttm:role attribute in ttm:desc elements w3c/ttml2#1247, and agreed to the following:

The full IRC log of that discussion <nigel> Topic: Permit ttm:role attribute in ttm:desc elements w3c/ttml2#1247
<nigel> github: https://github.com/w3c/ttml2/issues/1247
<cpn> Nigel: We last discussed in May. As DAPT defines desc type, so I suggest closing this with no changes, so not at ttm:role on metadata descendents
<cpn> Cyrill: Agree
<nigel> SUMMARY: Close with no change
nigelmegitt commented 3 months ago

Closing with no change as discussed in TTWG meeting