[TTML2] How and Why Schema Association is Not New

It has been claimed [1] that we cannot consider adding schema association
(ttp:{schemas,schema}) because it represents a new feature, or, more
generally, new functionality.  This is not true.

Prior to merging PR #606 [2], the ``ttp:version`` attribute was used to
allow a document author to drive schema association by specifying the
version of the specification to associate with a document, which in turn
associated one or more schemas as defined by that specification version.
This was thoroughly analyzed and discussed [3].

The resolution [4][5] that drove the adoption of #606 [2] was agreed
because it provided an alternative way to accomplish this association,
namely:

   1. use heuristics based on profile use of required features in
   combination with adding information into the specification that associates
   each feature with a specification version number; and
   2. "defining new feature designators to drive selection of alternate
   algorithm behavior"

As of this date, we have implemented (1) [2], but have not implemented (2).
So, we can say here that

   - that author defined schema association was already present prior to [1]
   - that we already have process agreement to implement [5]
   - that we have only partially implemented [5]

At this juncture, there remain two action items to fully implement
resolution [4]:

   - define new feature designators (and features as needed) to implement
   point (2) above; this is addressed in part by PR #594 [6] (in its current
   form) by adding the #validation-schema, #validation-schema-rnc,
   #validation-schema-xsd feature designators and ttp:schemas and ttp:schema
   elements as well as the logic for using the [effective validation schemas]
   added in the new [validate document] procedure;
   - update the [construct effective validation schemas] procedure to take
   into account the highest version associated with a required feature as part
   of the determination of a default set of schemas;

otherwise, the <loc href="#terms-effective-validation-schemas">effective
> validation schemas</loc> is a default set of schemas selected by the
> <loc href="#terms-document-processing-context">document processing
> context</loc>


My conclusion from this review is that we have already adopted a resolution
that is predicated on the adoption of #594 [6], and that a claim that this
violates process doesn't make any sense.

I would also note that author driven schema association is already
implemented in TTV, about which see, e.g., [7][8][9], which is a code
driven association of profiles with schemas. [It is author driven because
TTV uses ttp:profile and ttp:version (still) to drive profile selection
which drives (TTV) model selection which drives default schema association.]

Furthermore, I would add that if a profile designer (whether the profile is
to be shared or is embedded in the document) wishes to make use of
extension vocabulary from a foreign namespace and have that usage
validated, then they need to associate the profile with the additional
schema(s) that define the extension vocabulary, and that, without the aid
of ttp:schema, they will have no standard way to do so.

G.

[1] https://github.com/w3c/ttml2/pull/594#issuecomment-364907199
[2] https://github.com/w3c/ttml2/pull/606
[3] https://github.com/w3c/ttml2/issues/435#issuecomment-348064332
[4] https://github.com/w3c/ttml2/issues/435#issuecomment-356474313
[5] https://github.com/w3c/ttml2/issues/435#issuecomment-356142844
[6] https://github.com/w3c/ttml2/pull/594
[7]
https://github.com/skynav/ttt/blob/240ebb8d27a1a4b80f73a833dcc8bcb18214af9b/ttt-ttv/src/main/java/com/skynav/ttv/model/ttml/TTML1.java#L136-L140
[8]
https://github.com/skynav/ttt/blob/240ebb8d27a1a4b80f73a833dcc8bcb18214af9b/ttt-ttv/src/main/java/com/skynav/ttv/model/ttml/TTML2.java#L101-L105
[9]
https://github.com/skynav/ttt/blob/240ebb8d27a1a4b80f73a833dcc8bcb18214af9b/ttt-ttv/src/main/java/com/skynav/ttv/model/imsc/IMSC1.java#L171-L177