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

On Wed, Jul 17, 2013 at 12:43 PM, Michael Dolan <mdolan@newtbt.com> wrote:

> OK, I think we’re finally at a common understanding. I don’t necessarily
> agree with a few of the conclusions, but I concede they are a reasonable
> interpretation.****
>
> ** **
>
> I would offer that TTML 1.0 would benefit from a recommendation about
> profile designator values along the lines of: “To increase
> interoperability, it is recommended that the URI be a URL using the HTTP
> scheme and that presentation processors attempt to acquire and examine the
> profile documents.”
>

That's a good suggestion. I'll add a note to that effect (in SE & .next).


> ****
>
> ** **
>
> This thread was not intended to pick apart SDP-US. For convenience, I used
> its #color feature for illustrative purposes. However, I think it is clear
> from this thread that SDP-US could use some profile feature clarification
> relative to what I am nearly certain was the original intent of the
> constraints.  This extends beyond just #color. I’ll file an issue.****
>
> ** **
>
> Regards,****
>
> ** **
>
>                 Mike****
>
> ** **
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Wednesday, July 17, 2013 9:36 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 Wed, Jul 17, 2013 at 9:53 AM, Michael Dolan <mdolan@newtbt.com> wrote:*
> ***
>
> Regarding the two highlighted bits of text from further below:****
>
> any URI that feasibly dereferences a TTML *Profile Definition Document****
> *
>
>  ****
>
> and****
>
>  ****
>
> it is not required that a conformant TTML Content processor be able to
> dereference such an externally specified profile definition.****
>
>  ****
>
> then the URI has to be capable of being used to “feasibly dereference” a
> profile document, but the decoder has no obligation to do so.****
>
>  ****
>
> And, as we both noted, TTML provides no application-independent mechanism
> to resolve the URI, so two independent decoder (applications) would not
> know about the other’s private resolution process.  Therefore, most URI
> forms are actually not resolvable by any application decoder other than the
> ones that already knows all about the profile in the first place. So, all
> of this is virtually meaningless from a practical point of view unless the
> URI is formed as a URL with a common scheme (e.g. http).****
>
>  ****
>
> And, if one cannot have a reasonable chance of resolving access to the
> profile document, I don’t see any point to requiring that it exist. I can
> claim that I have created a profile of TTML, “published” a profile
> document, and then use the profile designator “urn:mike:foo” in my instance
> documents. I know how to resolve the URN (maybe it’s printed on paper on my
> desk, maybe not), but no one else has a clue how to resolve that URN. Good
> luck finding the profile document or conversely proving the profile
> document does not exist on my desk.****
>
> ** **
>
> Just because you can do that doesn't mean its a good idea. Its up to you
> as a profile author. If you want to write a profile that is widely
> interoperable, you will use a URI based on a common access method. If you
> want to write a profile for your intranet and don't care about external
> interoperability, then you can be more flexible.****
>
> ** **
>
> That you as a profile author can do this doesn't mean we need to overly
> constrain profile designators to use URLs based on http.****
>
>  ****
>
>  ****
>
> I certainly agree that TTML decoders should be able to parse and store
> well-formed XML. But to ensure we are still on the same page - if SDP-US
> decoders have no obligation to parse, process and make use of any values of
> tts:color other than #rrggbbaa, then that clearly violates the TTML
> feature designator, …ttml/feature#color, right?****
>
> ** **
>
> Correct. But as defined, a conforming SDP-US processor must support #color
> as defined, which means supporting more than a conforming document can use.
> ****
>
> ** **
>
> So, we have two choices as I see it to "fix" this:****
>
> ** **
>
> (1) define a new extension designation
> http://www.w3.org/ns/ttml/extension/#color-rrggbbaa and revise section 9
> of SDP-US to require this extension, while removing the existing #color
> feature requirement (this would need to be done for each and every
> constrained feature currently required);****
>
> ** **
>
> (2) modify the language in Section 3 of SDP-US as I previously suggested:*
> ***
>
> ** **
>
> (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.****
>
> ** **
>
> The second approach above involves a lot less editing work, and doesn't
> require changing Section 9 or introducing new extension designations.****
>
> ** **
>
> ** **
>
>  ****
>
> SDP-US would need to define an extension, or TTML.next would need to
> define a new feature designator that matches that constrained set of
> values. Either that or SDP-US decoders must support all values of
> tts:color.  It’s no different than a decoder only supporting
> #length-integer but claiming support for #length.****
>
>  ****
>
> I wasn’t proposing that we add the term “decode” to our Recommendation.***
> *
>
>  ****
>
> Regards,****
>
>  ****
>
>                 Mike****
>
>  ****
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Tuesday, July 16, 2013 6:46 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 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.
> >> >
> >> >
> >> >
> >> >
> >>
> >****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>