Add module framework (#1066).

[skynavga]

Closes #1066.

[nigelmegitt]

This pull request introduces both a constraint on where elements can be defined within W3C namespaces and the concept of, and requirement to use, a module registry. It's not clear to me that we have consensus for either of those introduced concepts at this time.

I would argue that the constraint on defining vocabulary within a W3C namespace exists independently of the introduction of modules and does not need to be repeated or duplicated.

I would argue that the fact that a module is registered or not registered in some external document is orthogonal to the specification and we don't need to introduce the text about it. All that matters is that, somehow, the module is considered in scope when the document is being processed. The obvious way to bring external modules into scope is by specifying within a profile document the features that depend on the module.

@skynavga how would you feel about simplifying this pull request to remove the namespace constraints and the registration/non-registration aspects, and to add that profile features may depend on externally defined modules?

[skynavga]

@nigelmegitt you do realize that these changes are exactly what we have already accepted and merged into TTML3, and that making a change here would create an inconsistency with TTML3? see w3c/ttml3#30 for confirmation.

[nigelmegitt]

@skynavga I seem to recall there was disquiet about those changes in TTML3 also. In my view it may be that the best approach is to fix it here and then port these changes as incremental changes onto TTML3 also, or it may be that we think TTML3 has a different set of constraints on modules than TTML2. Either way, my comments still stand.

[skynavga]

@nigelmegitt can we merge this PR and deal with your comments by way of another issue? since it proposes an additional follow-on substantive change that would affect both this spec and TTML3?

[palemieux]

The introduction of a

[cconcolato]

See comment #1066 (comment)

[skynavga]

I have attempted to address various comments in 2f67bbd, and, in particular, I have changed the adjectives internal/external to core/extension w.r.t. to characterizing modules and simplified language.

I have also removed the definition and references to a TTWG controlled Module Registry, which I still think is a good idea that will assist interoperability and implementation activity.

The net effect of removing the registry is that anyone may define an extension module that adds a content element or an attribute that it wishes to be treated as a style property regardless of whether it is in a TTWG controlled namespace or not.

I firmly believe this will lead to interoperability problems in the future, but we shall see.

[palemieux]

@skynavga I have approved the PR. Cyril and Nigel had much stronger opinions on this since they are writing "modules", so I encourage you to check with them.

[skynavga]

@cconcolato @nigelmegitt please check

[skynavga]

@palemieux please mark your conversation #1096 (review) as resolved, or ask me to do so

[skynavga]

Even though this PR impacts both document syntax and processing semantics, it is not interoperably testable as such, since whether or not a given implementation implements a feature defining module is dependent upon that implementation, and, if it does not implement it, then the default pruning rules will prune any elements or attributes added by a given module specification. Note, however, that element and/or attribute syntax associated with a given module specification could be tested for validity on an implementation that does support the module. Such tests would also need to specify a profile that requires support for any feature defined by the associated module that is being tested.

[nigelmegitt]

Thanks for the extensive work on this one @skynavga , I think we've ended up with a good result.

[cconcolato]

The PR has been improved quite a bit. Thank you. I'm still not convinced that the formal definition of modules was necessary, and the current definition of modules mixes everything from syntactical elements (attributes) to specifications, which is strange to me. Also, I'm not sure the 'clarification' about the difference between module and profile is needed. But in the interest of making progress, I'm approving this PR.

[skynavga]

@cconcolato I've tried to address your comment in 7c3ef1c:

the current definition of modules mixes everything from syntactical elements (attributes) to specifications, which is strange to me

there are no other outstanding, actionable comments at this time, so based on the current three approvals, I'm proceeding with merging