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