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

>> 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).