Re: profile definition and resolution [was RE: ISSUE-261: signaling docoument profile conformance is separate from decoder presentation requirements [TTML.next]

On Mon, Jul 15, 2013 at 9:48 AM, Michael Dolan <mdolan@newtbt.com> wrote:

> Glenn-****
>
> ** **
>
> The reason that I think a profile document itself is an inadequate tool to
> define a profile is that the granularity of the features has never (to
> date) matched the defined profile capabilities per the related prose for
> those profiles.
>

But the purpose of the TT Profile Document is not to define a profile. It
is to specify a set of features/extensions having been defined elsewhere.
You are talking about the "defined elsewhere" part of this equation, i.e.,
which features/extensions are defined, whether their definitions are
adequate or not.

The implied contract for a TT Profile Document is that it simply enumerates
features/extensions and assigns each a value (required, optional, etc), and
that a TTML Content Processor has a way (or can have a way) to determine if
it supports an enumerated feature.

When a TT document references a feasibly resolvable TT Profile Document, it
is simply using a shorthand, which it could instead of defined inline,
i.e., enumerated the features it requires inline.

When a processor encounters such a reference it has some options:

(1) it has a built-in (cached) form of the referenced profile, so doesn't
need to make an external reference (though it may choose to do so to update
its cache);

(2) it doesn't have a cached form or it wants to update its cache, so it
attempts to resolve and parse the referenced profile, which may succeed or
fail;

(3) if (2) fails, then it consults its system/user preferences to determine
whether to continue processing or abort the document;

If the processor did resolve the profile to a TT Profile Document, then it
knows which features it supports and which it doesn't, at least for those
defined at the time it was constructed/updated. If the TT Profile Document
(as parsed and possibly augmented by inline profile elements) requires a
feature it doesn't support, then it again consults its preferences, and
either continues or aborts.




>  ****
>
> ** **
>
> Without explicit restriction, a feature must be assumed to be fully
> supported.
>

The TT profile document says what the processor is to do if it isn't
supported and its value is 'required' or 'used'. It is up the processor to
determine if it supports the feature or not according to wherever the
feature is defined. In  the present TTML profiles, that is Appendix D or
SDP-US.


> ****
>
> ** **
>
> For example, let’s use tts:color.  SDP-US constrains the color
> representations in ways that are not covered in the TTML profile feature,
> #color. The granularity of this feature in TTML is all or nothing.
> Therefore, if an SDP-US (only) decoder were to receive a profile (URI or
> inline) that contained the #color feature, it would be forced to reject the
> instance document since the decoder does not support all the
> representations.
>

That's correct, at least in the sense that the syntactic representations of
color supported in TTML must be supported; however, it doesn't mean the
semantic meaning must be supported [1]:

A TTML presentation processor supports the #color feature if it (1)
implements presentation semantic support for the
tts:color<http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#style-attribute-color>
attribute
and (2) is capable of displaying or generating an output display signal
that distinguishes between at least sixteen (16) values of color, including
all primary and secondary colors of the SRGB color space.

[1] http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#feature-color

Furthermore, even if the processor didn't support these semantics, the
author could simply override the feature requirement by making it optional:

<profile use="dfxp-presentation">
  <features>
    <feature value="optional">#color</feature>
  </features>
</profile>


> ****
>
> The extension mechanism cannot, at least as I read the spec, be applied to
> TTML features, only 3rd party features – that is, extensions to TTML, not
> TTML itself. And, 3rd parties are prohibited from defining new features
> in the TTML namespaces.
>
Why is this a problem? Extensions are just an alias for "non-standard
features". Any 3rd party, or even the W3C itself is free to define new
extension URIs which may be referenced by TT Profile documents or by TTML
documents. If the TTWG wants to formally standardize on an extension, i.e.,
promote it to a "standard feature", then it just defines such a feature in
some document.


> ** **
>
> Since it is common practice today is to define profiles with features
> constrained in ways not pre-defined in TTML 1.0, how is it possible to
> create a useful profile document? Perhaps I am missing something about the
> profile/feature/extension mechanism?
>
(1) third parties can define new extension URIs along with some definition
thereof;
(2) authors of TT Profile documents can include references to such
extensions;
(3) authors of TTML documents can reference predefined TT Profile documents
and can at their discretion augment or restrict those definitions by
specifying feature/extension references inline (as in above example);


> ****
>
> ** **
>
> But if we can’t make a useful profile document, there is little point in
> requiring the URI for it to be resolvable to a physical document.
>
You can make a useful profile document. I'm not getting why you think that
is hard or impossible. Perhaps if you give me a more concrete example of
what you would like to do, I can explain how to do it with the current
mechanisms.


> ****
>
> ** **
>
> Regards,****
>
> ** **
>
>                 Mike****
>
> ** **
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Monday, July 15, 2013 6:58 AM
> *To:* Michael Dolan
> *Cc:* Timed Text Working Group
> *Subject:* Re: ISSUE-261: signaling docoument profile conformance is
> separate from decoder presentation requirements [TTML.next]****
>
> ** **
>
> ** **
>
> On Fri, Jul 12, 2013 at 2:40 PM, Michael Dolan <mdolan@newtbt.com> wrote:*
> ***
>
> Agreed.  But the inline form is already permitted, and I don't see a
> compelling reason to disallow it. That said, I would expect the "normal"
> case is to use a URI.
>
> Since you said "URI" and not URL, it begs that we return to the question of
> resolvability and existence of the TTML syntax profile.  I still maintain
> that the profile must be definable in prose or other means without actually
> creating and/or posting a resolvable profile document that conforms to the
> feature syntax defined in TTML.****
>
> ** **
>
> These are orthogonal issues:****
>
> ** **
>
> (1) defining a profile****
>
> (2) defining a feasibly resolvable profile document****
>
>  ****
>
> The feature granularity is insufficient to
> describe any (I think) of the profiles in use today.****
>
> ** **
>
> Note that the purpose of a feasibly resolvable profile document is not
> intended to formally define a profile (in the more general sense you are
> using it). It is up to us (or extension definers) to be as specific as
> desired in enumerating feature and extension designators.****
>
> ** **
>
> A feasibly resolvable profile document is effectively needed (in the use
> of a non-standard profile and in the absence of an inline profile document)
> in order for a processor to know whether it should process a document based
> on which features are implemented by the processor.****
>
>  ****
>
> Minimally there are
> certainly profile examples that cannot be (sdp-us and cff-tt). The feature
> mechanism cannot be extended by 3rd parties.****
>
> ** **
>
> If by "extended by 3rd parties" you mean defining new non-standard
> "features", then yes it is supported, since a non-standard "feature" is
> just what we call an "extension". Or do you have something else in mind by
> "extended"?****
>
>  ****
>
> This effectively forces
> permitting the profiles to be defined by other means, and therefore, there
> cannot necessarily be a profile document, and therefore cannot be
> resolvable
> in all cases.****
>
> ** **
>
> The definition of a profile document and its accessibility by a processor
> is not related to the definition of a profile itself. It (the document
> referenced by the URI) serves an operational purpose only.****
>
> ** **
>
> I see no legitimate reason for anyone to define a TTML profile (as
> presently defined) and fail to define a feasibly resolvable profile
> document instance.****
>
>  ****
>
>
> Regards,
>
>         Mike****
>
>
> -----Original Message-----
> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
> Sent: Friday, July 12, 2013 1:24 PM
> To: Glenn Adams
> Cc: Timed Text Working Group
> Subject: Re: ISSUE-261: signaling docoument profile conformance is separate
> from decoder presentation requirements [TTML.next]
>
> > Is there a use case for having a document include inline the definition
> of
> a content profile it claims to conform to?
>
> Such a use case does not immediately come to (my) mind.
>
> -- Pierre
>
> On Fri, Jul 12, 2013 at 1:18 PM, Glenn Adams <glenn@skynav.com> wrote:
> > Is there a use case for having a document include inline the
> > definition of a content profile it claims to conform to? Or is it
> > sufficient to allow a document to refer to a URI which is feasibly
> > resolvable to a definition of a content profile?
> >
> >
> > On Fri, Jul 12, 2013 at 2:08 PM, Pierre-Anthony Lemieux
> > <pal@sandflow.com>
> > wrote:
> >>
> >> > > Some means must be defined to separately signal these different
> >> > > semantics.
> >> > For example, we could create a new element and attribute -
> >> > <ContentProfile> and contentProfile.
> >>
> >> Sounds good. I also see value in exploring means for (a) defining a
> >> content profile and (b) signaling conformance of a document to one or
> >> more content profile.
> >>
> >> > <ContentProfile>
> >>
> >> What about following the <ttp:profile> template with the following
> tweaks:
> >>
> >> - adding a @designator attribute allowing the content profile
> >> designator to be specified
> >> - @use can contain one or more URIs, each identifying a content
> >> profile to be included in its entirety by reference, thereby avoiding
> >> having to repeat all features already defined in another profile.
> >> Perhaps @use can reference "profile" even when defining
> >> "contentProfile" so that existing content designator can be used.
> >> - allowing constraints over a base content profile to be specified
> >> using value="prohibited"
> >>
> >> <contentprofile designator="http://example.noname/profile1"
> >> use="http://example.noname/profile4 http://example.noname/profile3"
> >> xmlns="http://www.w3.org/ns/ttml#parameter">
> >>      <features xml:base="http://www.w3.org/ns/ttml/feature/">
> >>        <feature value="prohibited">#fontStyle-italic</feature>
> >>        <feature value="use">#fontStyle-bold</feature>
> >>      </features>
> >>     <extensions xml:base="http://example.noname/profile1">
> >>         <ttp:extension
> >> value="required">#prefilter-by-language</ttp:extension>
> >>     </ttp:extensions>
> >> </contentprofile>
> >>
> >> > @contentProfile
> >>
> >> What about a list of one or more content profile designator URIs,
> >> each indicating conformance to a content profile, e.g.
> >>
> >> <tt ttp:contentProfile="http://example.noname/profile1
> >> http://example.noname/profile2">
> >>
> >> Best,
> >>
> >> -- Pierre
> >>
> >> On Thu, Jul 11, 2013 at 9:16 AM, Timed Text Working Group Issue
> >> Tracker <sysbot+tracker@w3.org> wrote:
> >> > ISSUE-261: signaling docoument profile conformance is separate from
> >> > decoder presentation requirements [TTML.next]
> >> >
> >> > http://www.w3.org/AudioVideo/TT/tracker/issues/261
> >> >
> >> > Raised by: Mike Dolan
> >> > On product: TTML.next
> >> >
> >> > The profile element and attribute currently signal a feature set
> >> > that a decoder must implement in order to reasonably present the
> >> > document. Although it also hints at what features the document
> >> > instance may include, it does not signal document instance conformance
> today.
> >> >
> >> > There is currently no mechanism to signal what profile a document
> >> > instance conforms to (e.g. sdp-us).
> >> >
> >> > It is desirable to add this capability to TTML. However, simply
> >> > adding this semantic to the existing profile element and attribute
> >> > overly constrains the existing (decoder) and desired (document)
> >> > semantics. It is unreasonable to require that the single element
> >> > and attribute simultaneously signal both. For example, the fact
> >> > that a document instance conforms to dfxp-full does and should not
> >> > automatically infer that an sdp-us decoder could not properly
> >> > present it. That is instance dependent. This situation is aggravated
> when multiple profiles are involved.
> >> >
> >> > Some means must be defined to separately signal these different
> >> > semantics. For example, we could create a new element and attribute
> >> > - <ContentProfile> and contentProfile.
> >> >
> >> >
> >> >
> >> >
> >>
> >
>
> ****
>
> ** **
>