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.
> >> >
> >> >
> >> >
> >> >
> >>
> >
>
>
>