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

On Mon, Jul 15, 2013 at 10:42 AM, Michael Dolan <mdolan@newtbt.com> wrote:

> I assumed a parallel structure to the decoder profile mechanism, but
> perhaps we don’t need it. I don’t feel strongly.****
>
> ** **
>
> But we’ll have to answer the same profile document existence and
> resolvability question we’re discussing in the other thread…
>

yes, it would imply existence, but it doesn't require resolvability in the
same way, that is, unless we define an additional parameter attribute, call
it ttp:contentProfileVerification="none|lax|strict", along with some a
couple of new features #content-verification, #content-verification-lax,
and #content-verification-strict.

just defining a way to reference a content profile doesn't place any
requirement on a processor to verify compliance


> ****
>
> ** **
>
>                 Mike****
>
> ** **
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Monday, July 15, 2013 9:32 AM
> *To:* Michael Dolan
> *Cc:* Timed Text Working Group
>
> *Subject:* Re: ISSUE-261: signaling docoument profile conformance is
> separate from decoder presentation requirements [TTML.next]****
>
> ** **
>
> Not hard to define in XSD:****
>
> ** **
>
> <xs:simpleType name="contentProfiles">****
>
>   <xs:list>****
>
>     <xs:simpleType>****
>
>       <xs:restriction base="xs:anyURI"/>****
>
>     </xs:simpleType>****
>
>   </xs:list>****
>
> </xs:simpleType>****
>
> ** **
>
> ** **
>
> On Mon, Jul 15, 2013 at 8:32 AM, Michael Dolan <mdolan@newtbt.com> wrote:*
> ***
>
> >> we should limit ourselves to defining an attribute only at this point.*
> ***
>
>  ****
>
> The previously stated use case on this list was to be able to signal
> multiple conforming profiles (e.g. SDP-US and CFF-TT-Text.  This was the
> originally stated purpose of the choice of the element mechanism in SDP-US.
> It gets more complex when multiple namespaces are involved. With only an
> attribute, we’d have to create a URI list syntax, which is awkward.****
>
>  ****
>
> Regards,****
>
>  ****
>
>             Mike****
>
>  ****
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Monday, July 15, 2013 6:46 AM
> *To:* Timed Text Working Group
> *Subject:* Re: ISSUE-261: signaling docoument profile conformance is
> separate from decoder presentation requirements [TTML.next]****
>
>  ****
>
>  ****
>
> On Thu, Jul 11, 2013 at 10: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.****
>
>  ****
>
> Unless we identify a good use case for defining a content profile inline,
> then we should limit ourselves to defining an attribute only at this point.
> I would suggest ttp:contentProfile, specified on the tt element (only),
> with a URI value. This is also related to Issue 203 (
> http://www.w3.org/AudioVideo/TT/tracker/issues/203).****
>
> ** **
>