Add module framework (#29).

[skynavga]

Closes #29.

[palemieux]

The Specified Style Set Processing procedure needs to be revised to allow Styling Attributes not listed in 10.2. See also https://www.w3.org/TR/ttml-imsc1.1/#style-resolution-procedure.

Also, can module define additional content elements?

[nigelmegitt]

Thanks for opening this @skynavga - it's really useful to have something concrete to use as the basis for discussion, and has already raised some useful points.

[skynavga]

@palemieux re: #30 (review), I added the necessary hooks to 10.4.4.2 (6) and 10.4.4.4, the latter effectively extending [styled element] to potentially include a styled element defined in a (supported) external module;

I am open to considering supporting the ability to define new content elements in an external module, which would require tweaking the definition of [content element]; indeed, one could argue that if we augment 10.4.4.4 (as described above), we should also allow augmenting [content element], for what would be an (external module defined) styled element that is not a content element;

[skynavga]

@palemieux continuing my previous response to your original comment (#30 (review)), we could mandate (in a "requirements for registration" section of the module registry) that only the TTWG can define new content elements in public modules

[nigelmegitt]

I'd like opinions of the terms "private" and "public" as used here with modules. There's a connotation there that somehow the private modules are not public visible, which may well not be the case. Perhaps use "registered" (in place of public) and "unregistered" (in place of private), to avoid giving a misleading impression?

[palemieux]

Support for modules should be moved to TTML2 since it is used today, e.g. by IMSC, and does not introduce conformance changes for existing implementations,

[palemieux]

continuing my previous response to your original comment (#30 (review)), we could mandate (in a "requirements for registration" section of the module registry)
that only the TTWG can define new content elements in public modules

@skynavga I am not sure this is necessary since foreign elements (from modules) will be pruned by implementations unaware of the module.

[skynavga]

@palemieux #30 (comment) we use content elements in a number of critical points in TTML algorithms, so allowing a module to add a content element would be potentially dangerous if we allow other parties to do so; if we want to allow a content element defined in a module, then the TTWG needs to be in 100% control of that process

For re-review.

[skynavga]

@palemieux @nigelmegitt removed [{public,private} module] definitions

[palemieux]

@skynavga Thanks. Is there a diff available, or not yet?

[nigelmegitt]

@palemieux we haven't got diffs set up for this repo as yet - this is on @plehegar 's list.

[skynavga]

@palemieux no, unfortunately, the automatic preview/diff mechanism used for respec based specs does not work for xml based specs (or html for that matter); best to use the Files Changed link above

[skynavga]

Per conclusion from https://lists.w3.org/Archives/Public/public-tt/2019Apr/0007.html.