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

Just for ease of recognition by humans, im not wedded to it

-----Original Message-----
From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com] 
Sent: 12 July 2013 22:56
To: Sean Hayes
Cc: Michael Dolan; Timed Text Working Group
Subject: Re: ISSUE-261: signaling docoument profile conformance is separate from decoder presentation requirements [TTML.next]

Why not use a single URI instead of URI + token? Just curious.

-- Pierre

On Fri, Jul 12, 2013 at 2:50 PM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> Yes they could, but the uri would disambiguate.
>
> -----Original Message-----
> From: Michael Dolan [mailto:mdolan@newtbt.com]
> Sent: 12 July 2013 22:49
> To: 'Timed Text Working Group'
> Subject: 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 22:05:12 UTC