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

Received on Friday, 12 July 2013 20:24:28 UTC