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

On Tue, Jul 16, 2013 at 6:24 PM, Michael Dolan <mdolan@newtbt.com> wrote:

> Interesting lack of the use of the term “decode” in TTML 1.0 except in
> informative appendices. In those appendices, “decode” can be inferred to
> include the semantic processing and presentation.  Anyway, that’s how I
> meant it.****
>
> ** **
>
> Yes, from previous threads I knew we disagreed on the need/utility of the
> profile document.  I feel less strongly about it than I did having cleared
> up some profile details here where I am convinced that an accurate profile
> document could be created in all cases.  But I still don’t think it is
> universally useful (at least to the point of requiring it always),
> especially where multiple namespaces with required extensions are involved.
> The probability of there being interop between such specialized decoders
> seems very low.  But I can’t quantify “low” without analyzing the available
> content and the known decoder profiles. So perhaps we should drop it, and
> I’ll concede that no harm can come from a properly created profile document
> and perhaps it is good engineering regimen.  I’m not sure how this can be
> enforced, though. Developers are going to have to see the value. Other than
> SDP-US, I’m not aware of another TTML profile that defined a profile
> document.****
>
> ** **
>
> Turning to the final bit of concern is requiring resolution while
> permitting URIs as profile identifiers.  A URI can be a URL or a URN.  The
> common URL schemes are resolvable by most clients - certainly HTTP and
> maybe FTP.  But there are plenty of schemes that the march of web progress
> has left behind (e.g. tried using “gopher:” lately?).  For URNs it is even
> worse since there are no defined resolution mechanisms for URNs in general.
> TTML does not define any common resolution mechanism so it would have to be
> application dependent, which makes it generally unusable across different
> applications of TTML.  So, profile identifiers with much of anything other
> than a URL with the HTTP scheme just can’t be expected to be resolvable by
> the average client. So, I believe we need to either constrain the profile
> identifier to a URL with the http scheme, or we need to not require any
> expectation of resolution.
>

We say (in 5.2 Profiles) the following:

Nothwithstanding this constraint, a profile designator is not restricted to
the set of designators enumerated in *Table 2 –
Profiles*<http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#profile-vocab-table>,
but may be any URI that feasibly dereferences a TTML *Profile Definition
Document* provided it does not use the TT Profile Namespace as a prefix.

and

It is intended that the ttp:profile attribute be used when the author
wishes to reference one of the standard, predefined profiles of TTML
Content, and does not wish to modify (by supersetting or subsetting) that
profile. This attribute may also be used by an author to indicate the use
of a non-standard profile, in which case the specified profile designator
expresses a URI that denotes an externally defined *Profile Definition
Document*. However, it is not required that a conformant TTML Content
processor be able to dereference such an externally specified profile
definition.

So we (1) don't require a URL if a URN can feasibly dereference a profile
definition document (e.g., database lookup, 3rd party mapping from URN to
URL, etc), and (2) don't require this feasibly referenceable profile
document to be dereferenced.

Since we don't define a reference resolving process, I think we don't need
to limit profile designators to URLs.




> ****
>
> ** **
>
> Mostly unrelated to this thread, I think, but regarding: Every TTML
> Processor can (syntactically) decode every TTML document irregardless of
> its profile.  I think this would be news to nearly every developer in the
> industry and I am pretty sure not true in practice. If the above were
> intended, then what purpose is served by forbidding any TTML syntax in a
> document, such as is done in SDP-US 5.2 (picking on tts:color again): “A
> document must not contain a *<color>* expression value used with the
> tts:color attribute that does not conform to the #rrggbbaa expression
> format …”. If the decoder is required to parse all the syntax forms, this
> document constraint has no practical use.
>
When I said syntactically decode, I was too vague. I mean deserialize the
concrete syntax into a TTML Abstract Document Instance as defined by
Section 4 [1]. I did not mean to imply that this included syntactic
decoding of attribute values or element #PCDATA content.

[1] http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#doctypes

>
We don't define the term 'decode', and only use it in the informative
Appendix L on streaming.

If we were to define and use 'decode' in a normative way, we would have to
consider a number of potential processes to include under this term:

(1) first order syntax parsing, i.e., deserializing concrete syntax (XML)
into reduced infoset;

(2) second order syntax parsing, e.g., syntactically parsing attribute and
certain element #PCDATA content, such as the values of tts:color;

(3) interpreting the semantics of parsed element structure and attribute
values, e.g., determining that tts:extent='-5px -10px' is not valid or that
tts:fontFamily='FooBar' is valid but not supported (on my device);

I've been using 'decode' to refer to (1), but you appear to at least
include (2) and maybe (3). I do believe that (1) should be supported by all
compliant TTML processors. Whether a processor can syntactically parse a
new attribute to be supported by Processor B, say ext:myPrivateAttribute,
as defined by extension designation
http://example.com/ns/ttml/extension/#my-private-attribute, which is used
in a TT Profile Definition Document is another matter.

If Processor A encounters a TTML Document that references a profile
document (or defines it inline) so as to require support for this extension
feature, then Processor A should nominally reject the document (unless
overridden) since it doesn't know this extension. However, Processor A
should still be able to process documents intended for Processor B, and
ignore features that it doesn't support (whether because the profile
document calls them optional, or because the profile document calls them
required and abort is overridden or the document itself overrides required
with optional).



****
>
> ** **
>
> Regards,****
>
> ** **
>
>                 Mike****
>
> ** **
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Tuesday, July 16, 2013 4:06 PM
> *To:* Michael Dolan
> *Cc:* Timed Text Working Group
> *Subject:* Re: profile definition and resolution [was RE: ISSUE-261:
> signaling docoument profile conformance is separate from decoder
> presentation requirements [TTML.next]****
>
> ** **
>
> ** **
>
> On Tue, Jul 16, 2013 at 3:09 PM, Michael Dolan <mdolan@newtbt.com> wrote:*
> ***
>
> Modulo my imprecise terminology, I think we’re finally saying the same
> thing about the semantics of profile features and when extensions are
> required, even if the intended feature is a strict subset of dfxp-full.***
> *
>
>  ****
>
> I defer to Sean what the intent in SDP-US is.  It makes no difference to
> me.  But it is a safe bet that the average developer would not come to the
> conclusion that the profile specification in Section 9 is the authoritative
> feature specification for the decoder. So, SDP-US needs some clarification
> I think.  #color was just an example.****
>
>  ****
>
> Now that we’ve eliminated the blocking problem of how to define features
> precisely in the profile document, let’s return to the other 2 original
> points in this thread:****
>
>  ****
>
> 1.       If an instance document uses <profile> (or the attribute), does
> there have to be a TTML profile document defined or is prose sufficient?**
> **
>
> My position is that there must be a defined profile document. It doesn't
> serve to create a prose description of a profile without formally
> identifying or labeling some or all *features* (in a generic sense)
> intended to be supported by the profile. The process of identifying or
> labeling those features provides a means to create a TT Profile Definition
> Document.****
>
>  ****
>
> 2.       And if a profile document is required, then does the profile URI
> have to be resolvable to such a document?****
>
> My position is that it has to be feasibly resolvable. Meaning that it
> should live on the Web and have a permanent URI that would allow an HTTP
> client to obtain the resource using a GET request.****
>
> ** **
>
> Neither of these seem onerous requirements, and I am rather surprised to
> see suggestions that they should not be required. After all, what is the
> barrier to satisfying these requirements?****
>
>  ****
>
>  ****
>
> Rather than debate the meaning of the text in the TTML spec, let’s jump to
> what we **should** do.  It’s my view that a profile URI tied to a prose
> document is sufficient in some cases, an actual profile document should not
> be universally required, and thus #2 is not relevant.****
>
> ** **
>
> Our positions differ. I don't see any reason a profile definer shouldn't
> satisfy the requirement to provide a referencable document.****
>
>  ****
>
>  ****
>
> If all TTML decoder profiles were made up strictly of the features defined
> in TTML 1.0, then I definitely see the value in requiring a profile
> document and a decoder being able to automatically acquire it (both 1 and
> 2). This enables the case that a profile A decoder, entirely unaware a
> priori of profile B could in fact “learn” that it could (or not) properly
> decode a profile B document. This is cool.****
>
>  ****
>
> But this breaks down to an edge case when using required extensions.  A
> profile A decoder not a priori aware of profile B extensions would have no
> idea how to decode a profile B document.****
>
> ** **
>
> Could you outline a scenario where this might be true? Given the generic
> requirements on TTML Abstract Document Types [1], and the generic
> requirement on TTML Content Processors [2], I can't see how any conforming
> process would fail to decode a conforming document. But perhaps you mean
> something more by *decode* than I do.****
>
> ** **
>
> By decode, I usually think of syntactic parsing only, and not semantic
> interpretation. Given a TTML document deserialized into a Reduced XML
> Infoset (a generic requirement of every TTML content processor), then I
> don't really see an issue with syntactic parsing. TTML as a spec assumes
> that the decoder has managed somehow to deserialize some input into a
> Reduced XML Infoset, and everything else is defined with this assumption in
> mind. ****
>
> ** **
>
> [1] http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#doctypes****
>
> [2]
> http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#conformance-generic-processor
> ****
>
> ** **
>
> And, acquiring a profile document with undefined (to it) extensions isn’t
> going to help.  Only in the case where the decoder was a priori aware of
> the signaled profile would it be able to decode the document, and then it
> doesn’t need the profile document itself. It implicitly knows the profile
> from the URI.****
>
> Not by my understanding. Every TTML Processor can (syntactically) decode
> every TTML document irregardless of its profile.****
>
>  ****
>
>  ****
>
> I think the text that strongly infers (if not requires, depending on one’s
> reading) both a profile document and its resolution should be softened, at
> least for the case where there are required extensions defined.****
>
> I don't see this.****
>
>  ****
>
>  ****
>
> If we converge on #1, then I’ll continue with why we still can’t today do
> #2 without more spec writing.****
>
>  ****
>
> Regards,****
>
>  ****
>
>                 Mike****
>
>  ****
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Tuesday, July 16, 2013 12:37 PM
> *To:* Michael Dolan
> *Cc:* Timed Text Working Group
> *Subject:* Re: profile definition and resolution [was RE: ISSUE-261:
> signaling docoument profile conformance is separate from decoder
> presentation requirements [TTML.next]****
>
>  ****
>
>  ****
>
> On Tue, Jul 16, 2013 at 12:10 PM, Michael Dolan <mdolan@newtbt.com> wrote:
> ****
>
> It is rather clear to me that conformant SDP-US decoders are not required
> to implement any tts:color syntax other than what is defined in 5.2.****
>
>  ****
>
> That would be an incorrect interpretation of the current SDP-US spec,
> since it clearly requires a conforming decoder to support #color as defined
> in TTML.****
>
>  ****
>
> The rationale, as I mentioned below, is that if it is required to support
> the full syntax then there would be no point at all in prohibiting all the
> other syntax in the instance documents. Therefore a conformant decoder does
> not have to support all syntax.****
>
>  ****
>
> That may have been the intention, but it isn't what is written. To fix it,
> we would need to change the TT Profile document in Section 9 or alter the
> conformance language in Section 3.****
>
>  ****
>
> Therefore the profile requiring support for the feature
> …ttml/feature#color is an error in the profile.****
>
>  ****
>
> That's a possible reading, depending on your assumptions about the
> intentions.****
>
>  ****
>
>  ****
>
> However, debating the perhaps arguable language in SDP-US is not really
> the point of this thread.  The point is that there exist features in
> profiles of TTML that cannot be properly represented by the set of features
> defined in TTML.****
>
>  ****
>
> Let's distinguish *features* from *feature designations*., where *features
> * is a general concept and *feature designations* are the designations
> and semantics defined in TTML 1.0 Appendix D. So, what you are really
> saying is:****
>
>  ****
>
> there exist *features* in profiles of TTML that do not have corresponding
> *feature designators* defined in TTML****
>
>  ****
>
> And, for this, I agree. ****
>
> And in those cases, using such a TTML feature in the profile definition is
> just wrong since such a constrained decoder would be required to reject
> such a document requiring full support.****
>
> "Just wrong" depends on the intentions of the authors. If it were the
> intentions of the authors of SDP-US that a conforming presentation
> processor (decoder) require no more than necessary to support the *
> features* of a conforming SDP-US document, then I would agree. However, I
> can't answer this question, since I came along rather late in the editing
> process, and Section 9 had already been established (though subsequently
> fine tuned).****
>
>  ****
>
> I don't recall the issue of the present thread coming up while we were
> editing/discussing SDP-US, so I don't have a recollection of intentions in
> this area.****
>
>  ****
>
> If we wish, we can simple declare that the intentions were different, and
> set about to changing it.****
>
>  ****
>
> However, the solution is to redefine the feature as an extension in a new
> profile namespace subject to however the feature is really intended and
> defined by the controlling prose.  And, if the new definition is a strict
> subset of TTML, then the schema and documents of such a constrained profile
> can still use the TTML document namespace.****
>
> To be more particular about terminology, I believe you are suggesting that
> we:****
>
>  ****
>
> (1) define new extension designations in SDP-US, along with their semantic
> descriptions, as needed to redefine Section 9 to better match processor
> requirements to content usage;****
>
> (2) revise (replace) Section 9 to use these new extension designations;***
> *
>
>  ****
>
> I've also mentioned an alternative, which is to revise Section 3, and
> continue to use the same contents of Section 9. The latter would require
> less normative spec work and would better interoperate with fielded
> decoders (that should know the feature designations already defined but
> won't know new feature designations you propose). I have a slight
> preference for my approach because it simplifies editing work.****
>
>  ****
>
>  ****
>
> Alternatively, I suppose we could create a dependency of the feature
> definitions on the profile itself.  That is, e.g. …ttml/feature#color means
> one thing for the dfxp-presentation profile and another thing for the
> sdp-us profile. But I don’t think that was the intent.****
>
> Barring errata, the definition of a given (fully specified, absolute)
> feature designation should not change according to context.****
>
>  ****
>
>  ****
>
> And, it is now clear that SDP-US needs to either alter its profile along
> the lines of this thread (if my interpretation is correct), or it needs to
> alter the prose throughout to require support for the full syntax and
> require decoder semantics consistent with the TTML features that it claims
> are required (if your interpretation is correct). My money is on the former.
> ****
>
> My interpretation is correct according to what is written, but yours may
> be correct according to what was intended. It is a moot argument. Best to
> simply propose and adopt changes that fix what folks don't like. ****
>
>  ****
>
> Regards,****
>
>  ****
>
>                 Mike****
>
>  ****
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Monday, July 15, 2013 7:17 PM
> *To:* Michael Dolan
> *Cc:* Timed Text Working Group
> *Subject:* Re: profile definition and resolution [was RE: ISSUE-261:
> signaling docoument profile conformance is separate from decoder
> presentation requirements [TTML.next]****
>
>  ****
>
>  ****
>
> On Mon, Jul 15, 2013 at 6:46 PM, Michael Dolan <mdolan@newtbt.com> wrote:*
> ***
>
> Glenn-****
>
>  ****
>
> One thing that helps is the clarification that the profile namespace is
> not necessarily bound to the document namespace. ****
>
>  ****
>
> That's saying too much. The correct statement is that the profile
> namespace and the document namespace have nothing to do with each other.**
> **
>
>  ****
>
> And, therefore, SDP-US could define a new feature, e.g. #color, however it
> wishes in its own profile namespace, even though the **document**
> namespace remains ttml. Maybe that solves the problem.****
>
>  ****
>
> Actually, what you suggest below is not using "its own *profile namespace*",
> it is using an "*other extension namespace*" in order to define a new
> (and different) extension designation:****
>
>  ****
>
> http://www.w3.org/ns/sdp-us/feature/#color****
>
>  ****
>
> which is distinct from****
>
>  ****
>
> http://www.w3.org/ns/ttml/feature/#color****
>
>  ****
>
> Though perhaps a bit unusual to use a URI containing 'feature' to refer to
> an 'extension', it is perfectly legal for TTML.****
>
>  ****
>
> Profile namespaces are used in profile designators, while
> feature/extension namespaces are used in feature/namespace designations.**
> **
>
>  But I still can’t resolve what all you say below about how features work
> with the statement that the SDP-US profile is accurate as is.****
>
> I say this because SDP-US is not just the profile document defined in
> Section 9 [1], but also all of the normative language that comes before,
> e.g.,****
>
>  ****
>
> *R0013* - A document *must not* contain a *<color>* expression value used
> with the tts:color attribute that does not conform to the #rrggbbaa expression
> format as defined by [TTML10<http://www.w3.org/TR/2013/NOTE-ttml10-sdp-us-20130205/#bib-TTML10>],
> Section 8.3.2.****
>
>  ****
>
> By this statement, a conforming SDP-US document cannot use any (TTML)
> #color syntax that is not of the form #rrggbbaa. This statement is not
> expressible in TTML 1.0 profile vocabulary as presently defined, though
> with the new 'prohibited' value keyword we have introduced in 1.1, and in
> combination with new, not yet defined standard #feature designations (e.g.,
> #color-rgb-function, #color-rgba-function, #color-rrggbb), such a
> constraint could be expressed.****
>
> Since SDP-US is designed explicitly **not** to support the full tts:color
> syntax, then including the feature #color from the TTML profile namespace
> is clearly an error.****
>
> It's not an error, its just (potentially) misleading (clearly so since you
> have misinterpreted it). It says (1) a processor must support all of the
> #color syntax, *and* (2) a document must not use any syntax other than
> #rrggbb). So it effectively demands a processor to support more than it
> would need to support only conformant SDP-US documents. Perhaps that could
> be interpreted as an error, but strictly speaking, Section 3 says:****
>
>  ****
>
> This profile defines (1) constraints on documents and (2) minimum
> requirements for a TTML presentation processor capable of presenting such
> constrained documents.****
>
>  ****
>
> But *does not say* that (1) and (2) are equal. It only says that (2) is
> capable of presenting (1). Which is true. The definition of (2) *and not
> (1)* is based on the TT Profile document in Section 9:****
>
> A TTML presentation processor conforms to this profile if it:****
>
> 1.   implements support for the profile definition specified in Features
> in TTML 1.0 Used in This Profile<http://www.w3.org/TR/2013/NOTE-ttml10-sdp-us-20130205/#Features_in_TTML_1.0_Used>;
> and****
>
> 2.   implements support for all other semantics explicitly defined by
> this profile.****
>
> A decoder would not be able to disambiguate TTML #color from what was
> really defined/implemented.****
>
> Keep in mind that designation fragments, like *#color*, are only relative
> URIs, based on the applicable base URI. There are two different URIs you
> cite here when writing them in their full, absolute form:****
>
>  ****
>
> http://www.w3.org/ns/ttml/feature/#color****
>
> http://www.w3.org/ns/sdp-us/feature/#color****
>
>  ****
>
> If we were to define the latter in a revised version of SDP-US, in order
> to bring the definition of required processor support closer to the
> definition of a conforming document, then I would suggest using something
> like:****
>
>  ****
>
> http://www.w3.org/ns/ttml/sdp-us/extension/#color-rrggbbaa****
>
> We might also want to add new standard feature designations in TTML.next:*
> ***
>
>  ****
>
> http://www.w3.org/ns/ttml/feature/#color-rrggbb****
>
> http://www.w3.org/ns/ttml/feature/#color-rrggbbaa****
>
> ...****
>
>  ****
>
> Dealing only with tts:color (and not the other constrained features),
> doesn’t the SDP-US profile have to be modified along the lines of:****
>
>  ****
>
> <?xml version="1.0" encoding="utf-8"?>****
>
> <profile xmlns="http://www.w3.org/ns/ttml#parameter">****
>
>   <features xml:base="http://www.w3.org/ns/ttml/feature/">****
>
>     <!-- required (mandatory) feature support -->****
>
>     <feature value="required">#animation</feature>****
>
>     <feature value="required">#backgroundColor-block</feature>****
>
>     <feature value="required">#backgroundColor-inline</feature>****
>
>     <feature value="required">#color</feature>****
>
>     <feature value="required">#content</feature>****
>
>     <feature value="required">#core</feature>****
>
>     <feature value="required">#display-region</feature>****
>
>     <feature value="required">#displayAlign</feature>****
>
>     <feature value="required">#extent-region</feature>****
>
>     <feature value="required">#fontFamily-generic</feature>****
>
>     <feature value="required">#fontSize</feature>****
>
>     <feature value="required">#fontStyle-italic</feature>****
>
>     <feature value="required">#frameRate</feature>****
>
>     <feature value="required">#frameRateMultiplier</feature>****
>
>     <feature value="required">#layout</feature>****
>
>     <feature value="required">#length-percentage</feature>****
>
>     <feature value="required">#length-positive</feature>****
>
>     <feature value="required">#lineBreak-uax14</feature>****
>
>     <feature value="required">#presentation</feature>****
>
>     <feature value="required">#profile</feature>****
>
>     <feature value="required">#structure</feature>****
>
>     <feature value="required">#styling</feature>****
>
>     <feature value="required">#styling-inheritance-content</feature>****
>
>     <feature value="required">#styling-inheritance-region</feature>****
>
>     <feature value="required">#styling-inline</feature>****
>
>     <feature value="required">#styling-referential</feature>****
>
>     <feature value="required">#textAlign-absolute</feature>****
>
>     <feature value="required">#textDecoration-under</feature>****
>
>     <feature value="required">#textOutline-unblurred</feature>****
>
>     <feature value="required">#time-offset</feature>****
>
>     <feature value="required">#timing</feature>****
>
>     <feature value="required">#writingMode-horizontal-lr</feature>****
>
>   </features>****
>
>   <extensions xml:base="http://www.w3.org/ns/sdp-us/feature/">****
>
>     <extension value="required">#color</extension>****
>
>   </extensions>****
>
> </profile>****
>
>  ****
>
> We could do this, but IMO, it wouldn't be because the current definition
> is broken, it would be because we might want a definition of SDP-US
> processor support that more closely aligns with SDP-US content
> possibilities. ****
>
> SDP-US would then need to formally state that the extension #color is the
> definition in 5.2.****
>
> Yes, if we defined a new extension designation, we could define it in a
> way that matches the document constraints more closely. ****
>
>  ****
>
> The same would therefore be true for any SDP-US constrained features that
> have syntax or semantics constrained beyond the minimum defined in any TTML
> feature.****
>
> Yes, we could do that as well. But it isn't logically necessary to do so.
> We could also rewrite step (1) under processor conformance in Section 3 to
> read something like:****
>
>  ****
>
> (1) implements support for the profile definition specified in Features in
> TTML 1.0 Used in This Profile where the use and presence of such features
> is to be understood to be further constrained by statements in this profile
> that apply to document conformance;****
>
>  ****
>
> and further add the following Notes (or normative text):****
>
>  ****
>
> Note: When processing the semantics of a TTML 1.0 document that claims to
> make use of or otherwise conform with this (SDP-US) profile, a conforming
> presentation processor should not reject or otherwise abort processing a
> document that merely refers (directly or indirectly) to a standard TTML
> feature designation whose definition includes semantics not permitted by a
> conforming SDP-US document.****
>
>  ****
>
> Note: If a TTML 1.0 document that claims to make use of or otherwise
> conform with this (SDP-US) profile makes use of a standard TTML feature or
> some aspect of such a feature that is expressly prohibited by this profile,
> then a compliant presentation processor should ignore the construct that
> includes the prohibited feature or feature aspect.****
>
>  ****
>
>  ****
>
> SDP-US retains the TTML **document** namespace since it is still a strict
> subset.****
>
> Yes, but this is unrelated to the above discussion. We wouldn't be
> redefining TT vocabulary in a new SDP-US XML namespace.****
>
>  ****
>
>  ****
>
> If you still maintain that the profile for SDP-US is accurate as is, then
> I guess we need to talk more….****
>
>  ****
>
> Regards,****
>
>  ****
>
>                 Mike****
>
>  ****
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Monday, July 15, 2013 5:01 PM
> *To:* Michael Dolan
> *Cc:* Timed Text Working Group
> *Subject:* Re: profile definition and resolution [was RE: ISSUE-261:
> signaling docoument profile conformance is separate from decoder
> presentation requirements [TTML.next]****
>
>  ****
>
>  ****
>
> On Mon, Jul 15, 2013 at 12:19 PM, Michael Dolan <mdolan@newtbt.com> wrote:
> ****
>
> CIL.****
>
>  ****
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Monday, July 15, 2013 9:57 AM****
>
>
> *To:* Michael Dolan
> *Cc:* Timed Text Working Group****
>
> *Subject:* Re: profile definition and resolution [was RE: ISSUE-261:
> signaling docoument profile conformance is separate from decoder
> presentation requirements [TTML.next]****
>
>  ****
>
>  ****
>
> On Mon, Jul 15, 2013 at 9:48 AM, Michael Dolan <mdolan@newtbt.com> wrote:*
> ***
>
> Glenn-****
>
>  ****
>
> The reason that I think a profile document itself is an inadequate tool to
> define a profile is that the granularity of the features has never (to
> date) matched the defined profile capabilities per the related prose for
> those profiles. ****
>
>  ****
>
> But the purpose of the TT Profile Document is not to define a profile. It
> is to specify a set of features/extensions having been defined elsewhere.
> You are talking about the "defined elsewhere" part of this equation, i.e.,
> which features/extensions are defined, whether their definitions are
> adequate or not.****
>
>  ****
>
> The implied contract for a TT Profile Document is that it simply
> enumerates features/extensions and assigns each a value (required,
> optional, etc), and that a TTML Content Processor has a way (or can have a
> way) to determine if it supports an enumerated feature.****
>
>  ****
>
> When a TT document references a feasibly resolvable TT Profile Document,
> it is simply using a shorthand, which it could instead of defined inline,
> i.e., enumerated the features it requires inline.****
>
>  ****
>
> When a processor encounters such a reference it has some options:****
>
>  ****
>
> (1) it has a built-in (cached) form of the referenced profile, so doesn't
> need to make an external reference (though it may choose to do so to update
> its cache);****
>
>  ****
>
> (2) it doesn't have a cached form or it wants to update its cache, so it
> attempts to resolve and parse the referenced profile, which may succeed or
> fail;****
>
>  ****
>
> (3) if (2) fails, then it consults its system/user preferences to
> determine whether to continue processing or abort the document;****
>
>  ****
>
> If the processor did resolve the profile to a TT Profile Document, then it
> knows which features it supports and which it doesn't, at least for those
> defined at the time it was constructed/updated. If the TT Profile Document
> (as parsed and possibly augmented by inline profile elements) requires a
> feature it doesn't support, then it again consults its preferences, and
> either continues or aborts.****
>
>  ****
>
> MD>> Yes.  Understand all this. The above and its process is not in
> debate. The summary of my chain of logic:****
>
>  ****
>
> 1.         The TTML feature list is not granular enough to be accurate
> relative to the known profiles today.****
>
>  ****
>
> So, define new features (in W3C) or externally (in which case they are
> called 'extensions').****
>
>  ****
>
> 2.         Therefore, an actual profile document is not useful (in fact
> harmful in all known cases – see below).****
>
>  ****
>
> Yes it is. It is a formal mapping from a URI to a list of requirement
> specifications. It can be parsed. It can be cached. It can be referred to
> normatively to define what is required to process a document. I fail to see
> why this isn't useful, especially since it is what we intended it to do.
> Recall that the entire TTML Profile mechanism was defined as a way to
> express the kind of information expressed by SVG's requiredFeatures [1]
> requiredExtensions [2] attributes, and SMIL's system test attributes [3].*
> ***
>
>  ****
>
> [1]
> http://www.w3.org/TR/SVG/struct.html#ConditionalProcessingRequiredFeaturesAttribute
> ****
>
> [2]
> http://www.w3.org/TR/SVG/struct.html#ConditionalProcessingRequiredExtensionsAttribute
> ****
>
> [3]
> http://www.w3.org/TR/SMIL2/smil-content.html#ContentControlNS-PredefinedSystemTest
> ****
>
>  ****
>
> You are faulting the mechanism when it is the policy of its usage that is
> the problem.****
>
>  ****
>
> 3.         Therefore, if there is no profile document it does not need to
> be resolvable.****
>
> A profile always applies whether specified or not. Absent a profile
> reference, the dfxp-transformation profile applies. There should always be
> a TT Profile Document for every defined profile. I would say that a claim
> that a profile is defined without a TT Profile Document is a non-sequitor
> as far as TTML is concerned.****
>
> Without explicit restriction, a feature must be assumed to be fully
> supported.****
>
> Features (and extensions) are defined by the W3C (and 3rd parties)
> respectively. Their definitions must adequately specify what 'support'
> means, elsewise they are underspecified.****
>
>  ****
>
> The TT profile document says what the processor is to do if it isn't
> supported and its value is 'required' or 'used'. It is up the processor to
> determine if it supports the feature or not according to wherever the
> feature is defined. In  the present TTML profiles, that is Appendix D or
> SDP-US.****
>
>  ****
>
> MD>>  If the decoder must fall back on prose to understand the true
> meaning, then how is a profile document helpful? The feature definition
> must be detailed enough to cover the constraint set, and today they are not.
>  ****
>
>  ****
>
> For example, let’s use tts:color.  SDP-US constrains the color
> representations in ways that are not covered in the TTML profile feature,
> #color. The granularity of this feature in TTML is all or nothing.
> Therefore, if an SDP-US (only) decoder were to receive a profile (URI or
> inline) that contained the #color feature, it would be forced to reject the
> instance document since the decoder does not support all the
> representations.****
>
>  ****
>
> That's correct, at least in the sense that the syntactic representations
> of color supported in TTML must be supported; however, it doesn't mean the
> semantic meaning must be supported [1]:****
>
>  ****
>
> A TTML presentation processor supports the #color feature if it (1)
> implements presentation semantic support for the tts:color<http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#style-attribute-color> attribute
> and (2) is capable of displaying or generating an output display signal
> that distinguishes between at least sixteen (16) values of color, including
> all primary and secondary colors of the SRGB color space.****
>
>  ****
>
> [1] http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#feature-color****
>
>  ****
>
> MD>> Right.  But this is all irrelevant if the decoder can’t even decode
> all the syntax requried by #color.****
>
>  ****
>
> In that case, it can't claim to support #color. So if you are asking what
> to do if you want to define a profile that doesn't define all of the syntax
> of #color, then you need to define an extension designator and specify its
> meaning somewhere in prose. The designator is just a shorthand for that
> meaning, wherever it is defined. It is not the purpose of the TT Profile
> Document to define the meaning of feature or extension designators.****
>
>  ****
>
>  ****
>
> Furthermore, even if the processor didn't support these semantics, the
> author could simply override the feature requirement by making it optional:
> ****
>
>  ****
>
> <profile use="dfxp-presentation">****
>
>   <features>****
>
>     <feature value="optional">#color</feature>****
>
>   </features>****
>
> </profile>****
>
>  ****
>
> MD>>  Of course, but then what’s’ the point of a profile document if every
> feature that is constrained in a manner not covered by the TTML feature set
> now has to be optional? That’s at odds with the purpose of communicating
> the feature set to the decoder. They’re not optional, they’re required,
> just constrained.****
>
>  ****
>
> A constrained feature/extension as you put it will need to have its own
> feature/extension designator defined if it is to be referred to be a
> profile.****
>
>  ****
>
> The extension mechanism cannot, at least as I read the spec, be applied to
> TTML features, only 3rd party features – that is, extensions to TTML, not
> TTML itself. And, 3rd parties are prohibited from defining new features
> in the TTML namespaces.****
>
> Why is this a problem? Extensions are just an alias for "non-standard
> features". Any 3rd party, or even the W3C itself is free to define new
> extension URIs which may be referenced by TT Profile documents or by TTML
> documents. If the TTWG wants to formally standardize on an extension, i.e.,
> promote it to a "standard feature", then it just defines such a feature in
> some document.****
>
>  ****
>
> MD>>  I said below (highlight new): “The feature mechanism cannot be
> extended by 3rd parties.”  Then you asked: “…since a non-standard
> "feature" is just what we call an "extension". Or do you have something
> else in mind by "extended"?”  I tried to answer your question as “no”.
> Extensions don’t seem to solve this (but read on).****
>
>  ****
>
> Since it is common practice today is to define profiles with features
> constrained in ways not pre-defined in TTML 1.0, how is it possible to
> create a useful profile document? Perhaps I am missing something about the
> profile/feature/extension mechanism?****
>
> (1) third parties can define new extension URIs along with some definition
> thereof;****
>
> (2) authors of TT Profile documents can include references to such
> extensions;****
>
> (3) authors of TTML documents can reference predefined TT Profile
> documents and can at their discretion augment or restrict those definitions
> by specifying feature/extension references inline (as in above example);**
> **
>
>  ****
>
> MD>> So, are you saying that 3rd parties (including W3C Notes) can define
> a new profile namespace, then define a new feature constraint, e.g.
> #color-sdp-us, to constrain an existing TTML feature?****
>
>  ****
>
> Sure. Why not, that is the current mechanism's design after all?****
>
>  ****
>
> First, we must distinguish between *Profile Designators* [4], *Feature
> Designations* [5], and *Extension Designations* [6], all of which take
> the syntactic form of a URI.****
>
>  ****
>
> [4] http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#vocabulary-profiles
> ****
>
> [5]
> http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#feature-designations***
> *
>
> [6]
> http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#extension-designations*
> ***
>
>  ****
>
> Each of these designators/designations are divided into a *namespace* part
> and a *designation* part. For profile designators, we enumerate 4 (of an
> infinite set) in Table 2 [7].****
>
>  ****
>
> [7] http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#profile-vocab-table
> ****
>
>  ****
>
> The TT Profile namespace part we define in Table 1 [8] as
> http://www.w3.org/ns/ttml/profile/. We set aside this part (as a URI
> prefix) for standardization purposes for the W3C. However, we allow any
> other URI to use with a different namespace part (prefix):****
>
>  ****
>
> All profile designators which have the TT Profile Namespace as a prefix
> but are otherwise not listed in *Table 2 – Profiles*<http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#profile-vocab-table> are
> reserved for future standardization, and must not be appear in a conformant
> *Document Instance*. Nothwithstanding this constraint, a profile
> designator is not restricted to the set of designators enumerated in *Table
> 2 – Profiles*<http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#profile-vocab-table>,
> but may be any URI that feasibly dereferences a TTML *Profile Definition
> Document* provided it does not use the TT Profile Namespace as a prefix.**
> **
>
>  ****
>
> So you or anyone else may go define a TT Profile Document and refer to it
> using a URI of your choice as long as it doesn't use the TT Profile
> Namespace.****
>
>  ****
>
> Now, as for features and extension designations (we use the term
> 'designation' instead of 'designator' to make note of the fact that they
> take a slightly different form, i.e., with a fragment identifier), each of
> these are also uniquely identified with a URI. We state [5] that all
> 'feature' designations *must* use the unique prefix we define as the TT
> Feature Namespace http://www.w3.org/ns/ttml/feature/. However, for
> 'extension' designations, we state [6] that either the TT Extension
> Namespace http://www.w3.org/ns/ttml/extension/ or an *Other Extension
> Namespace* may be used. It is up to a 3rd party to decide what to use as
> an Other Extension Namespace. We give an example of such in an Example
> Fragment [8], namely http://example.org/ttml/extension/.****
>
>  ****
>
> [8]
> http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#parameter-vocabulary-extension
> ****
>
>  ****
>
> Nowhere do we constrain what an extension 'means', so it could mean the
> same as an existing defined 'feature', an extended form of an existing
> defined 'feature', a constrained (restricted) form of an existing defined
> feature, or a completely unrelated, non-standard feature (such as the
> #prefilter-by-language designator in the example fragment [8]).****
>
>  ****
>
> So a third party can define any of:****
>
>    - new profiles labelled and  referenced by new non-standard (from the
>    TTML sense) profile designators;****
>    - new extensions (= non-standard features) labelled and referenced by
>    new non-standard (from the TTML sense) extension designations;****
>
> A content author can then reference any combination of standard and
> non-standard profiles and also define inline profile extensions
> (supersets)/restrictions (subsets) by directly referring to both standard
> feature designations and non-standard extension designations.****
>
>  ****
>
> If so, then can there be a namespace for the profile that is different
> from the namespace of the document (many of the profiles do not define a
> new namespace for the TTML subset)?****
>
>  ****
>
> I'm not sure what you mean by "namespace of the document". But the
> namespaces for profiles are unrelated to namespaces for
> elements/attributes. So it sounds like the answer is YES. ****
>
>  ****
>
> But if we can’t make a useful profile document, there is little point in
> requiring the URI for it to be resolvable to a physical document.****
>
> You can make a useful profile document. I'm not getting why you think that
> is hard or impossible. Perhaps if you give me a more concrete example of
> what you would like to do, I can explain how to do it with the current
> mechanisms.****
>
>  ****
>
> MD>> I don’t see how yet.  See above.  I thought I was helping by using
> SDP-US and #color and the problem was obvious.  If the profile defined in
> Section 9 of SDP-US were sent to a decoder, and the decoder did not support
> all the syntax of tts:color (the strong implication is that it does not -
> see 5.2), then the decoder MUST reject the document.  You say above: “…
> the syntactic representations of color supported in TTML must be supported
> ”****
>
>  ****
>
> Since SDP-US requires support for #color, which means syntactic support
> for all TTML colors, then the decoder you describe above is not an SDP-US
> decoder. If you are just asking about an arbitrary decoder that makes no
> claims about conforming to a processor profile, then yes, a decoder that
> didn't support all the syntax of #color would have to make a decision about
> whether to reject the document or not. However, it need not reject the
> document:****
>
>  ****
>
> *6.1.1 ttp:profile*****
>
>  ****
>
> A conformant TTML processor is not required to be able to dereference a *Profile
> Definition Document* that is not one of the standard, predefined profiles
> defined by *F Profiles*<http://www.w3.org/TR/2013/PER-ttaf1-dfxp-20130709/#profiles>.
> Furthermore, a conformant TTML processor may make use of a built-in, static
> form of each standard, predefined profile so as not to require
> dereferencing a network resource.****
>
> If a TTML processor is unable to dereference a non-standard *Profile
> Definition Document*, then it must not further process the document
> without the presence of an explicit override from an end-user or some
> implementation specific parameter traceable to an end-user or to a user or
> system configuration setting. If a TTML processor aborts processing of a *Document
> Instance* due to the inability to reference a non-standard *Profile
> Definition Document*, then some end-user notification should be given
> unless the end-user or system has disabled such a notification, or if the
> processor does not permit or entail the intervention of an end-user.****
>
> *6.1.3 ttp:feature*****
>
>  ****
>
> If the value of the value attribute is required or use and the TTML
> processor implementation does not support the feature, or if the value attribute
> is use and the TTML processor implementation supports but has disabled
> that feature, then it must not further process the document without the
> presence of an explicit override from an end-user or some implementation
> specific parameter traceable to an end-user or to a user or system
> configuration setting. If a TTML processor aborts processing of a *Document
> Instance* due to the specification of a required, but unsupported feature
> by this element, then some end-user notification should be given unless the
> end-user or system has disabled such a notification, or if the processor
> does not permit or entail the intervention of an end-user.****
>
>  ****
>
> *6.1.5 ttp:extension*****
>
>  ****
>
> If the value of the value attribute is required or use and the TTML
> processor implementation does not support the extension, or if the value attribute
> is use and the TTML processor implementation supports but has disabled
> that extension, then it must not further process the document without the
> presence of an explicit override from an end-user or some implementation
> specific parameter traceable to an end-user or to a user or system
> configuration setting. If a TTML processor aborts processing of a *Document
> Instance* due to the specification of a required, but unsupported
> extension by this element, then some end-user notification should be given
> unless the end-user or system has disabled such a notification, or if the
> processor does not permit or entail the intervention of an end-user.****
>
>  ****
>
> So, a compliant processor (1) need not dereference a feasibly resolvable
> profile document, (2) need not reject a document that requires a feature it
> doesn't support, and (3) need not reject a document that requires an
> extension it doesn't support. However, in each of these cases, the
> processor must make use of a traceable end-user or system parameter to
> determine whether to proceed regardless of lack of support.****
>
>  ****
>
>  ****
>
> MD>> I think can safely say that a developer reading the SDP-US spec would
> not think to support the full syntax of tts:color.  Or if that support is
> somehow implied then what’s the point in forbidding the document syntax?**
> **
>
> We had to define SDP-US using the tools given, or would have had to resort
> to defining new extension designations, which was a possibility.****
>
>  ****
>
> In any case, it is one thing to require syntactic support and quite
> another to require semantic support. A lint type verifier (TTV supports a
> number of optional warnings) would probably want to flag a document that
> makes syntactic use of a feature for which semantic support isn't required.
> ****
>
>  ****
>
> So, we can perhaps reach faster closure on this thread if you could (I
> don’t know how to) define a decoder profile document that:****
>
>  ****
>
> 1.       Accurately represents the SDP-US profile;****
>
>  ****
>
> We have. It is a WG Note called SDP-US. That's it.****
>
> 2.       Accurately uses “required” and “optional” (hint: #color is
> obviously required by FCC regs); and****
>
> Is there a bug in SDP-US Section 9 [9], then it can be fixed in an errata
> or update. BTW, the prologue in Section 9 should be edited to make it clear
> that the profile document doesn't formally define the profile *on its own.
> * I can see how if one were to read "The following TTML profile
> definition formally defines the SDP US profile", then one would (1) find
> an inconsistency between what I've been saying above and this text and (2)
> would come to the wrong conclusion that the profile definition document is
> sufficient. [If that is your main problem, then we can easily fix that via
> an editorial correction.]****
>
>  ****
>
> [9]
> http://www.w3.org/TR/2013/NOTE-ttml10-sdp-us-20130205/#Features_in_TTML_1.0_Used
> ****
>
>  ****
>
> 3.       Won’t result in a perfectly conformant SDP-US decoder from
> having to reject all documents referencing such a profile.****
>
> Why would such a decoder have to reject all documents referencing SDP-US?*
> ***
>
>  ****
>
> In any case, I can see how it might be useful to further soften the
> language about potentially aborting/rejecting to be qualified by the actual
> use/presence of a feature/extension for which support is required (by the
> combined, merged profile). That is, instead of conservative (let's call
> this strict) rejection if a feature isn't supported, define a "lax"
> rejection if it isn't supported, is required, and is actually used.****
>
>  ****
>
>  ****
>
> (For clarity, I’m using SDP-US and #color as examples that are familiar.
> I can pick other profiles and other features with the same issue.)****
>
> Regards,****
>
>                 Mike****
>
>  ****
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Monday, July 15, 2013 6:58 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]****
>
>  ****
>
>  ****
>
> On Fri, Jul 12, 2013 at 2:40 PM, Michael Dolan <mdolan@newtbt.com> wrote:*
> ***
>
> Agreed.  But the inline form is already permitted, and I don't see a
> compelling reason to disallow it. That said, I would expect the "normal"
> case is to use a URI.
>
> Since you said "URI" and not URL, it begs that we return to the question of
> resolvability and existence of the TTML syntax profile.  I still maintain
> that the profile must be definable in prose or other means without actually
> creating and/or posting a resolvable profile document that conforms to the
> feature syntax defined in TTML.****
>
>  ****
>
> These are orthogonal issues:****
>
>  ****
>
> (1) defining a profile****
>
> (2) defining a feasibly resolvable profile document****
>
>  ****
>
> The feature granularity is insufficient to
> describe any (I think) of the profiles in use today.****
>
>  ****
>
> Note that the purpose of a feasibly resolvable profile document is not
> intended to formally define a profile (in the more general sense you are
> using it). It is up to us (or extension definers) to be as specific as
> desired in enumerating feature and extension designators.****
>
>  ****
>
> A feasibly resolvable profile document is effectively needed (in the use
> of a non-standard profile and in the absence of an inline profile document)
> in order for a processor to know whether it should process a document based
> on which features are implemented by the processor.****
>
>  ****
>
> Minimally there are
> certainly profile examples that cannot be (sdp-us and cff-tt). The feature
> mechanism cannot be extended by 3rd parties.****
>
>  ****
>
> If by "extended by 3rd parties" you mean defining new non-standard
> "features", then yes it is supported, since a non-standard "feature" is
> just what we call an "extension". Or do you have something else in mind by
> "extended"?****
>
>  ****
>
> This effectively forces
> permitting the profiles to be defined by other means, and therefore, there
> cannot necessarily be a profile document, and therefore cannot be
> resolvable
> in all cases.****
>
>  ****
>
> The definition of a profile document and its accessibility by a processor
> is not related to the definition of a profile itself. It (the document
> referenced by the URI) serves an operational purpose only.****
>
>  ****
>
> I see no legitimate reason for anyone to define a TTML profile (as
> presently defined) and fail to define a feasibly resolvable profile
> document instance.****
>
>  ****
>
>
> Regards,
>
>         Mike****
>
>
> -----Original Message-----
> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
> Sent: Friday, July 12, 2013 1:24 PM
> 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.
> >> >
> >> >
> >> >
> >> >
> >>
> >****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>