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

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. The feature granularity is insufficient to
describe any (I think) of the profiles in use today. Minimally there are
certainly profile examples that cannot be (sdp-us and cff-tt). The feature
mechanism cannot be extended by 3rd parties. 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.

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

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