search

w3c / dapt

Dubbing and Audio description Profiles of TTML2
https://w3c.github.io/dapt/
Other
7 stars 3 forks source link

Remove Script Event Type, use Represents instead #241

Closed nigelmegitt closed 2 months ago

nigelmegitt commented 2 months ago

Closes #227 by removing Script Event Type, reusing Represents instead.

Preview | Diff

css-meeting-bot commented 2 months ago

The Timed Text Working Group just discussed Remove Script Event Type, use Represents instead w3c/dapt#241, and agreed to the following:

The full IRC log of that discussion <nigel> Subtopic: Remove Script Event Type, use Represents instead w3c/dapt#241
<nigel> github: https://github.com/w3c/dapt/pull/241
<nigel> Nigel: [shows pull request preview]
<nigel> .. Question about whether to formalise the relationship when a content descriptor is a subset of another one.
<nigel> Cyril: 2 comments, one editorial, one technical.
<nigel> .. 1. Editorial: there's no question on the intent, merging the fields is a good decision.
<nigel> .. Why did you choose to make it a Shared Property?
<nigel> .. It behaves very similarly to text language source and other attributes.
<nigel> .. 2. Technical: I think we need to better explain the inheritance model that goes with it.
<nigel> q+
<nigel> .. To me, I see Represents as similar to xml:lang or daptm:langSrc - you specify it somewhere and it
<nigel> .. applies to the whole tree, and if you specify it somewhere else it is possibly to narrow down the value
<nigel> .. for that part of the tree, a group of divs or one div.
<nigel> .. For example for a dubbing script a represents at the top level could say "dialog nonDialogSounds"
<nigel> .. and for specific events you would say this is a dialog or a nonDialogSound.
<nigel> .. We shouldn't be able to say something in represents at the top level and then contradict that at a lower level,
<nigel> .. e.g. by not having any nonDialogSounds in the body but claiming it at the root.
<nigel> ack nige
<nigel> Nigel: My thinking here is that there is no inheritance model
<nigel> .. You could make the inheritance model one where you replace an inherited value with one
<nigel> .. specified at a lower level, but additive inheritance would not work.
<nigel> .. Let's say I commission a transcript including dialog and nonDialog sounds, but the media
<nigel> .. has no nonDialogSounds, then it makes sense to have no Script Events that represent nonDialogSounds.
<nigel> [discussion of inheritance, inclusion and exclusion constraints]
<atai> q+
<nigel> Gary: Could the top level one be a default one?
<nigel> Nigel: Could make represents mandatory on Script Events
<nigel> Cyril: Can't have a single Script Event be visual and nonVisual at the same time.
<nigel> ack at
<nigel> Andreas: Why can't we apply the same inheritance rule as xml:lang, so that the lowest
<nigel> .. attribute in the tree defines what the event is, so it's not a restriction, it's just overriding what is above.
<nigel> .. It's a general rule, e.g. for namespaces, xml:lang and others.
<nigel> .. To make this restriction makes it complicated to validate.
<nigel> Nigel: It's a list, and it only applies to the element it is on.
<nigel> Cyril: In that case your idea to make it mandatory on Script Event is probably better.
<nigel> .. It would lead to some verbosity.
<nigel> Gary: An alternative is to have represents be a single item and have a documentRepresents with a list
<nigel> Cyril: Could do that
<nigel> Gary: Then you could do normal inheritance
<nigel> Cyril: It's like langSrc, where the document can have multiple source languages
<nigel> .. I realise that langSrc is just one value but I thought we discussed having multiple values
<nigel> Nigel: Need to close this due to time. Please add comments to the issue clarifying the requirements.
<nigel> Cyril: OK
<nigel> SUMMARY: Reviewers to consider the PR and if necessary comment regarding the requirements, in the issue.
cconcolato commented 2 months ago

If verbosity was not a concern, we should say:

  1. a Script Event shall have a non-empty daptm:represents attribute and maybe, that contains a single value
  2. a Script Event shall not use a value that is not listed directly or indirectly (because it is a subset of a value listed) on the document-level daptm:represents. In the meeting @nigelmegitt said that there could be values listed at the top level that are not listed in script events, e.g. after editing or to indicate that the document tried to represent that dimension but could not find any content.

We could live with that. Alternatively, we could also specify that either:

  1. if daptm:represents is not present on a Script Event, it inherits the first value of the daptm:represents attribute on the document. It would behave like the default language.
  2. or introduce a daptm:defaultRepresents that is used to avoid the use of "first value".

BTW, the property is mandatory on the DAPT script but it shall also be non-empty.

nigelmegitt commented 2 months ago

@cconcolato see also https://github.com/w3c/dapt/issues/227#issuecomment-2348776405

I'm happy to take the approach you're suggesting - it's one of the options I also considered:

  1. Make daptm:represents mandatory and non-empty and maybe single value on Script Events
  2. Define a sub-type hierarchy in the <content-descriptor> registry. I would prefer to constrain it to 2 levels to minimise implementation complexity, i.e. to prevent the need to generate a tree, which would happen if we permitted a value to be a sub-type of another value that is also a sub-type of a 3rd one, and so forth.

If verbosity is a concern, perhaps we could shorten the attribute name, e.g to repr which is an abbreviation for "represents" or "representation" used in Python and Rust.

cconcolato commented 2 months ago

If verbosity is a concern, perhaps we could shorten the attribute name, e.g to repr which is an abbreviation for "represents" or "representation" used in Python and Rust.

The verbosity concern is not really about the length of the attribute name, but more about the repetition of the attribute in the case the document represents contains a single value that matches all the values on all the script events. But that concern is probably outweighed by the clear identification of what div matches a script event.

nigelmegitt commented 2 months ago

This doesn't build properly because of https://github.com/speced/respec/issues/4806

nigelmegitt commented 2 months ago

@cconcolato I think all of your comments have now been resolved, please check.