Definition of prohibited does not prohibit presence of feature.

[skynavga]

Section 4 states:

shall not use any vocabulary, syntax or attribute values that would require the processor to implement any "prohibited" features to successfully process the document.

If the intention of this language is to prohibit the presence of a feature, e.g., use of a span element in the image profile, then this language does not accomplish that goal. In particular, it permits an interpretation that a prohibited feature may be used even though it does not require the processor to implement support.

In other words, the term prohibited as defined does not mean that a feature must not be used. It only means that the author of the document cannot use

<feature value='required'>...</feature>

for a prohibited feature.

[nigelmegitt]

We had a lot of debate about this wording - my only lingering concern with it was around the interpretation of the word 'successfully' which is there to make the link that you're asserting is absent. The reasoning is that if some vocabulary etc is present but ignored because it relates to a prohibited feature then it has not been successfully processed, just partially processed.

Can you suggest some better phrasing?

[skynavga]

Assuming the intent is to prohibit the presence of the feature as opposed
to prohibiting the presence of a declaration that support for the feature
is required (the current reading), then I would suggest paraphrasing the
following which is based on the new 'prohibited' feature value keyword
introduced in TTML2 [1]:

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

[1]
https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html#profile-vocabulary-feature

On Tue, Dec 8, 2015 at 4:07 AM, nigelmegitt notifications@github.com
wrote:

We had a lot of debate about this wording - my only lingering concern with
it was around the interpretation of the word 'successfully' which is there
to make the link that you're asserting is absent. The reasoning is that if
some vocabulary etc is present but ignored because it relates to a
prohibited feature then it has not been successfully processed, just
partially processed.

Can you suggest some better phrasing?

—
Reply to this email directly or view it on GitHub
#114 (comment).

[nigelmegitt]

That's what we tried before, but we got to the present wording because we couldn't use "feature" in that way, due to TTML1 features being processor features only: it makes no sense for a processor feature to be in a document.

[skynavga]

On Tue, Dec 8, 2015 at 8:37 AM, nigelmegitt notifications@github.com
wrote:

That's what we tried before, but we got to the present wording because we
couldn't use "feature" in that way, due to TTML1 features being processor
features only: it makes no sense for a processor feature to be in a
document.

But the IMSC specification clearly uses "feature" to refer to document
conformance, so that is a false argument. The use of prohibited/prohibition
in IMSC is clearly intended to go beyond what is meant by TTML1 profile
terminology. In any case, the current language doesn't prevent the presence
of a feature, it only prevents the presence of the following declaration.

prohibited feature

Which means that the following applies:

prohibited feature

Which means the feature may or may not be present in the document, and thus
its presence isn't prohibited.

—
Reply to this email directly or view it on GitHub
#114 (comment).

[nigelmegitt]

The ttp:profile element is prohibited so no declaration is permitted. The term 'feature' is as defined in TTML1, so unless we redefine it in IMSC (which would be confusing) then I'm not happy to use it in a radically different sense, even though I agree the intent is to try to describe document conformance.

[skynavga]

The issue here is defining 'prohibited', not defining 'feature'. The
current language does not have the intended effect. I'll leave it up to you
an PAL to find a better solution, upon which I will comment as needed.

On Tue, Dec 8, 2015 at 9:06 AM, nigelmegitt notifications@github.com
wrote:

The ttp:profile element is prohibited so no declaration is permitted. The
term 'feature' is as defined in TTML1, so unless we redefine it in IMSC
(which would be confusing) then I'm not happy to use it in a radically
different sense, even though I agree the intent is to try to describe
document conformance.

—
Reply to this email directly or view it on GitHub
#114 (comment).

[skynavga]

Note also that in the tables that list feature dispositions in IMSC that
the term 'disposition' is used, which is not equated with the TTML1 values
of the 'value' attribute of the 'feature' element. Rather, the Conformance
Section (4) directly defines the disposition value semantics without
reference to TTML1.

On Tue, Dec 8, 2015 at 10:56 AM, Glenn Adams glenn@skynav.com wrote:

The issue here is defining 'prohibited', not defining 'feature'. The
current language does not have the intended effect. I'll leave it up to you
an PAL to find a better solution, upon which I will comment as needed.

On Tue, Dec 8, 2015 at 9:06 AM, nigelmegitt notifications@github.com
wrote:

The ttp:profile element is prohibited so no declaration is permitted.
The term 'feature' is as defined in TTML1, so unless we redefine it in IMSC
(which would be confusing) then I'm not happy to use it in a radically
different sense, even though I agree the intent is to try to describe
document conformance.

—
Reply to this email directly or view it on GitHub
#114 (comment).

[nigelmegitt]

The current solution is what @palemieux and I came up with, so we're back at the beginning.

The problem we see with TTML1 features is that they're all defined in terms of processor behaviour, so as long as we're using TTML1 features we need a different way to approach them. Since we're not able to use the TTML1 value attribute of the feature element in this way we came up with this alternative.

[skynavga]

On Wed, Dec 9, 2015 at 2:34 AM, nigelmegitt notifications@github.com
wrote:

The current solution is what @palemieux https://github.com/palemieux
and I came up with, so we're back at the beginning.

The problem we see with TTML1 features is that they're all defined in
terms of processor behaviour, so as long as we're using TTML1 features we
need a different way to approach them. Since we're not able to use the
TTML1 value attribute of the feature element in this way we came up with
this alternative.

Right. So there is no problem in defining prohibited properly. Do you not
recognize that the current language does not actually prohibit the presence
of the feature usage?

—
Reply to this email directly or view it on GitHub
#114 (comment).

[nigelmegitt]

Do you not recognize that the current language does not actually prohibit the presence of the feature usage?

No - at least I don't see any problem with the wording right now:

shall not use any vocabulary, syntax or attribute values that would require the processor to implement any "prohibited" features to successfully process the document.

seems to do the job to me. Your issue is:

In particular, it permits an interpretation that a prohibited feature may be used even though it does not require the processor to implement support.

So far I've failed to understand how this interpretation is possible since it appears to be the direct opposite of the text - though as always I'm happy to have it explained!

[skynavga]

On Wed, Dec 9, 2015 at 12:33 PM, nigelmegitt notifications@github.com
wrote:

Do you not recognize that the current language does not actually prohibit
the presence of the feature usage?

No - at least I don't see any problem with the wording right now:

shall not use any vocabulary, syntax or attribute values that would
require the processor to implement any "prohibited" features to
successfully process the document.

seems to do the job to me. Your issue is:

In particular, it permits an interpretation that a prohibited feature may
be used even though it does not require the processor to implement support.

So far I've failed to understand how this interpretation is possible since
it appears to be the direct opposite of the text - though as always I'm
happy to have it explained!

It is very simple: any vocabulary item (element or attribute) and any
attribute value item that is unknown can be ignored. The expression
"successfully process" includes "ignore". Perhaps this is where the
misunderstanding lies.

—
Reply to this email directly or view it on GitHub
#114 (comment).

[nigelmegitt]

Yes, that's probably the location of the misunderstanding: I don't think "ignore" is a form of "successful processing".

[nigelmegitt]

@skynavga Could you suggest an edit that makes it even clearer?

[skynavga]

On Wed, Dec 9, 2015 at 12:49 PM, nigelmegitt notifications@github.com
wrote:

Yes, that's probably the location of the misunderstanding: I don't think
"ignore" is a form of "successful processing".

That is precisely the problem. In my book, ignoring a vocabulary item or
an unknown attribute value is definitely included in successful processing.

The language used in Section 4 is very problematic and needs to be
rewritten, both of:

• may use any vocabulary, syntax or attribute values whose
  interpretation will be successfully processed by a processor that supports
  "permitted" features;
• shall not use any vocabulary, syntax or attribute values that would
  require the processor to implement any "prohibited" features to
  successfully process the document.

These should be rewritten to read as follows:

• may use any vocabulary, syntax or attribute value which presence is
  admitted by a feature defined by the applicable profile as having the
  disposition "permitted";
• shall not use any vocabulary, syntax or attribute value which presence
  is admitted by a feature defined by the applicable profile as having the
  disposition "prohibited".

Note: The term use means appears in a document instance.

—

Reply to this email directly or view it on GitHub
#114 (comment).

[nigelmegitt]

See also discussion in TTWG meeting 2015-12-10 minuted at http://www.w3.org/2015/12/10-tt-minutes.html#item02

[nigelmegitt]

I just looked up "admit" since I thought the proposed wording is hard to understand. OED defines it as

To allow for the possibility or presence of something.

which I interpret as "permit". Reading the proposal again with this definition it ends up looking tautological or not following the right conformance trail. We'd be saying "shall not use any vocab etc that would be permitted by a feature defined by a profile as prohibited", but that hasn't fixed the problem that none of the referenced features "admit" the presence of anything: they are all defined as a processor behaviour in relation to some vocabulary should that be present.

I'm happy with the clarification about the meaning of the term use.

My preference right now is to leave the existing wording as is, potentially add the clarification of "use" and define explicitly that "successfully process" does not include ignoring, e.g. adding a sentence such as:

A processor successfully processes a feature if it exhibits the defined behaviour for that feature without ignoring any associated vocabulary, syntax or attribute value.

Would that help?

[skynavga]

On Thu, Dec 10, 2015 at 9:47 AM, nigelmegitt notifications@github.com
wrote:

I just looked up "admit" since I thought the proposed wording is hard to
understand. OED defines it as

To allow for the possibility or presence of something.

which I interpret as "permit". Reading the proposal again with this
definition it ends up looking tautological or not following the right
conformance trail. We'd be saying "shall not use any vocab etc that would
be permitted by a feature defined by a profile as prohibited", but that
hasn't fixed the problem that none of the referenced features "admit" the
presence of anything: they are all defined as a processor behaviour in
relation to some vocabulary should that be present.

I'm happy with the clarification about the meaning of the term use.

My preference right now is to leave the existing wording as is,
potentially add the clarification of "use" and define explicitly that
"successfully process" does not include ignoring, e.g. adding a sentence
such as:

A processor successfully processes a feature if it exhibits the defined
behaviour for that feature without ignoring any associated vocabulary,
syntax or attribute value.

Would that help?

No. For two reasons:

(1) it is contrary to what one would interpret "successfully process" to
mean in the larger TTML context;
(2) it refers to processing;

It is undesirable and unnecessary to even refer to processing in this
context.

—
Reply to this email directly or view it on GitHub
#114 (comment).

[nigelmegitt]

(1) it is contrary to what one would interpret "successfully process" to
mean in the larger TTML context;

That's why the term is defined. There are plenty of examples of jargon that is defined in a local context in a specification in a way that is contrary to normal expectations.

Perhaps a different term would work? "completely process" for example?

It is undesirable and unnecessary to even refer to processing in this
context.

I disagree with this statement. The way that we carefully constructed the current tables and text (during which discussions in Sapporo @skynavga you were present) was designed to be useful both in defining processor requirements and in defining document conformance. It is both desirable and necessary to define both.

[skynavga]

On Tue, Dec 15, 2015 at 10:39 AM, nigelmegitt notifications@github.com
wrote:

(1) it is contrary to what one would interpret "successfully process" to
mean in the larger TTML context;

That's why the term is defined. There are plenty of examples of jargon
that is defined in a local context in a specification in a way that is
contrary to normal expectations.

Perhaps a different term would work? "completely process" for example?

No.

It is undesirable and unnecessary to even refer to processing in this
context.

I disagree with this statement. The way that we carefully constructed the
current tables and text (during which discussions in Sapporo @skynavga
https://github.com/skynavga you were present) was designed to be useful
both in defining processor requirements and in defining document
conformance. It is both desirable and necessary to define both.

Sure, but you are conflating the two, using processing to define content
conformance. The definitions of content conformance and processing
conformance must be independent.

—
Reply to this email directly or view it on GitHub
#114 (comment).

[skynavga]

On Tue, Dec 15, 2015 at 11:22 AM, Glenn Adams glenn@skynav.com wrote:

On Tue, Dec 15, 2015 at 10:39 AM, nigelmegitt notifications@github.com
wrote:

(1) it is contrary to what one would interpret "successfully process" to
mean in the larger TTML context;

That's why the term is defined. There are plenty of examples of jargon
that is defined in a local context in a specification in a way that is
contrary to normal expectations.

Perhaps a different term would work? "completely process" for example?

No.

It is undesirable and unnecessary to even refer to processing in this
context.

I disagree with this statement. The way that we carefully constructed the
current tables and text (during which discussions in Sapporo @skynavga
https://github.com/skynavga you were present) was designed to be
useful both in defining processor requirements and in defining
document conformance. It is both desirable and necessary to define both.

Sure, but you are conflating the two, using processing to define content
conformance. The definitions of content conformance and processing
conformance must be independent.

To elaborate further. The term disposition "prohibited" as used in IMSC
only applies to content conformance, it does not create a processing
conformance requirement, e.g., to verify that no prohibited feature is used
in content.

—

Reply to this email directly or view it on GitHub
#114 (comment).

[nigelmegitt]

Perhaps a different term would work? "completely process" for example?

No.

Your objection seemed to be about the natural reading of the term "successfully process" not the concept that we're trying to convey. What terminology would you use to express that concept?

[nigelmegitt]

I disagree with this statement. The way that we carefully constructed the
current tables and text (during which discussions in Sapporo @skynavga
https://github.com/skynavga you were present) was designed to be
useful both in defining processor requirements and in defining
document conformance. It is both desirable and necessary to define both.

Sure, but you are conflating the two, using processing to define content
conformance. The definitions of content conformance and processing
conformance must be independent.

We are using the tools available to us in TTML1SE and working around them as best we can. TTML2 offers better tools for this which I expect we will want to adopt in IMSC 2.

The definitions of content conformance and processing conformance can reasonably be coincident in practice even if in principle they must be independent.

To elaborate further. The term disposition "prohibited" as used in IMSC
only applies to content conformance, it does not create a processing
conformance requirement, e.g., to verify that no prohibited feature is used
in content.

Right, so would a resolution to this be to add a statement that validating processors shall consider as non-conformant (and may thus reject) documents for which complete and successful processing (for want of a better term) would require processor support of prohibited features?

[skynavga]

On Wed, Dec 16, 2015 at 4:29 AM, nigelmegitt notifications@github.com
wrote:

I disagree with this statement. The way that we carefully constructed the
current tables and text (during which discussions in Sapporo @skynavga
https://github.com/skynavga
https://github.com/skynavga you were present) was designed to be
useful both in defining processor requirements and in defining
document conformance. It is both desirable and necessary to define both.

Sure, but you are conflating the two, using processing to define content
conformance. The definitions of content conformance and processing
conformance must be independent.

We are using the tools available to us in TTML1SE and working around them
as best we can. TTML2 offers better tools for this which I expect we will
want to adopt in IMSC 2.

The definitions of content conformance and processing conformance can
reasonably be coincident in practice even if in principle they must be
independent.

To elaborate further. The term disposition "prohibited" as used in IMSC
only applies to content conformance, it does not create a processing
conformance requirement, e.g., to verify that no prohibited feature is used
in content.

Right, so would a resolution to this be to add a statement that validating
processors shall consider as non-conformant (and may thus reject) documents
for which complete and successful processing (for want of a better term)
would require processor support of prohibited features?

Our position is that the term 'prohibited' as a disposition only applies to
content conformance, and that its intention is to prohibit the use of a
feature in a document. It does not apply to processor conformance, e.g., it
does not require a processor to detect the presence of a prohibited
feature, and, if detected, then prescribe a particular behavior upon such
an event.

In this regard, the current definition of 'prohibited' in terms of
processor behavior is not only misleading but unsuccessful (since
"successfully process" includes the possibility of ignoring a prohibited
feature). Indeed, one of the most basic design features of the internet has
always been "be conservative in what you transmit, but liberal in what you
receive" and has almost always resulted in implementations that ignore
unknown or prohibited content. In the absence of language to the contrary,
decoder processing always includes "ignore or discard content".

The simple solution is to simply describe content conformance in terms of a
prohibition on content, as we have proposed (expanded here to also clarify
the definition of "permitted"):

• may use any vocabulary, syntax or attribute value which presence is
  admitted by a feature defined by the applicable profile as having the
  disposition "permitted";
• shall not use any vocabulary, syntax or attribute value which presence
  is admitted by a feature defined by the applicable profile as having the
  disposition "prohibited".

Note: The term use means appears in a document instance.

—

Reply to this email directly or view it on GitHub
#114 (comment).