Collaborative editing or partial editing - do we need "unfinished" state?

[nigelmegitt]

We need think about either collaborative editing or partial editing and whether we need "unfinished" state. Worth an issue.

_Originally posted by @cconcolato in https://github.com/w3c/dapt/pull/49#discussion_r973503810_

[nigelmegitt]

Possibly an issue for a future discussion; not marking as Agenda today because there's not been enough discussion on this issue to warrant it.

[nigelmegitt]

Discussed 2023-02-09 with @cconcolato : Agreed to highlight this question somewhere in the specification so that when we go to FPWD we can ask for feedback from the wider world on how important it is to support partial editing.

[cconcolato]

Should we add a daptm:stage = draft | final?

[nigelmegitt]

Maybe daptm:status = draft | final but yes, that'd be okay by me. Orthogonal to the script type, i.e. it's reasonable to have a draft or a final version of each script type.

[mattsimpson3]

Hi - further to conversations with Nigel, we would suggest a means of tracking changes once something has been edited - so that a delta can readily be produced for reversioning (i.e. a list of points in a script or programme to review and chnage). Frequently the international release of content is tweaked (for music rights, unsuitable language etc) and it would be good to know which sections of the script have been modified. I don't think this needs to be word by word within the DAPT doc, but rather a means of flagging change on sections. Perhaps last modified date / time stamp, as that would allow iteration...?

[nigelmegitt]

See also #140.

[css-meeting-bot]

The Timed Text Working Group just discussed Collaborative editing or partial editing - do we need "unfinished" state? w3c/dapt#52, and agreed to the following:

• SUMMARY: Continue discussing offline

The full IRC log of that discussion

<nigel> Subtopic: Collaborative editing or partial editing - do we need "unfinished" state? w3c/dapt#52
<nigel> github: https://github.com/w3c/dapt/issues/52
<nigel> Cyril: This issue is about possibly tracking state changes into a document.
<nigel> .. Thank you Matt for commenting on it.
<nigel> .. I'm asking myself and my colleagues if there is a need for interoperability in tracking changes
<nigel> .. while editing?
<nigel> .. I'm not sure for example if we would go between authoring tools where interop is needed to signal unfinished editing.
<nigel> .. The other thing is: possibly it could be done externally to the document, in a version control system
<nigel> .. or asset management system.
<nigel> .. At Netflix the need we identified is to see what delivery it refers to.
<nigel> .. For example if a script is received, the original media changes and you need to get another one.
<nigel> .. It's about tracking multiple finished documents pointing to different related media objects.
<nigel> .. We added some text about identifying related media objects recently.
<nigel> .. You could use that, as well as additional proprietary data in other namespaces.
<nigel> .. I'm looking for use cases where interop is needed between tools for fine-grained change tracking.
<nigel> MattS: Quite often we will be asked to reversion or modify a subtitle or caption file based on the results
<nigel> .. of compliance edits or a localisation process.
<nigel> .. It's very useful for the translators, captioners, subtitlers, to be driven to the changed elements rather
<nigel> .. than working out for themselves where the differences in the media are.
<nigel> .. It can be as simple as an edit to remove a section, or replacement of expletives, or some other editorial change.
<nigel> .. I agree, we could do it as an external diff process.
<nigel> .. From our point of view there is value in it travelling within the document.
<nigel> .. It does not need to be particularly complex.
<nigel> .. I can see arguments against keeping multiple versions in one file.
<nigel> .. But just indicating what had been edited most recently would be useful.
<nigel> .. We get around this now by exporting Edit Decision Lists and pointing humans to the changed timecodes.
<nigel> .. Does that help?
<atai> q+
<nigel> Cyril: Yes, it helps, it's very similar when you mention ETL. My colleagues are using OpentimelineIO to do the same thing.
<nigel> .. I still wonder how we identify the latest edits in the document.
<nigel> .. Have an iteration number on each script event, and increment all the touched events every time you edit?
<nigel> .. I would need to see a proposal. I'm not opposed.
<nigel> .. What Nigel suggested initially, to use ScriptType at event level, I don't think it covers your use case.
<nigel> MattS: No, for me it's almost like a "dirty" flag - what has not been seen before in this file.
<nigel> cyril: How would you track deletions then?
<nigel> MattS: True, that's equally valid.
<nigel> ack atai
<nigel> Andreas: Question to Matt - is this particular for DAPT, or for other TTML documents?
<nigel> MattS: It would count for other TTML documents, but workflow-wise if we were to use DAPT as an
<nigel> .. inbound script and we have multiple versions sent to us, it would be useful to know what is different,
<nigel> .. i.e. the intention of the edit.
<nigel> cyril: I agree with that. The current thinking is to carry top-level metadata in the form of a change log,
<nigel> .. but not with a fine-grained approach.
<nigel> MattS: If we want to save human time, we would want to direct the person to the changed part rather
<nigel> .. then having them hunt for it.
<nigel> .. A DAPT document could be the input to a process, where an IMSC document might be the output,
<nigel> .. from a lifecycle point of view.
<nigel> Cyril: My suggestion is to continue the conversation offline with examples. Do others share the same use case?
<nigel> .. Is this a v1 thing or can it be deferred for now? There are options.
<nigel> SUMMARY: Continue discussing offline

[cconcolato]

Resolving this issue is important to resolve #75. For example, if we don't allow partial documents, there is no reason to have a document with 0 events.

[cconcolato]

Current spec says: https://w3c.github.io/dapt/#script-events

A DAPT Script MAY contain zero or more Script Event objects

A final document SHALL have at least one script event, otherwise the document seems useless.

Similarly, https://w3c.github.io/dapt/#dfn-script-event says:

A Script Event object [...] has the following properties: Zero or more Text objects [...]

A Script Event without Text in a final document does not make sense.

[nigelmegitt]

The concept of "final" is getting my brain in a twist. What's "final", i.e. deliverable, from one stage, may be merely an input to the next stage.

For example, if I'm some kind of audio description process stage 1 preparer, then my only job might be to identify times when audio descriptions could be present. My "final" output would be a bunch of Script Events with timing properties but no Text objects in them.

Looking back at the discussion, I wonder if different concepts are needed:

1. A revision history metadata section
2. A review history section
3. A way to mark up specific objects with the revision number in which they were changed
4. A way to mark up specific objects with comments relating to a specific review

One suggestion for how to address the "final" comment is to allow for some external rule set to be defined, and then add a review that checks the document against that rule set.

For example, a rule set could be:

1. document has at least one Script Event
2. zero Script Events have no Text

Then a review can be added that validates the document against that rule set, and adds an entry into the review history.

This all feels a bit beyond the "minimum viable" v1 to me, but I could be persuaded if people really want/need this.

To make this more concrete, I'm thinking of something like:

<head><metadata>
  <daptm:revisionHistory>
    <daptm:revision revision="1" revDate="2024-03-27T1549">
      <daptm:revComment>Added Script Event times</daptm:revComment>
    </daptm:revision>
    <!-- more revisions here -->
  </daptm:revisionHistory>
  <daptm:reviewHistory>
    <daptm:review review="1" revision="1" ruleSet="urn:identifying:ruleset" revDate="2024-03-27T1550" reviewStatus="changes_needed">
      <daptm:revComment>Found a Script Event with unusual duration</daptm:revComment>
    </daptm:review>
    <!-- more reviews here -->
  </daptm:reviewHistory>
</metadata></head>
<body>
  <div xml:id="se1" revision="1" begin="0.1s" end="0.2s">
    <metadata>
       <daptm:reviewNote review="1">Short duration</daptm:reviewNote>
    </metadata>
  </div>
</body>

[mattsimpson3]

I think it's very hard to declare something to be final; only time indicates no further changes were made in my experience - otherwise it's just a version published on a give day. The revision approach suggested here, esp if applicable to the text itself, would be great for directing a revision / reversion process downstream (e.g. filter text by changes please), but I agree that to get this usable could take a bit of iteration and may make more sense once there are some 'real' files in existance.