- From: Andreas Tai <tai@irt.de>
- Date: Mon, 15 Jul 2013 14:16:46 +0200
- To: Sean Hayes <Sean.Hayes@microsoft.com>
- CC: Pierre-Anthony Lemieux <pal@sandflow.com>, Michael Dolan <mdolan@newtbt.com>, Timed Text Working Group <public-tt@w3.org>
This additional identifier for a content profile would be very useful. I agree with Pierre that one string would be good. Possibly a construction rule for the URI would be helpful like http:// + domain_of_authority + profile-identifier. To use the XML Schema namespace of the different content profiles as the "identifier" could be problematic. If a profile do not define an extension but just constrain the document model of TTML than the XML schema would not have an extra, non TTML namespace. I like the proposal of Sean to define the element as a child of the /tt:tt/tt:head/tt:metadata. Question is if it has to be defined in the TTML namespace. Possibly a metadata element with the needed semantics is already defined elsewhere? This way it could be used already by TTML 1.0 documents. From my perspective there is an urgent need to integrate this information. Best regards, Andreas Am 13.07.2013 00:04, schrieb Sean Hayes: > 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. >>>>> >>>>> >>>>> >>>>> >> >> >> >> >> -- ------------------------------------------------ Andreas Tai Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR Floriansmuehlstrasse 60, D-80939 Munich, Germany Phone: +49 89 32399-389 | Fax: +49 89 32399-200 http: www.irt.de | Email: tai@irt.de ------------------------------------------------ registration court& managing director: Munich Commercial, RegNo. B 5191 Dr. Klaus Illgner-Fehns ------------------------------------------------
Received on Monday, 15 July 2013 12:18:56 UTC