Need algorithm to determine profile in absence of ttp:profile property.

[skynavga]

An algorithm is necessary to be able to deterministically which profile applies to an IMSC conformant document in the absence of a ttp:profile attribute.

[palemieux]

What use case do you have in mind?

[skynavga]

All processing. If you don't know whether text or image profile applies,
then you don't know what constraints apply.

On Sun, Dec 6, 2015 at 12:06 AM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

What use case do you have in mind?

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

[skynavga]

Also, I would suggest a simple algorithm: if tts:profile is not specified, then the text profile applies.

[nigelmegitt]

This may be a silly question but if there's no ttp:profile attribute AND no ebuttm:conformsToStandard element, then how do you know you're dealing with an IMSC document at all? Is this in the case that a validator for example is configured to validate a provided document against IMSC [any profile]? If so, what would be the impact of requiring that the validator be configured to validate more specifically against either IMSC Text Profile or IMSC Image Profile?

[skynavga]

In the case of TTV, the user specifies a parameter that tells it to
validate against a certain "validation model". This is done either through
a command line option or a TTV specific "annotation attribute" on the root
element, e.g.,

<tt ... xmlns:ttva="http://skynav.com/ns/ttv/annotations" ttva:model=
"imsc1">

This tells TTV (a generic TTML processor) to behave as a generic IMSC
processor.

However, that is not sufficient information to perform validation. And,
more generally, it isn't sufficient to perform any processing, since the
conformance section states:

A [presentation processor
https://rawgit.com/w3c/imsc1/master/spec/ttml-ww-profiles.html#dfn-presentation-processor
| transformation processor
https://rawgit.com/w3c/imsc1/master/spec/ttml-ww-profiles.html#dfn-transformation-processor]
that conforms to a profile defined in this specification: shall implement
[presentation | transformation] semantic support for all features
designated as "permitted" by the profile, subject to any additional
constraints on features as specified by the profile

which effectively requires answering the question "which profile applies?"
before it can perform processing.

Without a well defined algorithm to answer this question, then we end up
with:

• a generic IMSC processor must guess the profile (absent external
  information); or
• all IMSC processors must be non-generic, i.e., assume either text or
  image profile

This would be a very bad design indeed.

My proposal for an algorithm is quite simple:

"If no ttp:profile attribute is present, then the text profile applies."

This nicely handles the case of an EBU-TT targeted document (that may use
ebuttm:conformsToStandard or not), which implies the text profile.

On Mon, Dec 7, 2015 at 1:43 AM, nigelmegitt notifications@github.com
wrote:

This may be a silly question but if there's no ttp:profile attribute AND
no ebuttm:conformsToStandard element, then how do you know you're dealing
with an IMSC document at all? Is this in the case that a validator for
example is configured to validate a provided document against IMSC [any
profile]? If so, what would be the impact of requiring that the validator
be configured to validate more specifically against either IMSC Text
Profile or IMSC Image Profile?

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

[nigelmegitt]

I see what you mean, however I think there remains another interpretation: that it is reasonable to have a [ presentation | transformation ] processor that conforms to just one of the profiles, which is my interpretation of the phrase "conforms to a profile". In other words, there's no real concept of a generic IMSC 'any profile' processor, and there's no wording that defines the conformance of a processor that can handle any document in either profile.

It's clear that there are 2 separate profiles in IMSC.

Having said that, if you really want to derive the profile as the first step in generic IMSC processing, then I support the algorithm you've described.

[skynavga]

As I said, absent the algorithm, one cannot create a generic IMSC processor
without resorting to heuristics. This was also a point raised by Cyril when
discussing how to derive an external (wrapper) profile parameter.

IMO, defining such an algorithm is not an option.

As for the concept of a generic IMSC processor, although not explicitly
mentioned, it is implied in the sense that:

A [ presentation processor
https://rawgit.com/w3c/imsc1/master/spec/ttml-ww-profiles.html#dfn-presentation-processor
| transformation processor
https://rawgit.com/w3c/imsc1/master/spec/ttml-ww-profiles.html#dfn-transformation-processor]
that
conforms to a profile defined in this specification

does not restrict a processor to conforming to only one of the defined
profiles.

It is useful to note as well that nowhere in the IMSC specification is it
required that an IMSC processor (of any type) conform to any IMSC profile.

On Mon, Dec 7, 2015 at 8:49 AM, nigelmegitt notifications@github.com
wrote:

I see what you mean, however I think there remains another interpretation:
that it is reasonable to have a [ presentation | transformation ] processor
that conforms to just one of the profiles, which is my interpretation of
the phrase "conforms to a profile". In other words, there's no real concept
of a generic IMSC 'any profile' processor, and there's no wording that
defines the conformance of a processor that can handle any document in
either profile.

It's clear that there are 2 separate profiles in IMSC.

Having said that, if you really want to derive the profile as the first
step in generic IMSC processing, then I support the algorithm you've
described.

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

[nigelmegitt]

I'm reading the text you've quoted differently from you @skynavga . I think the text you've quoted says exactly that an IMSC processor is required to conform to at least one IMSC profile, though I do agree that it does not say that it must conform to any (i.e. "all") profiles.

If there's an issue here it is that the one:one vs one:two mapping between processor and profiles is unclear.

I do support the idea that a processor should ideally be able to derive the profile from the document, which is e.g. Cyril's use case. I just don't believe that there's a requirement that every IMSC processor be able to handle both profiles.

So in conclusion I don't object to adding the proposed algorithm, but I do object to requiring the existence of generic IMSC processors, and I think it's valid to create a workflow for documents of a single profile, with processors that only know how to deal with that profile.

[skynavga]

On Mon, Dec 7, 2015 at 9:59 AM, nigelmegitt notifications@github.com
wrote:

I'm reading the text you've quoted differently from you @skynavga
https://github.com/skynavga . I think the text you've quoted says
exactly that an IMSC processor is required to conform to at least one IMSC
profile, though I do agree that it does not say that it must conform to
any (i.e. "all") profiles.

It definitely does not require any (either text or image) profile be
supported. It could support neither profile, though that would make it
rather useless. The point is that there is no language that says that an
IMSC processor must at least support one profile.

If there's an issue here it is that the one:one vs one:two mapping between
processor and profiles is unclear.

I do support the idea that a processor should ideally be able to derive
the profile from the document, which is e.g. Cyril's use case. I just don't
believe that there's a requirement that every IMSC processor be able to
handle both profiles.

I never said that, nor assumed it.

So in conclusion I don't object to adding the proposed algorithm, but I do
object to requiring the existence of generic IMSC processors

Where did I say or imply that?

, and I think it's valid to create a workflow for documents of a single
profile, with processors that only know how to deal with that profile.

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

[nigelmegitt]

@skynavga apologies if I'm being slow but I'm struggling to spot the point you're making here. Is it that in:

A [ presentation processor | transformation processor ] that conforms to a profile defined in this specification

the terms are not preceded by "IMSC"?

My reasoning is that a processor that supports neither profile is by definition not a processor that conforms to the IMSC specification and is therefore not something with which we need to be concerned.

I just don't believe that there's a requirement that every IMSC processor be able to handle both profiles.

I never said that, nor assumed it.

Okay, that was the only interpretation I could think of for the issue you described, but happy that's not what you meant.

So in conclusion I don't object to adding the proposed algorithm, but I do object to requiring the existence of generic IMSC processors
Where did I say or imply that?

You described the use case where you have a "generic IMSC processor" - as far as I can tell that's not something that the specification defines anywhere or is intended to support. Furthermore the two profiles are mutually incompatible in the sense that the only documents that conform to both profiles have no content in them. An image profile document that contains/references an image cannot conform to the text profile and a text profile document that contains text cannot conform to the image profile.

[skynavga]

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

@skynavga https://github.com/skynavga apologies if I'm being slow but
I'm struggling to spot the point you're making here. Is it that in:

A [ presentation processor | transformation processor ] that conforms to a
profile defined in this specification

the terms are not preceded by "IMSC"?

My reasoning is that a processor that supports neither profile is by
definition not a processor that conforms to the IMSC specification and is
therefore not something with which we need to be concerned.

This problem could be solved by introducing a term in the definitions as
follows:

IMSC Processor A presentation or transformation processor that
conforms to at least one of the profiles defined in this specification.

I just don't believe that there's a requirement that every IMSC processor
be able to handle both profiles.

I never said that, nor assumed it.

Okay, that was the only interpretation I could think of for the issue you
described, but happy that's not what you meant.

So in conclusion I don't object to adding the proposed algorithm, but I do
object to requiring the existence of generic IMSC processors
Where did I say or imply that?

You described the use case where you have a "generic IMSC processor" - as
far as I can tell that's not something that the specification defines
anywhere or is intended to support. Furthermore the two profiles are
mutually incompatible in the sense that the only documents that conform to
both profiles have no content in them. An image profile document that
contains/references an image cannot conform to the text profile and a text
profile document that contains text cannot conform to the image profile.

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

[skynavga]

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

@skynavga https://github.com/skynavga apologies if I'm being slow but
I'm struggling to spot the point you're making here. Is it that in:

A [ presentation processor | transformation processor ] that conforms to a
profile defined in this specification

the terms are not preceded by "IMSC"?

My reasoning is that a processor that supports neither profile is by
definition not a processor that conforms to the IMSC specification and is
therefore not something with which we need to be concerned.

I just don't believe that there's a requirement that every IMSC processor
be able to handle both profiles.

I never said that, nor assumed it.

Okay, that was the only interpretation I could think of for the issue you
described, but happy that's not what you meant.

So in conclusion I don't object to adding the proposed algorithm, but I do
object to requiring the existence of generic IMSC processors
Where did I say or imply that?

You described the use case where you have a "generic IMSC processor" - as
far as I can tell that's not something that the specification defines
anywhere or is intended to support. Furthermore the two profiles are
mutually incompatible in the sense that the only documents that conform to
both profiles have no content in them.

They are not mutually compatible from a processor implementation
perspective.

An image profile document that contains/references an image cannot conform
to the text profile and a text profile document that contains text cannot
conform to the image profile.

You are focusing only on the document conformance aspect here, you need to
consider the processor conformance. It is obvious to me that a generic IMSC
processor (which I define to mean an IMSC processor that supports both
profiles) is a reasonable and likely interpretation and outcome.

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

[nigelmegitt]

I'd like @palemieux 's view here. The issue I'm seeing is (as raised) whether we need 1) to define an algorithm for a processor that is configured to expect "IMSC" documents to deduce which profile to use, as opposed to 2) if we can reasonably expect processors to be configured either for "IMSC Text" or "IMSC Image".

I'm comfortable with the option 2) right now, and in a broadcast workflow I would strongly prefer it because I would not want for example a supplier to switch between profiles used for delivered subtitle documents on an ad hoc basis and for validators to pass documents of either profile in the same workflow. Others may take a different view.

[skynavga]

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

I'd like @palemieux https://github.com/palemieux 's view here. The
issue I'm seeing is (as raised) whether we need 1) to define an algorithm
for a processor that is configured to expect "IMSC" documents to deduce
which profile to use, as opposed to 2) if we can reasonably expect
processors to be configured either for "IMSC Text" or "IMSC Image".

this is an objection issue for me unless the answer is option 1

I'm comfortable with the option 2) right now, and in a broadcast workflow
I would strongly prefer it because I would not want for example a supplier
to switch between profiles used for delivered subtitle documents on an ad
hoc basis and for validators to pass documents of either profile in the
same workflow. Others may take a different view.

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

[nigelmegitt]

From where does your expectation that there should be a generic IMSC processor derive? If we'd split IMSC in two separate documents one for each profile would you still be implementing a single validator for both? I'm not seeing the logical distinction between what we have now and that scenario.

Having said all that, I'm still happy with the algorithm you've proposed!

[skynavga]

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

From where does your expectation that there should be a generic IMSC
processor derive?

I believe I have now implemented four full implementations of TTML related
processors. Two validators and two presentation engines. They have always
been generic. TTML1 defines presentation processor and transformation
processor in terms of an underlying generic processor. So this concept is
included in IMSC1 as well.

I find it very odd that anyone would question the existence of such a
concept.

If we'd split IMSC in two separate documents one for each profile would
you still be implementing a single validator for both? I'm not seeing the
logical distinction between what we have now and that scenario.

Having said all that, I'm still happy with the algorithm you've proposed!

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

[palemieux]

The specification does not define a generic IMSC1 processor: it defines an IMSC1 Image Profile processor and an IMSC1 Text Profile processor.

In absence of ttp:profile or ebuttm:conformsToStandard, the behavior of a processor that conforms to IMSC1 Text and/or Image Profile will depend on the circumstances. For instance:

• the profile to which the document conforms may have been communicated through the media container, as in Ultraviolet where the the profile identifier is carried in a sample description box in the ISO BMFF file.
• an authoring tool might offer the user the option to explicitly indicate which profile the document conforms to, perhaps offering a suggested choice based on simple heuristics, e.g. is smpte:BackgroundImage present?
• a validation tool might offer the following options:
  • "force-image": validate according to Image Profile, failing if Text Profile is signaled explicitly
  • "force-text": validate according to Text Profile, failing if Image Profile is signaled explicitly
  • "auto": validate according to ttp:profile or ebuttm:conformsToStandard, failing if not present
  • "auto with heuristics": validate according to ttp:profile or ebuttm:conformsToStandard if present, otherwise use heuristics
• "auto with Text fallback": validate according to ttp:profile or ebuttm:conformsToStandard if present, otherwise use Text Profile

I do not see a single solution fitting all scenarios. We could describe a few examples if it helps.

[skynavga]

It is very simple, override the language in TTML1:

If neither ttp:profile
http://www.w3.org/TR/ttml1/#parameter-attribute-profile attribute nor
ttp:profile http://www.w3.org/TR/ttml1/#parameter-vocabulary-profile element
is present in a Document Instance, and if the Document Interchange
Context does not make an implicit or explicit reference to a pre-defined
profile or does not specify a Profile Definition Document or another
equivalent set of feature designations, then the DFXP Transformation
profile applies.

That is, repeat the same text as above except substitute "IMSC1 Text
Profile" for "DFXP Transformation".

On Wed, Dec 9, 2015 at 7:24 PM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

The specification does not define a generic IMSC1 processor: it defines an
IMSC1 Image Profile processor and an IMSC1 Text Profile processor.

In absence of ttp:profile or ebuttm:conformsToStandard, the behavior of a
processor that conforms to IMSC1 Text and/or Image Profile will depend on
the circumstances. For instance:

the profile to which the document conforms may have been communicated
through the media container, as in Ultraviolet where the the profile
identifier is carried in a sample description box in the ISO BMFF file.

an authoring tool might offer the user the option to explicitly
indicate which profile the document conforms to, perhaps offering a
suggested choice based on simple heuristics, e.g. is smpte:BackgroundImage
present?

a validation tool might offer the following options:

• "force-image": validate according to Image Profile, failing if Text
  Profile is signaled explicitly
  • "force-text": validate according to Text Profile, failing if
    Image Profile is signaled explicitly
  • "auto": validate according to ttp:profile or
    ebuttm:conformsToStandard, failing if not present
  • "auto with heuristics": validate according to ttp:profile or
    ebuttm:conformsToStandard if present, otherwise use heuristics
• "auto with Text fallback": validate according to ttp:profile or
  ebuttm:conformsToStandard if present, otherwise use Text Profile

I do not see a single solution fitting all scenarios. We could describe a
few examples if it helps.

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

[skynavga]

You will need to do further edits to this, but you get the idea.

On Wed, Dec 9, 2015 at 7:50 PM, Glenn Adams glenn@skynav.com wrote:

It is very simple, override the language in TTML1:

If neither ttp:profile
http://www.w3.org/TR/ttml1/#parameter-attribute-profile attribute nor
ttp:profile http://www.w3.org/TR/ttml1/#parameter-vocabulary-profile element
is present in a Document Instance, and if the Document Interchange
Context does not make an implicit or explicit reference to a pre-defined
profile or does not specify a Profile Definition Document or another
equivalent set of feature designations, then the DFXP Transformation
profile applies.

That is, repeat the same text as above except substitute "IMSC1 Text
Profile" for "DFXP Transformation".

On Wed, Dec 9, 2015 at 7:24 PM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

The specification does not define a generic IMSC1 processor: it defines
an IMSC1 Image Profile processor and an IMSC1 Text Profile processor.

In absence of ttp:profile or ebuttm:conformsToStandard, the behavior of
a processor that conforms to IMSC1 Text and/or Image Profile will depend on
the circumstances. For instance:

the profile to which the document conforms may have been communicated
through the media container, as in Ultraviolet where the the profile
identifier is carried in a sample description box in the ISO BMFF file.

an authoring tool might offer the user the option to explicitly
indicate which profile the document conforms to, perhaps offering a
suggested choice based on simple heuristics, e.g. is smpte:BackgroundImage
present?

a validation tool might offer the following options:

• "force-image": validate according to Image Profile, failing if Text
  Profile is signaled explicitly
  • "force-text": validate according to Text Profile, failing if
    Image Profile is signaled explicitly
  • "auto": validate according to ttp:profile or
    ebuttm:conformsToStandard, failing if not present
  • "auto with heuristics": validate according to ttp:profile or
    ebuttm:conformsToStandard if present, otherwise use heuristics
• "auto with Text fallback": validate according to ttp:profile or
  ebuttm:conformsToStandard if present, otherwise use Text Profile

I do not see a single solution fitting all scenarios. We could describe a
few examples if it helps.

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

[palemieux]

Well... the proposed approach is not always appropriate IMHO: for instance, an authoring program might simply refuse to consider a document to be an IMSC1 Text or Image Profile document (and instead process it using the DFXP Transformation processor profile) unless explicitly instructed to. In other words, fallback to IMSC1 Text Profile is not always the right approach if the processor cannot determine conformance to either IMSC1 Text or Image Profile.

[skynavga]

On Wed, Dec 9, 2015 at 8:23 PM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

Well... the proposed approach is not always appropriate IMHO: for
instance, an authoring program might simply refuse to consider a document
to be an IMSC1 Text or Image Profile document (and instead process it using
the DFXP Transformation processor profile) unless explicitly instructed to.
In other words, fallback to IMSC1 Text Profile is not always the right
approach if the processor cannot determine conformance to either IMSC1 Text
or Image Profile.

That's correct. But if we don't define a definitive fallback, then an
implementation is forced to use a non-standard heuristic that is
non-deterministic.

Consider it a formal objection on the behalf of SKYNAV if no fallback is
defined.

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

[palemieux]

But if we don't define a definitive fallback, then an
implementation is forced to use a non-standard heuristic that is
non-deterministic.

Do you have an objection to the TTML1 fallback mechanism applying, i.e. DFXP Transformation processor profile, if no determination is made on whether the document conforms to IMSC1?

[skynavga]

On Thu, Dec 10, 2015 at 6:52 AM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

But if we don't define a definitive fallback, then an
implementation is forced to use a non-standard heuristic that is
non-deterministic.

Do you have an objection to the TTML1 fallback mechanism applying, i.e.
DFXP Transformation processor profile, if no determination is made on
whether the document conforms to IMSC1?

In the scenario we are discussing, the processor either knows or has been
told that the document is an IMSC document (of unspecified profile), so the
DFXP transformation profile is not an option.

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

[palemieux]

In the scenario we are discussing, the processor either knows or has been told that the document is an IMSC document (of unspecified profile)

The specification does not specify "an IMSC1 document", only an IMSC1 Text Profile document and an IMSC1 Image Profile document.

An algoriithm using the presence of smpte:backgroundImage and span as heuristics could be provided as examples.

[skynavga]

Examples are not sufficient, a normative algorithm is required. And it
matters not that the spec doesn't refer to an "IMSC1 document" without
qualifying the profile. It refers to "Document Instance" adopting the even
more generic TTML1 definition, and it clearly implies IMSC1 Document as a
TTML1 Document Instance that conforms to one of the defined profiles.

I'm getting a little tired arguing this point. Please just do as I ask and
take my proposed text and turn it into text you are satisfied with
including on a normative basis.

On Thu, Dec 10, 2015 at 9:34 AM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

In the scenario we are discussing, the processor either knows or has been
told that the document is an IMSC document (of unspecified profile)

The specification does not specify "an IMSC1 document", only an IMSC1 Text
Profile document and an IMSC1 Image Profile document.

An algoriithm using the presence of smpte:backgroundImage and span as
heuristics could be provided as examples.

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

[palemieux]

Please just do as I ask and
take my proposed text and turn it into text you are satisfied with
including on a normative basis.

The proposed text at #111 (comment) ?

If so, the proposed text is inadequate since a fallback to Text Profile is not appropriate in all circumstances, and cannot be compelled by "SHALL" language.

What situation are you trying to prevent by proposing this language?

Perhaps you have another proposal?

[skynavga]

On Thu, Dec 10, 2015 at 10:36 AM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

Please just do as I ask and
take my proposed text and turn it into text you are satisfied with
including on a normative basis.

The proposed text at #111 (comment)
#111 (comment) ?

Here is modified text:

If the ttp:profile attribute is not present in a Document Instance, and
if the Document Interchange Context does not make an implicit or explicit
reference to a profile defined by this specification, then the IMSC1 Text
profile SHALL apply.

If so, the proposed text is inadequate since a fallback to Text Profile is

not appropriate in all circumstances, and cannot be compelled by "SHALL"
language.

Yes it can, because the document interchange context language covers all
those circumstances. And it MUST be a shall condition, otherwise it means
nothing.

What situation are you trying to prevent by proposing this language?

Anarchy.

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

[palemieux]

In fact, IMSC1 cannot define the fallback as Text Profile since a Document Instance that does not conform to Image and Text Profile can in fact conform to another specification, e.g. EBU-TT-D.

In other words, this specification applies only if the Instance Document is determined to be Text Profile or Image Profile.

Anarchy.

You will need to be more specific. In what interchange scenario would the absence of a fallback be harmful?

[skynavga]

On Thu, Dec 10, 2015 at 11:57 AM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

In fact, IMSC1 cannot define the fallback as Text Profile since a Document
Instance that does not conform to Image and Text Profile can in fact
conform to another specification, e.g. EBU-TT-D.

In other words, this specification applies only if the Instance Document
is determined to be Text Profile or Image Profile.

Anarchy.

You will need to be more specific. In what interchange scenario would the
absence of a fallback be harmful?

In a multi-profile validator, transformer, or presentation engine. What is
the push back here?

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

[nigelmegitt]

Here's an alternative proposal, not fleshed out as a pull request, but just to test the concept before going to a load of effort for something that will be rejected a priori:

• Add for each profile a "content identification" section with an algorithm for deriving when it is clear to which profile a document claims conformance and some heuristics that may be used when it is unclear, for example:

1. If the ttp:profile attribute is present and specifies [text | image], that defines the profile.
2. If the ttp:profile attribute is absent but ebuttm:conformsToStandard is present and references EBU-TT-D then that defines the profile
3. If at this stage the profile has not been derived and there is no further external information then the profile is unknown. Heuristics may be used, for example:
   3a. If the document contains p or span elements it may be a text profile document.
   3b. If the document contains images it may be an image profile document.
   3c. The document may not conform to either IMSC profile at all.

This would be two algorithms, one for each profile. There is no such grouping as generic IMSC - any processor being told to process a document as "IMSC" has been mis-configured.

[skynavga]

No, this isn't adequate or desirable. See more below.

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

Here's an alternative proposal, not fleshed out as a pull request, but
just to test the concept before going to a load of effort for something
that will be rejected a priori:

Add for each profile a "content identification" section with an
algorithm for deriving when it is clear to which profile a document claims
conformance and some heuristics that may be used when it is unclear, for
example:

1. If the ttp:profile attribute is present and specifies [text |
   image], that defines the profile.

this is ok

1. If the ttp:profile attribute is absent but
   ebuttm:conformsToStandard is present and references EBU-TT-D then that
   defines the profile

this is not ok, in the sense that use of ebuttm:conformsToStandard is just
one possible heuristic that could be used by a sniffer as a pre-processor;
the algorithm I'm asking for should not use any heuristics, i.e., should
not be a sniffer, but merely serve as a failsafe fallback, e.g., in the
absence of a sniffer;

1. If at this stage the profile has not been derived and there is no
   further external information then the profile is unknown. Heuristics may be
   used, for example: 3a. If the document contains p or span elements it may
   be a text profile document. 3b. If the document contains images it may be
   an image profile document. 3c. The document may not conform to either IMSC
   profile at all.

again, this is attempting to define a sniffer, but that is not what i'm
asking for;

This would be two algorithms, one for each profile.

That doesn't make any sense. You can't choose an algorithm to determine a
profile without knowing the profile.

There is no such grouping as generic IMSC - any processor being told to
process a document as "IMSC" has been mis-configured.

I would certainly disagree strongly with this statement. There are already
such processors in use with such practice being followed. You seem to be
stuck on the idea that IMSC processors must be text-profile only or
image-profile only. That is a short-sighted viewpoint.

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

[nigelmegitt]

You seem to be stuck on the idea that IMSC processors must be text-profile only or image-profile only. That is a short-sighted viewpoint.

Well you seem to be stuck on the idea that a generic "IMSC processor" must exist. And you seem to be the only person on this discussion with this viewpoint. There's nothing in the IMSC specification that defines a generic IMSC concept, and I would object to adding it.

I don't have any problem with the idea that a processor can support both IMSC text profile and IMSC image profile documents, and agree that such a processor would need somehow to know what it is processing, but that construct (a processor that supports both) is not a matter for the specification.

this is not ok, in the sense that use of ebuttm:conformsToStandard is just
one possible heuristic that could be used by a sniffer as a pre-processor;
the algorithm I'm asking for should not use any heuristics, i.e., should
not be a sniffer, but merely serve as a failsafe fallback, e.g., in the
absence of a sniffer;

At some level every algorithm is a variant on a heuristic, since what the document claims may not match the reality - you can construct a document that claims to be a text profile document but that includes images; in reality it would not be valid against either IMSC profile but you would only know that by attempting to validate it fully.

Since all the proposed mechanisms other than 'external context' involve examining the document they're all sniffers.

You can't choose an algorithm to determine a profile without knowing the profile.

You can iterate through each 'profile identification algorithm' in turn until you have sufficient confidence in the outcome. Each profile has its own algorithm in this case, based on specific values of e.g. ttp:profile.

My proposal was designed to provide some mechanisms for processors to identify profile by examining the document, which is what I understand the requirement to be. If that doesn't help you then I suggest we take no action and reluctantly carry your objection forward as unresolved. We have no consensus right now on any resolution to this issue, and we do not even have consensus on the predicate of the issue.

[skynavga]

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

You seem to be stuck on the idea that IMSC processors must be text-profile
only or image-profile only. That is a short-sighted viewpoint.

Well you seem to be stuck on the idea that a generic "IMSC processor" must
exist. And you seem to be the only person on this discussion with this
viewpoint. There's nothing in the IMSC specification that defines a generic
IMSC concept, and I would object to adding it.

Let's stop using the term "generic IMSC processor" as this conflicts with
the use of "generic processor" in TTML1. I pointed out previously that what
I'm really talking about is a "multiple-profile IMSC processor".

As for the existence or expectation of existence of a multiple-profile IMSC
processor: it already exists in multiple forms, not only for IMSC but also
for TTML, which though it (the TTML spec) doesn't explicitly discuss either
a "single-processor" or a "multiple-processor" profile, it defines multiple
profiles and both single- and multiple-profile implementations are natural
uses of the spec.

If you don't mind going to the director with a Formal Objection
outstanding, then feel free to ignore our position. Otherwise, I'd suggest
you figure out how to address the substance of our comment.

I don't have any problem with the idea that a processor can support both

IMSC text profile and IMSC image profile documents, and agree that such a
processor would need somehow to know what it is processing, but that
construct (a processor that supports both) is not a matter for the
specification.

It is just as much a construct of the specification as a "single-profile"
implementation, which is also not defined by the specification. The
specification defines behavior for a presentation processor and a
transformation processor. It does not define a "text-profile only
presentation processor" or an "image-profile only presentation processor".

Why are you assuming that a single-profile processor is defined (when it is
not) and rejecting the notion of a multiple-profile processor? At best, the
specification is completely silent on the notion of either single-profile
or multiple-profile support. In this regard, the spec is ambiguous, and you
cannot assume that a single-profile processor is sanctioned while a
multiple-profile processor is non-existent.

this is not ok, in the sense that use of ebuttm:conformsToStandard is just
one possible heuristic that could be used by a sniffer as a pre-processor;
the algorithm I'm asking for should not use any heuristics, i.e., should
not be a sniffer, but merely serve as a failsafe fallback, e.g., in the
absence of a sniffer;

At some level every algorithm is a variant on a heuristic, since what the
document claims may not match the reality - you can construct a document
that claims to be a text profile document but that includes images; in
reality it would not be valid against either IMSC profile but you would
only know that by attempting to validate it fully.

Since all the proposed mechanisms other than 'external context' involve
examining the document they're all sniffers.

You can't choose an algorithm to determine a profile without knowing the
profile.

You can iterate through each 'profile identification algorithm' in turn
until you have sufficient confidence in the outcome. Each profile has its
own algorithm in this case, based on specific values of e.g. ttp:profile.

My proposal was designed to provide some mechanisms for processors to
identify profile by examining the document, which is what I understand the
requirement to be. If that doesn't help you then I suggest we take no
action and reluctantly carry your objection forward as unresolved.

That is unacceptable since we have proposed a very simple resolution which
you have ignored or failed to show why it is not technically feasible:

"If no tts:profile is specified, then the text profile applies."

All you have offered is a more complex approach that may require parsing
the whole document (to the end) and which is inappropriate as a failsafe
fallback.

We have no consensus right now on any resolution to this issue, and we do
not even have consensus on the predicate of the issue.

We may need one or more meetings to resolve this issue.

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

[skynavga]

In the interest of moving this process forward, I will offer a revised
proposal to address out concerns. The proposal takes the form of adding the
following normative language:

Add to Section 3:

Single-Profile Processor. A Processor that supports one and only one of the
profiles defined in Section 5, namely, the Text Profile or the Image
Profile.

Multiple-Profile Processor. A Processor that supports both of the profiles
defined in Section 5, namely, both the Text Profile and the Image Profile.

Add to Section 5.1 (or wherever deemed appropriate):

A Single-Profile Processor shall process a Document Instance in accordance
to the single profile which it supports. If a ttp:profile attribute is
present and its value is not equal to the profile designator associated
with that single supported profile, then the Document Instance may be
considered incompatible with that Processor and subject to abort
processing. If no ttp:profile attribute is present, then the Document
Instance should be tentatively considered to be compatible with that
Processor and subject to normal processing.

A Multiple-Profile Processor shall process a Document Instance in
accordance to one of its supported profiles. If a ttp:profile attribute is
present and its value is not equal to the profile designator associated
with any of the supported profiles, then the Document Instance may be
considered incompatible with that Processor and subject to abort
processing. If no ttp:profile attribute is present, and if no profile
metadata is provided by the Document Interchange Context, then the Document
Instance should be tentatively considered to be compatible with the Text
Profile and subject to normal processing as such.

Note: A Document Interchange Context can obtain profile metadata by
multiple means, including but not limited to: profile parameter data
provided by a content container or envelope, using a pre-processor that
attempts to guess the applicable profile, etc.

On Wed, Dec 16, 2015 at 9:13 AM, Glenn Adams glenn@skynav.com wrote:

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

You seem to be stuck on the idea that IMSC processors must be
text-profile only or image-profile only. That is a short-sighted viewpoint.

Well you seem to be stuck on the idea that a generic "IMSC processor"
must exist. And you seem to be the only person on this discussion with this
viewpoint. There's nothing in the IMSC specification that defines a generic
IMSC concept, and I would object to adding it.

Let's stop using the term "generic IMSC processor" as this conflicts with
the use of "generic processor" in TTML1. I pointed out previously that what
I'm really talking about is a "multiple-profile IMSC processor".

As for the existence or expectation of existence of a multiple-profile
IMSC processor: it already exists in multiple forms, not only for IMSC but
also for TTML, which though it (the TTML spec) doesn't explicitly discuss
either a "single-processor" or a "multiple-processor" profile, it defines
multiple profiles and both single- and multiple-profile implementations are
natural uses of the spec.

If you don't mind going to the director with a Formal Objection
outstanding, then feel free to ignore our position. Otherwise, I'd suggest
you figure out how to address the substance of our comment.

I don't have any problem with the idea that a processor can support both

IMSC text profile and IMSC image profile documents, and agree that such a
processor would need somehow to know what it is processing, but that
construct (a processor that supports both) is not a matter for the
specification.

It is just as much a construct of the specification as a "single-profile"
implementation, which is also not defined by the specification. The
specification defines behavior for a presentation processor and a
transformation processor. It does not define a "text-profile only
presentation processor" or an "image-profile only presentation processor".

Why are you assuming that a single-profile processor is defined (when it
is not) and rejecting the notion of a multiple-profile processor? At best,
the specification is completely silent on the notion of either
single-profile or multiple-profile support. In this regard, the spec is
ambiguous, and you cannot assume that a single-profile processor is
sanctioned while a multiple-profile processor is non-existent.

this is not ok, in the sense that use of ebuttm:conformsToStandard is just
one possible heuristic that could be used by a sniffer as a pre-processor;
the algorithm I'm asking for should not use any heuristics, i.e., should
not be a sniffer, but merely serve as a failsafe fallback, e.g., in the
absence of a sniffer;

At some level every algorithm is a variant on a heuristic, since what the
document claims may not match the reality - you can construct a document
that claims to be a text profile document but that includes images; in
reality it would not be valid against either IMSC profile but you would
only know that by attempting to validate it fully.

Since all the proposed mechanisms other than 'external context' involve
examining the document they're all sniffers.

You can't choose an algorithm to determine a profile without knowing the
profile.

You can iterate through each 'profile identification algorithm' in turn
until you have sufficient confidence in the outcome. Each profile has its
own algorithm in this case, based on specific values of e.g. ttp:profile.

My proposal was designed to provide some mechanisms for processors to
identify profile by examining the document, which is what I understand the
requirement to be. If that doesn't help you then I suggest we take no
action and reluctantly carry your objection forward as unresolved.

That is unacceptable since we have proposed a very simple resolution which
you have ignored or failed to show why it is not technically feasible:

"If no tts:profile is specified, then the text profile applies."

All you have offered is a more complex approach that may require parsing
the whole document (to the end) and which is inappropriate as a failsafe
fallback.

We have no consensus right now on any resolution to this issue, and we do
not even have consensus on the predicate of the issue.

We may need one or more meetings to resolve this issue.

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

[palemieux]

Thanks for the revised proposal. The following drawbacks remain in my opinion:

• the algorithm ignores the contents of the ebuttm:conformsToStandard element, whose contents indicate a priori conformance of the document (see Section 6.10)
• the algorithm prescribes fallback behavior that is not generally applicable to or recommended for all scenarios and implementations. Specifically, in absence of conclusive in-band or out-of-band conformance information, some processors may choose to:
  • use heuristics to determine conformance, e.g. the presence of smpte:backgroundImage
  • request the user to select from a list of profiles
  • tentatively validate according to a list of prioritized models and select the first model that validates successfully
  • render under best effort, e.g. assume that the document conforms to either IMSC1 Text or Image profile and render according to the union of the two profiles.
  • abort processing
  • accept the document and log a warning
• the specific choice of ultimate fallback to IMSC1 Text Profile should not be encouraged since processing a IMSC1 Image profile document by an IMSC1 Text Profile processor will always yield undesirable results, i.e. nothing.

Overall, a single algorithm will not fit all applications. IMSC1 could nevertheless:

• list heuristics for determining conformance
• further encourage the use of ttp:profile and ebuttm:conformsToStandard when no external context conveys conformance information, e.g. if the multimedia container does not signal conformance of the subtitle track.

See also #111 (comment) and #111 (comment)

[skynavga]

see inline below; overall, none of these comments suggest technical
problems or changes to the revised proposal;

On Thu, Dec 17, 2015 at 10:52 PM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

Thanks for the revised proposal. The following drawbacks remain in my
opinion:

• the algorithm ignores the contents of the ebuttm:conformsToStandard
  element, whose contents indicate a priori conformance of the document (see
  Section 6.10)

(1) the algorithm allows for the document interchange context to supply a
profile based on pre-processing the document, e.g., to look for content
that could provide more guidance;
(2) if no profile metadata is supplied by the document interchange context,
then the algorithm selects the text profile, which is the correct guess in
case the document is an EBU-TT-D document;

• the algorithm prescribes fallback behavior that is not generally
  applicable to or recommended for all scenarios and implementations.

that is the nature of a fallback default, it may be wrong; the only time
it will be wrong is if the document is a document that adheres to the image
profile, but does not specify ttp:profile, and no profile metadata is
available from the document interchange context, either a
container/envelope supplied profile or a heuristically determined profile
by means of a pre-processor;

the goal of defining a fallback default is not to correctly answer the
question "what profile does this document conform to?"; rather, it is to
supply an answer to a multiple profile processor which must select some
profile in order to perform processing

• Specifically, in absence of conclusive in-band or out-of-band
  conformance information, some processors may choose to:
  • use heuristics to determine conformance, e.g. the presence of
    smpte:backgroundImage

yes, this is allowed by the algorithm as part of the document interchange
context processing;

• • request the user to select from a list of profiles

yes, this is allowed by the algorithm as part of the document interchange
context processing;

• • tentatively validate according to a list of prioritized models
    and select the first model that validates successfully

yes, this is allowed by the algorithm as part of the document interchange
context processing, as a possible pre-processing strategy;

• • render under best effort, e.g. assume that the document conforms
    to either IMSC1 Text or Image profile and render according to the union of
    the two profiles.

this would be outside the scope of IMSC since it does not define
processing for a union of the two profiles; but this is not ruled out by
the proposed algorithm

• • abort processing

this is already covered by the proposed algorithm: e.g., if using the
fallback default of text profile turns out to be wrong (the document
conforms to image profile), then "subject to normal processing" includes
the note in Section 3:

NOTE

This specification does not specify presentation processor
https://rawgit.com/w3c/imsc1/master/spec/ttml-ww-profiles.html#dfn-presentation-processor
or transformation processor
https://rawgit.com/w3c/imsc1/master/spec/ttml-ww-profiles.html#dfn-transformation-processor
behavior
when processing or transforming a non-conformant Document Instance
https://rawgit.com/w3c/imsc1/master/spec/ttml-ww-profiles.html#dfn-document-instance
.
in other words, the processor will do whatever it likes if it determines
that the document doesn't conform to the fallback default profile

• • accept the document and log a warning

this is covered by the previous comment;

• • the specific choice of ultimate fallback to IMSC1 Text Profile
    should not be encouraged since processing a IMSC1 Image profile document by
    an IMSC1 Text Profile processor will always yield undesirable results, i.e.
    nothing.

in that case, make sure your implementation does something better than the
fallback default, e.g., add a pre-processor that sniffs the profile based
on document content; the proposed algorithm explicitly allows this and
notes this fact;

Overall, a single algorithm will not fit all applications.

there is nothing about the proposed algorithm that does not allow an
application to do whatever it wants; ""whatever it wants" comes to play in
three places:

• an application is free to do whatever it wants in terms of
  implementing a pre-processor that answers the question "what profile to
  use?" in order to obtain profile metadata to be used by the processor
  proper;
• an application is free to interpret the above cited note regarding
  processing/transforming a non-conformant document instance (in the case
  that the fallback default is wrong);
• the new proposal doesn't actually mandate that text profile be used as
  the fallback, it only recommends it "should"

IMSC1 could nevertheless:

• list heuristics for determining conformance

it could do so, but that would constitute defining a sniffer
pre-processor, something that i am not proposing we do at this time; there
is nothing about the proposal that would prevent this being defined in the
future; it is essentially orthogonal to the proposal;

• further encourage the use of ttp:profile and
  ebuttm:conformsToStandard when no external context conveys conformance
  information, e.g. if the multimedia container does not signal conformance
  of the subtitle track.

it could also require that ttp:profile be present if the document is
claimed to adhere to the image profile, but leave the current
optional/prohibited use in place for handling non-EBU-TT-D text profile
documents and EBU-TT-D text profile documents; in that fashion, the
fallback default would always be correct

requiring ttp:profile for image profile documents would never conflict with
EBU-TT-D usage that allegedly prohibits the presence of ttp:profile

See also #111 (comment)
#111 (comment) and #111
(comment) #111 (comment)

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

[nigelmegitt]

Status update: this issue has not been concluded and remains open; in the meantime we have requested a transition of IMSC 1 to a new Candidate Recommendation, with Skynav's formal objection carried up to the Director.

We can continue to work on this issue to reach a solution that everyone can accept. In fact by the Process we must do that since we cannot move to Proposed Recommendation with any unresolved issues remaining.

[skynavga]

Based on further discussions, I propose a resolution to this issue as indicated below. I wish I could express in a more simple fashion; however, without delineating the various forks in the decision tree, the result would remain ambiguous. I am not entirely certain that I've take care of all ambiguity here, so if you find something questionable, please say so.

Note that this new proposed language does not make use of any of the terms previously proposed, such as Single- or Multiple-Profile IMSC Processor, and is written in a generic fashion to handle all foreseeable implementation options. The only external terms referenced are "Document Interchange Context" and "Document Processing Context", both of which are defined in TTML1 2Ed. I would note that the terms "interoperable", "feasibly interoperable", and "compatible" remain undefined. I don't propose that we attempt to pin these down more precisely, as it would be time consuming and probably error prone. Notwithstanding a precise definition, these terms should have a reasonable operational interpretation in the mind of the reader.

Add new section 6.10 "Profile Resolution Semantics" containing the following:

For the purpose of content processing, the determination of resolved profile SHOULD take into account both the signaled profile, as defined by Section 6.9, and profile metadata, as designated by either (or both) the Document Interchange Context or (and) the Document Processing Context.

If a profile is signaled, then the tentative resolved profile is the signaled profile; otherwise, if a profile is designated by profile metadata, then the tentative resolved profile is the profile designated by profile metadata. If no profile is signaled and no profile is designated by profile metadata, then the tentative resolved profile is the Text Profile, if supported; otherwise, it is the Image Profile, if supported; otherwise, it is undefined.

If the tentative resolved profile is not the Text Profile or the Image Profile, but is feasibly interoperable with exactly one of these two profiles, then the tentative resolved profile is the profile with which it is feasibly interoperable; otherwise, if it feasibly interoperable with both of these two profiles, then the tentative resolved profile is the Text Profile (if supported); otherwise it is the Image Profile (if supported).

If the tentative resolved profile is undefined, or is not feasibly interoperable with either Text Profile or Image Profile, or its feasible interoperability is unknown, then processing SHOULD be aborted.

If the tentative resolved profile is the Text Profile, the Text Profile is supported, and the document instance is compatible with the Text Profile, then the resolved profile is the Text Profile; otherwise, if the tentative resolved profile is the Image Profile, the Image Profile is supported, and the document instance is compatible with the Image Profile, then the resolved profile is the Image Profile; otherwise, the resolved profile is undefined.

If the resolved profile is undefined, then a processor MAY attempt to determine compatibility of the document instance with either (or both) Text Profile or (and) Image Profile, and, if such determination is made, then the resolved profile is the compatible profile, or, if compatible with both, whichever of the two profiles are supported, or, if both are supported, the Text Profile.

If the resolved profile remains undefined, processing SHOULD be aborted; otherwise, the document instance SHOULD be processed according to the resolved profile.

_

[palemieux]

Below is an edited proposal intended to:

• explicitly cover processors that support a large number of profiles
• separate profile determination from processor processing behavior
• allow the processor to choose a default profile other than Text or Image if the resolved profile is undetermined or unsupported

---

The Processor SHOULD determine the profiles to which the Instance Document conforms ("resolved profiles") using, in order of preference:

• the profile signaling mechanisms specified in Section 6.9;
• the Document Interchange Context or (and) the Document Processing Context, which MAY involve inspection of the instance document.

If one of the resolved profile is a profile supported by the Processor, then the Processor SHOULD process the document instance according to the resolved profile.

If none of the resolved profiles are supported by the Processor but one resolved profile is feasibly interoperable with the Text Profile, then the Processor SHOULD process the document instance as if it conforms to the Text Profile.

If none of the resolved profiles are supported by the Processor but one resolved profile is feasibly interoperable with the Image Profile, then the Processor SHOULD process the document instance as if it conforms to the Image Profile.

If the resolved profiles are undetermined or none of the resolved profiles is supported by the processor, then the Processor SHOULD nevertheless process the document instance using one of its supported profile, with a preference for the Text Profile over the Image Profile.

As a last resort, the Processor SHOULD abort processing.

[palemieux]

Below is a revised proposal based on 20160204 TTWG meeting and further input from @nigelmegitt and @skynavga

PROFILE RESOLUTION SEMANTICS

For the purpose of content processing, the determination of resolved profile SHOULD take into account both the signaled profile, as defined by Section 6.9, and profile metadata, as designated by either (or both) the Document Interchange Context or (and) the Document Processing Context, which MAY entail inspecting document content.

If the resolved profile is a not a profile supported by the Processor but is feasibly interoperable with the Text Profile, then the resolved profile is the Text Profile; otherwise, if the resolved profile is a not a profile supported by the Processor but is feasibly interoperable with the Image Profile, then the resolved profile is the Image Profile.

If the resolved profile is a profile supported by the Processor, then the Processor SHOULD process the document instance according to the resolved profile. If the resolved profile is neither Text Profile nor Image Profile, processing is outside the scope of this specification.

If the resolved profile is undetermined or not supported by the processor, then the Processor SHOULD nevertheless process the document instance using one of its supported profiles, with a preference for the Text Profile over the Image Profile; otherwise, processing MAY be aborted.

[skynavga]

LGTM

On Thu, Feb 4, 2016 at 10:38 AM, Pierre-Anthony Lemieux <
notifications@github.com> wrote:

Below is a revised proposal based on 20160204 TTWG meeting and further
input from @nigelmegitt https://github.com/nigelmegitt and @skynavga
https://github.com/skynavga

PROFILE RESOLUTION SEMANTICS

For the purpose of content processing, the determination of resolved
profile SHOULD take into account both the signaled profile, as defined by
Section 6.9, and profile metadata, as designated by either (or both) the
Document Interchange Context or (and) the Document Processing Context,
which MAY entail inspecting document content.

If the resolved profile is a not a profile supported by the Processor but
is feasibly interoperable with the Text Profile, then the resolved profile
is the Text Profile; otherwise, if the resolved profile is a not a profile
supported by the Processor but is feasibly interoperable with the Image
Profile, then the resolved profile is the Image Profile.

If the resolved profile is a profile supported by the Processor, then the
Processor SHOULD process the document instance according to the resolved
profile. If the resolved profile is neither Text Profile nor Image Profile,
processing is outside the scope of this specification.

If the resolved profile is undetermined or not supported by the processor,
then the Processor SHOULD nevertheless process the document instance using
one of its supported profiles, with a preference for the Text Profile over
the Image Profile; otherwise, processing MAY be aborted.

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

[nigelmegitt]

LGTM

[nigelmegitt]

Would really appreciate your views on #111 (comment), @TairT and @cconcolato (as well as everyone else of course).

[andreastai]

Fine with me.