-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Script Event Type, use Represents instead #241
Remove Script Event Type, use Represents instead #241
Conversation
The Timed Text Working Group just discussed
The full IRC log of that discussion<nigel> Subtopic: Remove Script Event Type, use Represents instead #241<nigel> github: https://github.com//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. |
If verbosity was not a concern, we should say:
We could live with that. Alternatively, we could also specify that either:
BTW, the property is mandatory on the DAPT script but it shall also be non-empty. |
@cconcolato see also #227 (comment) I'm happy to take the approach you're suggesting - it's one of the options I also considered:
If verbosity is a concern, perhaps we could shorten the attribute name, e.g to |
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 |
3681360
to
76cdc27
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My general comments are:
- technical: why is 'represents' optional on Script Events? If it remains optional, what should be its value when not specified? I would prefer making it mandatory.
- technical: I would like to mandate that if a represents value is used at a Script Event level, it (or its corresponding top-level value, if the value is a sublevel) must be present at the document level.
- editorial: it is not clear to me why we are making it a "shared property" like begin/end. Those are allowed on plenty of objects (Script Event, Mixing Instruction, Audio Recording). Represents is allowed on DAPT Script and Script Event. Language is allwoed on Script Event Description, Text (and also on Script Event because of inheritance). Text Language Source is allowed on DAPT Script, Script Event (by inheritance), Text. I think we should be consistent. My suggestion is maybe to remove the notion of "Shared properties", define a property in one place and allow it in other places by reference.
I added some other minor comments.
This doesn't build properly because of speced/respec#4806 |
@cconcolato I think all of your comments have now been resolved, please check. |
<p>Some of the properties in the DAPT data model are common within more than one object type, | ||
and carry the same semantic everywhere they occur. | ||
These <dfn>shared properties</dfn> are listed in this section. | ||
</p> | ||
<p>Some of the value sets in DAPT are reused across more than one property, | ||
and have the same constraints everywhere they occur. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Represents and Script Represents don't really have put the same constraints on content-descriptor ... Maybe we should remove the end of the sentence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no difference to the constraints on <content-descriptor>
, there's a difference in how many content descriptors are permitted in Script Represents vs Represents, but that difference isn't described in this section.
* Merge registry table entries for `eventType` and `<content-descriptor>` (removing the `eventType` registry) * Extract definition of Represents into the Shared Properties section * Remove Script Event Type * Make Represents an optional property of Script Event and move example that was in Script Event Type up into Script Event under the Represents bullet * Add _permitted_ `#represents-div` feature * Update class diagram to remove Script Event Type and add Represents to Script Event
Fix to be one or more, was zero or more.
Separate scriptRepresents from represents as applied to Script Events. Define usage constraints. Define the syntax of `<content-descriptor>` to allow for generic validity checking without needing to understand the contents of the values used. Update the feature extensions and examples. Update the introduction to mention represents. Update the examples. Update the profiles and dispositions. Define an inheritance model for `daptm:represents`. Make Represents required to have a non-empty and valid computed value, but don't require `daptm:represents` on every Script Event `<div>` element. Allow user-defined content-descriptor values beginning `x-`. State that ttm:desc SHOULD NOT be empty.
Move the term inside the angle brackets, which makes it harder to find in the index of terms, but fixes the Respec error.
* Fix broken reference to scriptRepresents * Explain presence of inherited `daptm:represents` on `<body>` element in example * Explain how scriptRepresents might include values not present in Script - Represents * Fix syntax references to NMToken and `<lwsp>` * Take suggestions for better term definitions for content-descriptor * Clarify that Represents is inheritable, within the Represents property aside.
d37708f
to
5a3704d
Compare
Closes #227 by removing Script Event Type, reusing Represents instead.
eventType
and<content-descriptor>
(removing theeventType
registry)#represents-div
featurePreview | Diff