Repository navigation
Unable to normatively determine non-conformance when testing content constraints. #125
Description
At present, IMSC1 says the following (in Section 3) regarding non-conforming content:
"NOTE This specification does not specify presentation processor or transformation processor behavior when processing or transforming a non-conformant Document Instance."
At the same time, IMSC1 specifies many normative constraints on content. As a result of there being no defined behavior in the case of content non-conformance, it is effectively impossible to test these normative constraints in an interoperable manner. For example, one processor may simply ignore non-conforming content, in part or in whole, while another processor may attempt to detect non-conformance and issue a warning to the end user or abort processing.
Due to this situation, one must question to what extent the IMSC1 specification is complete and testable.
This uncertainty may be eliminated by adding the following normative language:
"If a presentation or transformation processor is also a validating content processor, then when processing a non-conforming Document Instance, the following semantics shall apply:
- if validation is disabled or is otherwise not performed, then subsequent processing behavior is not defined;
- otherwise, processing shall depend upon the value of the application parameter validationActionMode as follows:
- if 'abort', then processing shall be aborted;
- if 'warn', then the end-user should be warned, with an option to abort or ignore;
- if 'ignore', then should not abort or warn end-user;
The value of the validationActionMode application parameter may be determined by the document processing context, and, if not set, shall assume the value 'abort'.
If processing is not aborted in the case of a non-conforming Document Instance, then further processing behavior is not defined by this specification.
Note: A processor may choose to attempt to recover from a non-conforming Document Instance by discarding or ignoring content until normal processing can continue."
and, further, revising the above cited NOTE in Section 3 to read as follows:
"NOTE This specification does not specify presentation processor or transformation processor behavior when processing or transforming a non-conformant Document Instance when the processor is not a validating content processor."
The above proposal is conceptually based on new features in TTML2 intended to deal with content conformance semantics, e.g., see [1][2], but does so without resorting to use of any of the new TTML2 vocabulary.
[1] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html#profile-attribute-validation
[2] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html#profile-attribute-validationAction
As such, adding this in IMSC1 will improve our ability to verify the many normative statements in IMSC1 regarding content constraints, and do so in an interoperably testable manner. We can make available an additional set of test content that contains one or more tests for every content constraint specified in IMSC1.
Activity
andreastai commentedon Feb 1, 2016
Normative constraints are the core of technical specifications but to my knowledge not all of them normativly define *how * these constraints shall be tested. These specs are nevertheless testable.
I question the usefulness of defining a normative validation behaviour for a validating IMSC 1 processor. This would make processors that do not follow this strategy (e.g. a simple XML Schema based processor) either a "non conformant validating IMSC processor" or they may not be named "validating IMSC processors" at all.
skynavga commentedon Feb 1, 2016
I don't believe the proposal limits the type of validation strategy or
mandates what aspects of a document are validated. Consequently, a simple
schema based processor that does not test other semantic constraints would
qualify as a validating processor as well. We just need to make sure we
define "validating IMSC processor" in a sufficiently general fashion.
On Mon, Feb 1, 2016 at 12:41 AM, Andreas Tai notifications@github.com
wrote:
skynavga commentedon Feb 4, 2016
I believe Andreas' concern can be addressed by adding the following definition and note to section 3:
Validating Content Processor. An optional designation applied to a Processor that additionally verifies the validity of content prior to or during normal processing, where validity includes the verification of adherence to basic encoding rules, syntactic constraints, semantic constraints, and usage recommendations, or some part thereof.
Note: This specification does not define a normative model of the coverage of validation processing; that is, it does not specify either a minimum or maximum level of validation processing, though one may assume an implied minimum that is greater than the empty set. In particular, a validation process that consists solely of schema validation may be considered a viable validating content processor. Other validating content processors may provide more or less coverage than a schema only validator.
andreastai commentedon Feb 4, 2016
From what I understand in the proposal it is tested if the a validating processor folllow the rules of the parameter
validationActionMode. If a processor does not follow the defined behaviour it would not be a validation content processor. A schema processor for example will report some errors (warn), ignore other errors of the spec (e.g. because not testable with the XSD) and abort in some scenarios (e.g. if the XML document is not well formed). It single strategy can not be defined.In general I doubt that there is a requirement to define if a QC application should abort, warn, ignore an errors. I also think that this may lead to the undesired behaviour that content is not presented when the validation is aborted because it should apply to the followng processors:
So if the same processor validates a document, than aborts processing it is likely that it also aborts processing.
skynavga commentedon Feb 4, 2016
ah, I think I see a source of confusion deriving from an essential missing
phrase in the original proposal;
the text
otherwise, processing shall depend upon the value of the application
should be revised to:
otherwise, if non-conformance is detected, processing shall depend upon the
it is not the intent that the above parameter determine what aspects of
conformance are assessed for validity, but that the parameter determine the
action to take when an assessment occurs and that assessment indicates a
violation;
On Thu, Feb 4, 2016 at 7:54 AM, Andreas Tai notifications@github.com
wrote:
skynavga commentedon Feb 5, 2016
It sounds like more discussion is needed to reach a conclusion on this matter; consequently, I'm OK with deferring it to IMSC2 and have assigned that milestone.
andreastai commentedon Feb 5, 2016
Thanks!
skynavga commentedon Feb 5, 2016
Does that mean you would be satisfied with the proposal if it is modified
to reflect that missing info (and the other prior suggestions I made in
this thread)?
On Fri, Feb 5, 2016 at 12:34 AM, Andreas Tai notifications@github.com
wrote:
andreastai commentedon Feb 5, 2016
Sorry for the ambiguous comment.
No, it meant that I am glad that the discussion is deferred to IMSC2.
Updated profile signaling and resolution to match TTML2 semantics (#3, …