W3C home > Mailing lists > Public > public-tt@w3.org > February 2018

[TTML2] How and Why Schema Association is Not New

From: Glenn Adams <glenn@skynav.com>
Date: Tue, 13 Feb 2018 13:34:06 -0700
Message-ID: <CACQ=j+e+cqWizjwrOoozi+8ENun9g0EKii3Y89OevtQEex7QSA@mail.gmail.com>
To: TTWG <public-tt@w3.org>
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,

   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.


[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
Received on Tuesday, 13 February 2018 20:39:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 February 2018 20:39:52 UTC