Add hooks to TTML2 to simplify the creation of external modules.

[palemieux]

• extend style resolution to include style properties defined in external modules
• broaden the definition of TTML Content Document Type to include elements in external modules
• extend the definition of content element to include elements defined in external modules
• extend the definition of condition to include elements defined in external modules

See also w3c/ttml3#29

[skynavga]

Before we consider this, we need to determine if this change is (1) substantive (I believe it is) and (2) does not represent new functionality (I believe it it does), but, rather, represents a bug fix or necessary clarification. Unless this proposal satisfies both (1) and (2), then my position (at present) is that we should not entertain this proposal for TTML2.

[nigelmegitt]

My position on this right now is that adjusting the language to allow for the points in this issue is editorial, whereas actually extending the set of style properties, content elements etc would be substantive.

Noting that:

• the profiles defined in TTML2 would not include such extensions;
• foreign vocabulary is already permitted without causing a validation error;
• the semantic and processing behaviour for foreign vocabulary is undefined

my conclusion is there's no substantive change overall to TTML2. There could however be a substantive change to the conformance of processors that support extended vocabulary, should any of those extensions' status change from being included or excluded from the sets of style properties, content elements etc as defined in this issue.

That's a hypothetical concern, which I don't believe has any practical impact, because to do so would require a change in the specifications that define the extensions. For example IMSC already defines coincident rules in Style Resolution, and that language would need to be modified to make use of any new constructs in TTML2. In the meantime IMSC refers explicitly to TTML2 from Nov 2018.

[palemieux]

My position on this right now is that adjusting the language to allow for the points in this issue is editorial,

+1

[skynavga]

I'm going to create a PR that pulls in changes from w3c/ttml3#30. However, I am going to mark both the PR and this issue as a substantive change, since we marked it as substantive at w3c/ttml3#29 and w3c/ttml3#30.

[skynavga]

I should add, however, that marking it as substantive does not mean this introduces new functionality as such; that is, adding the framework does not itself create new features (that might be created by a newly defined external module, for example).

[cconcolato]

I'm not convinced that we need to extend the notion of 'modules'.

TTML uses already too many terms that confuse people. 'Module' may be in the spec today but it does not mean that it needs be extended as proposed in the PR with the notions of 'internal/external modules', or with a 'registry', or with a definition that mixes many different things together: 'element types' and 'specifications'. Also, changes like saying that a "profile" is a collection of "feature specifications" instead of "features" are not helping.

In my view, new specifications should not be called 'external modules'. They should be 'extension specifications' (if a collective name is needed) or simply not named specifically. These specifications could define elements, attributes or values but their purpose is to actually define one or more 'feature' designators (otherwise they cannot be used). That should be sufficient. For example, IMSC 1.x could say it supports TTML2 and the features defined in spec Y, without having to refer to a module.

If a spec Y has to extend an existing TTML module for the purpose of saying that an existing procedure to the new element A, it should be able to do so. Instead of having to white-list all specs that can extend an existing module, we should rather focus on making sure the spec does not forbid an external specification to do so.

[skynavga]

I need to better explain why we need to have different terms for what I called internal vs external modules in TTML3. At present, TTML2 defines three normative abstract document types in sections §4.1, §4.2, and §4.3, which play a central (and crucial) role in steps (2) and (3) of the Document Conformance criteria (§3.1). Focusing on §4.1 specifically, the TTML Content Document Type, the definition of this document type normatively references §5, Vocabulary, and requires that the root tt element must adhere to §8.1.1, from which all remaining vocabulary definitions follow (by reference).

So we have an existing, crucial reference in this one point in §4.1 (also in §4.2 and §4.3) to §5, of which §5.4 Catalog and §5.4.1 Core Catalog enumerates a fixed vocabulary each member of which is associated with a unique Module name.

Now, in TTML3, we changed the language in §4.[123] to refer to a collection of functional modules instead of referring directly to §5 Vocabulary, and, importantly, we defined module to refer to either an internal module or an external module, where internal module refers explicitly to the Core Catalog in §5.4.1. The reason I wrote it this way was because I needed to (1) retain the existing chain of normative references that previously existed in §4.[123] to the finite (and fixed) collection of vocabulary defined in §5, and, at the same time (2) introduce an open set (not fixed) of vocabulary defined elsewhere (meaning outside the TTML[23...] specification text).

It was a completely natural descriptive device that I employed (internal vs external) as a way to characterize and distinguish (1) the core, fixed set of vocabulary defined in TTML[23..], and (2) an open set of new vocabulary defined outside of TTML[23...].

Writing it in this manner DOES NOT introduce "heavy machinery" or present any kind of cognitive burden for the reader. However, perhaps it is my choice of the terms internal and external that are causing concern. In this regard, I suggest we change these adjectives to "core" instead of "internal" and "extension" instead of "external". The term "core" is completely consistent with the way this vocabulary is characterized in §5. Furthermore, the term "extension" could be seen to be consistent with §5.4.2, although we may want to tweak the first paragraph of §5.4.2.

The result is that we would have core modules, which are those defined by the core catalog (§5.4.1), and extension modules, which are those defined by the (open ended) extension catalog (§5.4.2), where the term module merely means a (defining) specification of some collection of vocabulary.

We could then refer to new specifications that define additional (non-core) vocabulary as Extension Modules, e.g., Timed Text Karaoke Extension Module or TTML Karaoke Extension Module.

This would allow us to effectively organize and refer to the (closed set of) vocabulary defined by the existing core modules and also refer to the new (open set of) vocabulary which will be defined in extension modules. This also allows the specification to retain the normative thread of references from the existing abstract document type definitions in §4 to §5.4.1 and also new definitions that derive from §5.4.2 in the form of new extension module specifications.

We can't very well tell people that we are modularizing TTML without making use of the term module can we? To avoid the term seems quite absurd to me, as we have wide precedent for its use both in the TTWG and in other WGs.

[nigelmegitt]

The terms "core" and "extension" seem like an improvement over "internal" and "external" to me.

[skynavga]

Marking this issue as an enhancement since the omission of support for modularization was not an oversight.