- From: Glenn Adams <glenn@skynav.com>
- Date: Tue, 16 Jul 2013 17:06:15 -0600
- To: Michael Dolan <mdolan@newtbt.com>
- Cc: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <CACQ=j+fTgTsDRyj2MKz2X-sOUqTr82dVq2AdxwjK7jwBDZrwOQ@mail.gmail.com>
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. > >> > > >> > > >> > > >> > > >> > >**** > > **** > > **** > > **** > > **** > > ** ** >
Received on Tuesday, 16 July 2013 23:07:09 UTC