- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Fri, 12 Jul 2013 14:55:43 -0700
- To: Sean Hayes <Sean.Hayes@microsoft.com>
- Cc: Michael Dolan <mdolan@newtbt.com>, Timed Text Working Group <public-tt@w3.org>
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 21:56:32 UTC