Move processor conformance out of #validation

[palemieux]

The definition of a validating processor should be moved to Section 3.2, and the statement is a validating content processor removed.

[skynavga]

@palemieux section E.1.217 #validation does not define validating processor. Further, why should is a validating content processor be removed?

[palemieux]

What does prohibiting “is a valid content processor” mean when #validation is prohibited?

[skynavga]

@palemieux first, the prohibited value applies only to content profiles, and it means:

if the value of the value attribute is prohibited, then the feature must not appear in a document that claims conformance with that profile;

it has nothing to do with whether the feature is supported or not by a processor; therefore, in this case, specifying

<ttp:feature value='prohibited'>#validation</ttp:feature>

in a content profile means that the parameters ttp:validation and ttp:validationAction must not appear in a document;

for a processor that supports validation, this means that the default values of these parameters apply, i.e., that validation is optional, and that a validation error produces a warning, not an error condition;

if you want to prohibit validation (as opposed to prohibiting the use of these parameter attributes), then you will actually want to use the #validation feature and specify a parameter

<tt ttp:validation='prohibited' .../>

[nigelmegitt]

See #672 regarding documents prohibiting validation.

[skynavga]

@palemieux is there any action you wish taken on this issue? if not, then please close

[palemieux]

@skynavga Apologies for the delay. I have been busy with IMSC and TTML1. Will get back to this soon. Is it blocking anything?

[skynavga]

@palemieux no, not blocking, just processing open issues

[skynavga]

@palemieux ping

[palemieux]

@skynavga Stepping back: "Transformation Processor" and "Presentation Processor" are defined in 3.2. Where is "Validation Processor" defined?

[skynavga]

@palemieux It is not defined. Validation is an optional sub-processing step of a content processor, whether it is a transformation processor or a presentation processor. The semantics of validation as a sub-processing step is defined by Section 5.3. See also definition of term [validating content processor].

[css-meeting-bot]

The Working Group just discussed Move processor conformance out of #validation ttml2#689.

The full IRC log of that discussion

<nigel> Topic: Move processor conformance out of #validation ttml2#689
<nigel> github: https://github.com/w3c/ttml2/issues/689
<nigel> Glenn: This is for Pierre who has asked additional questions on this.
<nigel> .. [summarises comments on the thread] Pierre, do you still think there's a problem?
<nigel> Nigel: We can't hear from @palemieux right now, will have to come back to this one.

[css-meeting-bot]

The Working Group just discussed Move processor conformance out of #validation ttml2#689, and agreed to the following:

• SUMMARY: @skynavga to prepare a pull request as per the above discussion for further review.

The full IRC log of that discussion

<nigel> Topic: Move processor conformance out of #validation ttml2#689
<nigel> github: https://github.com/w3c/ttml2/issues/689
<nigel> Pierre: I think there is still a problem. We have a conformance section, §3, where conformance
<nigel> .. of various kinds of processors is defined, and suddenly in the validation feature there is
<nigel> .. a definition of a validating processor and I don't know why this is done but not in §3.
<nigel> Glenn: There is no such thing as a validation processor, though I did discover two non-normative
<nigel> .. uses of that in the Introduction, which I can remove. A validating processor is a sub-processing
<nigel> .. step of a content processor, either a transformation or a presentation processor. There
<nigel> .. is no such thing as a standalone validation processor. It's an optional bit that gets turned on.
<nigel> .. So there's no need to add a separate definition.
<nigel> Pierre: An implementation today can be either a transformation or a presentation processor.
<nigel> .. Why not define a validation processor and an implementation could be all three at once?
<nigel> Glenn: There's no need to.
<nigel> .. The only reason for doing so is for the purpose of making claims. Nobody is going to make
<nigel> .. a validating content processor that is only a validation processor in my opinion, and if
<nigel> .. they wanted to do so it would be a validating transformation processor with a yes/no outcome.
<nigel> .. There is no need to add a new class.
<nigel> Pierre: Then lets remove the words "is a validating content processor".
<nigel> Glenn: But that's the point of that section...
<nigel> Nigel: I'm struggling to see the problem here.
<nigel> Pierre: The `#validation` feature designators is unique amongst all the feature designators
<nigel> .. because it imposes more than the processing of vocabulary but also conformance to
<nigel> .. a particular validating content processor definition. My suggestion is that if there is really
<nigel> .. such a thing as a validating content processor then it should be defined in the section
<nigel> .. on conformance. Either way "is a validating content processor" should be removed, and
<nigel> .. if there is a validating content processor then it should be added to §3.
<nigel> Nigel: Okay point 1, why should we not remove bullet 1 from `#validation`, i.e. remove
<nigel> .. the words "is a validating content processor".
<nigel> Glenn: This is not the first feature designator that does not define a syntactic construct,
<nigel> .. e.g. lineBreak-uax14.
<nigel> .. The current specification of ttp:validation does not mandate support for a validating content processor,
<nigel> .. it defines semantics that apply to a validating content processor but does not require
<nigel> .. it to be one. I could just move support requirement to ttp:validation.
<nigel> Nigel: Isn't support for `#validation` something that implies that the supporting processor
<nigel> .. is a validating processor?
<nigel> Glenn: It would mean that logically there is no effect.
<nigel> .. The `#speech` designator uses the same language. We don't define a conformance
<nigel> .. section for a speech synthesis processor.
<nigel> Nigel: They aren't identical, you could use the same approach for speech to validation.
<nigel> Glenn: There are two things I could do:
<nigel> .. I could use more of the approach taken within `#speech`.
<pal> q+
<nigel> .. Or I could use the phrasing from speech to make it explicit that validation is an optional
<nigel> .. component of any content processor.
<nigel> ack pal
<nigel> Pierre: I still don't understand - the current definition says "if it is a validating content processor"
<nigel> .. I follow the link to the definition and it doesn't tell me anything.
<nigel> Glenn: That's a good point, which I was thinking about. The real intent is to implement the
<nigel> .. semantics of §5.3.1.
<nigel> Pierre: Why not just say that, instead of "is a validating content processor" just say
<nigel> .. "implements the semantics of §5.3 Validation"?
<nigel> Glenn: I could do that, I would prefer to do it in the definition of the validating content processor,
<nigel> .. because then I could do the same for the speech processor to make them congruent.
<nigel> Pierre: Then the definitions section starts to look like a conformance section, which is my
<nigel> .. point at the end of the day.
<nigel> Glenn: You could say that for everything. We are not going to create a conformance section
<nigel> .. for each of the defined features?
<nigel> Nigel: Would you accept a change to the definition Pierre?
<nigel> Pierre: No the feature should just refer to §5.3 directly.
<nigel> Glenn: [scribe paraphrases: this is about consistency across the spec]
<nigel> Nigel: The question is Pierre would you be able to accept the reference intermediated through the definitions section?
<nigel> Pierre: I would need to study it further.
<nigel> SUMMARY: @skynavga to prepare a pull request as per the above discussion for further review.

[andreastai]

Glenn: There is no such thing as a validation processor, though I did discover two non-normative .. uses of that in the Introduction, which I can remove. A validating processor is a sub-processing .. step of a content processor, either a transformation or a presentation processor.

I do not share this view. IRT is developing a service which sole purpose is to validate TTML. It is quite common to have QC processors that just check constraints of format definitions.

[skynavga]

@tairt I understand, and TTV is the same type of processor. However, from the TTML nomenclature we have employed, both the IRT and TTV processors would be validating transformation processors, where the output of the transformation is one bit expressing validity (or not). In this fashion, we can view validation processing as an optional component of our currently defined TTML Transformation or TTML Presentation Processors. Note also the analog in the #speech feature which is defined in terms of an optional speech processing component.