Repository navigation
No feature to indicate TTML2 profile attribute vocabulary _only_ #1261
Description
While working on w3c/dapt#43 I noticed that there's no feature that allows only the TTML2 profile attribute vocabulary to be specified, without also requiring support for the TTML1-defined #profile. I expected to see this in #profile-version-2 but that's defined as an extension to #profile and declares it to be an error to prohibit use of #profile and require or permit #profile-version-2.
The possible options are:
- Define some new feature, excluding
#profile, e.g.#profile-exclusive-version-2 - Just use
#contentProfilesand#processorProfilesindependently, without also supporting#profile.
This probably doesn't have a very high priority to fix, but I'm raising it because I think in time we should be helping folk move away from tt@ttp:profile usage (i.e. ttp:profile attribute on the tt element), in favour of the newer vocabulary, and the current arrangement only goes half-way, in that it allows people to use both, but not to define a requirement that excludes the older vocabulary.
Activity
skynavga commentedon Dec 21, 2022
I don't view this as something that needs "fixed" since support for
#profileis required by#presentation,#presentation-audio, and#transformationfeatures, and thence,#presentation-version-2and#transformation-version-2.In addition, the construct effective processor profile procedure step 4 requires treatment of
tt@ttp:profile, a consequence of mandatory Generic Processor Conformance, step 2 (perform profile processing).Finally, the Backwards Compatibility clause indicates that TTML2 is designed to process conforming TTML1 documents, including those that employ
tt@ttp:profile, even in such cases as an audio-only TTML presentation processor.IMO, a better solution is for content aggregators and content services to require that no
tt@ttp:profilebe present in the TTML2 documents they ingest, but, rather, that#contentProfilesand#processorProfilesbe used as an alternative.nigelmegitt commentedon Dec 21, 2022
Thanks for that @skynavga. In the DAPT situation we want to make it a TTML2-only document, and explicitly don't care about TTML1 backwards compatibility, and we are indeed prohibiting use of the
tt@ttp:profileattribute and requiring use oftt@ttp:contentProfileswith at least one known value corresponding to DAPT.That being the case, it now looks unfortunate that the feature designators you listed bundle processing requirements for functionality we don't want implementers to have to support.
The upside is that we can roll our own combined set of features that omits
#profile, cumbersome though that may be.Looking at construct effective processor profile procedure step 4, effectively what I'm saying is that it should be feasible for implementers to omit that step, since
#profilesupport is not required.I also note that the first line definition of
#profileconcerns thett@ttp:profileattribute, but then the feature also incorporates support for element vocabulary. Since we will be using a well-known profile designator inttp:contentProfileswe don't require that any of that vocabulary is supported, though of course support would be permitted.skynavga commentedon Dec 21, 2022
I would suggest the following. In DAPT,
#profile-root(scoped to DAPT NS) as supporting semantics ofttp:profileattribute ontt(root) element;#profile-rootasprohibitedin the DAPT content profiles andoptionalin the DAPT processor profiles;A comment regarding DAPT Conformance: the term permitted is used multiple times; however, this term is not defined or used in TTML2, so has no meaning in the context of referring to TTML2 profiles. However, the term optional is used by TTML2 and applies equally to content and processor profiles, where it means it may or may not appear in a document (when used with a content profile), and it may or may not be supported by a processor (when used by a processor profile). In contrast, the term permitted, as I understand it, would apply only to a content profile, and not to a processor profile.
nigelmegitt commentedon Dec 21, 2022
Thanks for the suggestion, that could work. It would still not allow us to use any of the TTML2 features that require support for
#profileof course, since that would introduce a requirements conflict.The conformance terms permitted, optional, required, prohibited used in DAPT are defined in DAPT's Conformance section rather than using their TTML2 definitions. I see that we don't say anything about processor support for features marked as
optional, which looks like an omission.nigelmegitt commentedon Dec 21, 2022
I think my previous comment regarding conformance language may have been slightly at cross-purposes with what you meant @skynavga - I've opened an issue on DAPT with your comment, and my summary of what needs to be fixed based on it.
skynavga commentedon Dec 21, 2022
Regarding
I'm not sure that is true. In particular, see the note at the end of 5.2.1:
I would then expect DAPT to specify that
#profile-rootisprohibitedin its content profile butoptionalin its processor profiles; however, the profile specification in Features does not distinguish between content and processor profiles.nigelmegitt commentedon Dec 22, 2022
@skynavga how does that subtractive profile idea interact with text such as:
from
#profile-version-2? On first look, it appears that the spec is prohibiting subtraction in this case, by declaring it to be an error.skynavga commentedon Dec 22, 2022
While that is an interesting question, it is a problem for another day since I am suggesting to prohibit a new
#profile-root, and not#profile. A bit of subterfuge, but by the letter of the specification, not inconsistent.In retrospect, we probably should have considered deprecating
tt@ttp:profilein 2nd Ed. But that too, can be deferred.nigelmegitt commentedon Dec 22, 2022
Thanks again @skynavga - I've implemented your proposal at w3c/dapt#103 along with some other changes. With reference to your point about the conformance terms, it should be clearer how the DAPT dispositions map to the TTML2
ttp:featureandttp:extensionelements'valueattributes now.I'm not sure if there's any urgent work to do in TTML2, but it does seem odd that there's no semantic defined for a processor profile when
ttp:feature@value="prohibited"(likewise forttp:extension@value="prohibited"). I think it should be the same semantic as foroptional.The other addition made in DAPT, absent from TTML2, is the semantic: optional in content, required in processor. The term "permitted" is used for this in DAPT.
skynavga commentedon Dec 22, 2022
Regarding
Actually, it is defined (as mapped to
optional) by Table 6-2.I think
permittedis not needed in TTML2 since everyttp:featureandttp:extensionelement is specified in the context of attp:profileelement of a specific type (eithercontentorprocessor).As an aside, I've never been comfortable with IMSC's introduction of
permittedsince it has no syntactic counterpart in TTML2 itself. Further, having IMSC (and now DAPT) define profiles without actually including any timed text profile document is troubling. IMO, every TTML profile specification should include (inline) one or more such documents, such as those found in TTML2 itself: Appendix G - Standard Profiles.nigelmegitt commentedon Dec 22, 2022
OK, for DAPT where I'd like to define a single profile, I like the idea that I can define it as a content profile and have there be inference rules for what that means for generating a processor profile, and I hadn't paid enough attention to that section, so thanks for the pointer.
The difficulty is that I don't want to have to require
ttp:inferProcessorProfileMethod="strict"on every DAPT TTML document instance, but that's the definition in Table 6-2 that we would want, and omitting it, the one that we'd get is the "loose" one.It seems like a shame right now that the
ttp:inferProcessorProfileMethodis only considered significant on the<tt>element: it would be neat to have it on a<ttp:profile>element wheretype="content"to say "hey, if you're inferring a processor profile from me, do it in a [strict|loose] way".nigelmegitt commentedon Dec 23, 2022
I realised overnight that my last comment was not right. Using either
looseorstrictalone can not achieve what I think we want from a content profile that can be used to infer a processor profile.The missing category is not in the
inferProcessorProfilemethod, it's in the classification of feature use, and is exactly what is introduced in both IMSC and DAPT to allow some features to be marked as "optional in both content and processor" and others to be marked as "optional in content, required by processor".That mix of feature states can't be switched on a feature level by
inferProcessorProfileat all, because it only acts on a profile level.I would suggest adding the
permittedvalue tottp:feature@valueandttp:extension@valuebut the amount of change required would be quite large. For example Table 6-1 would be much bigger due to the larger number of permutations.nigelmegitt commentedon Dec 23, 2022
The solution I have, which feels non-ideal, but safe, is to specify in w3c/dapt#103 the content profile and the processor profile explicitly in the appendix, as timed text profile documents, while keeping the easier-to-read table of feature and extension dispositions.
nigelmegitt commentedon Oct 8, 2026
Suggest closing this with no change, in favour of #1286. There's another potential new issue, to do with the
permitteddisposition in DAPT and IMSC, but the mechanism used in DAPT seems to work, so apparently no change is actually needed in TTML2, even if it would be useful.