- From: Michael Dolan <mdolan@newtbt.com>
- Date: Fri, 12 Jul 2013 13:55:04 -0700
- To: "'Timed Text Working Group'" <public-tt@w3.org>
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 20:55:41 UTC