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

OK.  But if there is no registry, then the "name" values can collide and
thus isn't useful.

-----Original Message-----
From: Sean Hayes [mailto:Sean.Hayes@microsoft.com] 
Sent: Friday, July 12, 2013 2:33 PM
To: Michael Dolan; 'Timed Text Working Group'
Subject: RE: ISSUE-261: signaling docoument profile conformance is separate
from decoder presentation requirements [TTML.next]

Yes that's what I meant by auth. The short name would be an arbitrary token

-----Original Message-----
From: Michael Dolan [mailto:mdolan@newtbt.com]
Sent: 12 July 2013 21:55
To: 'Timed Text Working Group'
Subject: RE: ISSUE-261: signaling docoument profile conformance is separate
from decoder presentation requirements [TTML.next]

Who will manage the brand token registry?  I like the "brand" idea borrowed
from MPEG, but I think a URI is better - just use the XML schema namespace:

        <ttm:brand profile="http://www.decelle.org/.....cff-tt-text-1.0.6"
/>

-----Original Message-----
From: Sean Hayes [mailto:Sean.Hayes@microsoft.com]
Sent: Friday, July 12, 2013 1:41 PM
To: Pierre-Anthony Lemieux; Glenn Adams
Cc: Timed Text Working Group
Subject: RE: ISSUE-261: signaling docoument profile conformance is separate
from decoder presentation requirements [TTML.next]

In fact I think we would want to actively discourage documents being able to
make up or modify player definitions in the document. I'm not sure we would
in fact even necessarily have a machine readable form for a player profile.

In my mind the best way to handle this would be the definition of a new
metadata element for branding along the lines of the little stickers you get
on consumer equipment and media

<ttm:brand name="short-name" auth="uri" />


So for example:

  <?xml version="1.0" encoding="utf-8"?>
  <tt
   xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
   xml:lang="en" xmlns="http://www.w3.org/ns/ttml"
  >
    <head>
      <metadata>
        <ttm:title>An example to test brand metadata</ttml:title>
        <ttm:brand name="uvvu-tt" auth="http://www.uvvu.com/" />
        <ttm:brand name="sdp-us" auth="http://www.w3.org"/>
        <ttm:brand name="ebu-tt-d" auth="http://www.ebu.ch"/> 
     </metadata>
    </head>
...

  </tt>
    
-----Original Message-----
From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
Sent: 12 July 2013 21:24
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 21:49:08 UTC