Re: [TTML2] How and Why Schema Association is Not New

Thanks for the analysis Glenn.

I'm afraid you haven't convinced me, but I'm open to other views from the WG members.

Comments inline:



From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Tuesday, 13 February 2018 at 20:34
To: TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: [TTML2] How and Why Schema Association is Not New
Resent-From: <public-tt@w3.org<mailto:public-tt@w3.org>>
Resent-Date: Tuesday, 13 February 2018 at 20:39

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].

[3] was indeed discussed and the resolution to adopt it recorded on 10th January. It mentions only determining a default schema, and says nothing about using an author-defined schema.


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

I do not recall discussing how to provide an explicit association between a document instance and a schema and the minutes do not record such a discussion.


  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]

I don't follow how you have come to this conclusion: author defined profile association was present, but not explicit schema association. They're not equivalent.

  *   that we already have process agreement to implement [5]
  *   that we have only partially implemented [5]

I do not see anything about explicit schema association in [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 <lochref="#terms-effective-validation-schemas">effective validation schemas</loc> is a default set of schemas selected by the
<lochref="#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'd be open to this argument in principle but in practice I do not find it convincing. Perhaps in your mind Glenn there was an implied association present before, but I did not detect it previously and even though you're pointing at specific things I still cannot see it.

Given how tenuous I believe the implication of an explicit schema was in the most recent WD, I am also concerned that adding this now would require us to go through another wide review cycle, which I do not believe is warranted at this time, or acceptable to the WG that has previously stated a strong desire to get to CR about now.


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