Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Define DAPT-specific conformant implementation types #44

Closed
cconcolato opened this issue Sep 14, 2022 · 9 comments · Fixed by #245
Closed

Define DAPT-specific conformant implementation types #44

cconcolato opened this issue Sep 14, 2022 · 9 comments · Fixed by #245
Labels
CR must-have Must be resolved before going to CR

Comments

@cconcolato
Copy link
Contributor

We should define our own classes of conformant implementation types, to avoid using the generic "presentation processor" or "transformation processor" ones. We could link to them.
At the moment, I can think of the following classes:

  • DAPT Authoring Tool: tool that produces compliant DAPT documents or consumes DAPT compliant document. I don't think they map to TTML2 processors.
  • DAPT Audio Recorder/Renderer: tool that takes DAPT Audio Description scripts, e.g. with mixing instruction, and produces audio output, e.g. a WAVE file. I think it is a "presentation processor"
  • DAPT Validator: tool that verify that a DAPT document is compliant to the specification. I'm not sure what it maps to in TTML2 terminology.
@cconcolato cconcolato mentioned this issue Sep 14, 2022
Merged
@nigelmegitt
Copy link
Contributor

I think:

  • Authoring Tool = transformation processor
  • Renderer / mixer = presentation processor
  • Validator = validation processor

But we don't necessarily want to use TTML2 Transformation Processor at all.

@cconcolato cconcolato mentioned this issue Nov 30, 2022
Merged
nigelmegitt added a commit that referenced this issue Dec 1, 2022
@nigelmegitt
Add issue link to #44 so we don't forget
185e0f6
nigelmegitt added a commit that referenced this issue Dec 1, 2022
@nigelmegitt
Clarify character styling and other styling requirements (#76)
9548e18 
* Resolve #29

* Drive-by fix of a few linting/HTML syntax errors including removing two duplicate id attribute values.
* Define Character Style
* Specify that Character Styles are style elements with ttm:agent attributes matching the xml:id of the ttm:agent element for the Character
* Character Styles can be applied to Script Events and Text objects using the style attribute
* Presentation processors must not associate them with character styles via any other mechanism, e.g. matching the ttm:agent attributes only. Note and example also included.
* Permit other non-Character Style styling including inline
* Tweak text that permits <p> elements to contain mixed content
* Tweak note about the order of <p> elements mattering, for grammar.

* Tweaks from self-review

* "one or more optional" is better written "zero or more".
* The representation of Character Styles is not dependent on whether or not a Character has a Character Style.
* Clarify that style elements without a ttm:agent attribute are allowed, and are simply not Character Styles.

* Address review feedback

Remove duplicate "be".

* Add issue link to #44 so we don't forget
@nigelmegitt
Copy link
Contributor

Not sure if we still need to do this? Currently we are using "presentation processor" and "content processor", linking to their TTML2 definitions.

In terms of splitting out functionality to change the implementation target size, #118 adds a bunch of audio related features that were in the examples but, within the data model and main part of the specification, only subtly hinted at previously. If we want to split out support for those into a separate category of implementation/processor then now might be a good time to do it, or wait for wide review feedback and see if anyone asks us for it.

My preference would be to have fewer, larger implementation targets rather than more, smaller ones but I think it is important to be guided by industry feedback.

@cconcolato
Copy link
Contributor Author

I think this issue should be handled jointly with #75

@nigelmegitt nigelmegitt changed the title [ED issue] Define DAPT-specific conformant implementation types Define DAPT-specific conformant implementation types May 18, 2023
@nigelmegitt nigelmegitt added the CR must-have Must be resolved before going to CR label May 18, 2023
@nigelmegitt
Copy link
Contributor

I'm not sure if we need to create additional classes of implementation at all.

Looking at the specification now, what problem arises by not describing these implementation classes?

@nigelmegitt
Copy link
Contributor

This turned out to be a key question during today's TTWG call. A normative requirement for some kind of DAPT processor would mean that #216 needs to change to have normative provisions.

@nigelmegitt nigelmegitt mentioned this issue Apr 9, 2024
Merged
@cconcolato
Copy link
Contributor Author

Looking at the spec we have requirements for:

A transformation processor ...

A presentation processor ...

A presentation processor that supports audio ....

A presentation processor that supports extended descriptions ...

content processors ...

A validation processor ...

I'm not sure anymore that we need to derive TTML's categories of processors as suggested in initial comment. Maybe having an informative note about how all these processors relate in practice would avoid readers to go to the complex definitions in TTML2...

That said, given the comment #241 (comment) first bullet 2, and the restrictions proposed in #75 (comment), we essentially end up have sub-profiles of DAPT by identifying the supported values of represents. For example, a derived specification could say that only dialogue is supported and in that case, the processor would not have to support audio-related features.

@nigelmegitt
Copy link
Contributor

Can we close this with no action then?

@cconcolato
Copy link
Contributor Author

Can we add a paragraph or a note to section https://w3c.github.io/dapt/#conformance-of-dapt-processors that would say:

NOTE: The provisions in this specification are expressed in terms of TTML2 processor types, using terms like "content processors", "presentation processors", "validation processors", "transformation processor" ... They may be understood with the mapping below:

  • A DAPT tool that would display the content of a DAPT document, in any form: for example, just rendering the text, event by event; or rendering the text of all the events all at once along a timeline; or one doing the audio mixing, would be considered a Presentation Processor. A Presentation Processor can also support additional rendering features from TTML2, such as styles for DAPT documents that use that.
  • A DAPT authoring tool, producing DAPT documents from scratch or from an other document, would be considered a transformation processor. It may also be considered as a presentation processor if it does any form of rendering of the text or the audio.
  • A DAPT tool that would indicate if a DAPT document is compliant to this specification would correspond to a validation processor.

@nigelmegitt
Copy link
Contributor

Do you want to open a pull request for that, @cconcolato ?

@cconcolato cconcolato mentioned this issue Sep 26, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CR must-have Must be resolved before going to CR
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

add note to describe DAPT implementation types w3c/dapt
2 participants
@cconcolato @nigelmegitt