- From: David Singer <singer@apple.com>
- Date: Mon, 12 May 2014 18:37:29 +0200
- To: Glenn Adams <glenn@skynav.com>
- Cc: Cyril Concolato <cyril.concolato@telecom-paristech.fr>, TTWG <public-tt@w3.org>
Hi Glenn, comments and questions inline… On May 12, 2014, at 18:21 , Glenn Adams <glenn@skynav.com> wrote: > > You say singular “the”, but a document can be conformant with more than one profile, can’t it? How do I indicate that? > > In TTML1, it is not possible. However, we do have an open issue to add support to TTML2 to allow defining a profile by referencing multiple referenced profiles [1]. This mechanism may be used to refer to such a combined profile, where the profile designator makes reference to the definition of the combined profile, e.g., [using the mechanisms for defining processor profile] > > #1 referencing a combination processor profile Got it, but that doesn’t enable a content author, but a profile definer… > #2 referencing multiple processor profiles from ttp:profile attribute > > <tt ttp:profile="http://example.com/ttml/profile/A http://example.com/ttml/profile/B http://example.com/ttml/profile/C" ttp:profileCombination="leastRestrictive”> yes, that works > #3 embedding multiple processor profiles with ttp:profile element > > <tt ttp:profileCombination="leastRestrictive"> > <head> > <ttp:profile use="http://example.com/ttml/profile/A"/> > <ttp:profile use="http://example.com/ttml/profile/B"/> > <ttp:profile use="http://example.com/ttml/profile/C"/> > </head> > ... > </tt> that works too > > note that TTML1 already allows this type of combination profile definition but defines a hard-wired (rather than author specified) combination method sorry, you lost me > However, we need to be clear about the purpose of using a profile here. It is *not* to specify conformance, at least from the way I see people discussing this matter. Rather, it is to specify what processor profile is required to process the document. In other words, what features must be supported by processor according to author's requirements. This is distinct from what profile(s) the document conforms to. For example, a document may conform to a profile in which a feature is optionally used, but then require that feature be supported in order for it to be processed. I am not sure I get the distinction. * This processor profile is required to process the document. * This document conforms to this profile. What is the practical difference here, for a client trying to decide “I support profiles X, Y, Z; can/should I process this document?”. Isn’t it just a question of how conformance is defined (as a format question or as a processing question)? * Any one of these processor profiles are required to process the document. * This document conforms to these profiles. and these are the same with higher cardinality. > The only utility of a statement of content profile conformance is to (1) perform validation processing, and/or (2) to imply a processor profile in the absence of an explicit declaration of processor profile. From what I can tell in this discussion, folks are primarily thinking about the second of these uses of a content profile conformance declaration. Furthermore, it appears that, in regard to discussing references to multiple content profiles, folks are assuming that a disjunction combinator applies; namely, that the least restrictive expression of any given feature usage requirement would apply to creating a corresponding processor support requirement. > > For example, say we have three content profiles P, Q, and R that define one feature F, where P makes F prohibited, Q makes F optional, and R makes F required. Then it’s only possible to make a document that conforms to 2 of them (F is absent: PQ; F is present; QR). > If we then had an expression of conformance (where "leastRestrictive" profile is similar to an an "or" or "union" operation), e.g., > > <tt ttp:contentProfile="P Q R" ttp:contentProfileCombination="leastRestrictive”/> No, stop, we’re not asking that. <tt ttp:contentProfile="P Q R" ttp:contentProfileCombination="leastRestrictive”/> would mean a) everything in the document is either permitted by P Q and R (or is ignorable — permitted ignorable stuff under P Q and R) b) there is nothing in the document contrary to any of P Q or R c) if you implement at least one of P Q or R, then you can process the document, ignoring stuff that is not in the profile(s) you support, and the result is OK by the content author. > > I understand this desire. However, it is also clear that we are not going to define a calculus for use in a codecs parameter that is equivalent (in terms of expressibility) with the formal definition mechanism for processor and content profiles in TTML2. I don’t see any calculus required. Look, we have a number of TTML profiles already with significant overlap. If I write a document that stays in that intersection, someone implementing EBU TT, SMPTE TT, W3C DFXP, and so on, should all be fine. I suspect many simple cases will fall into this intersection. Documents ought to be able to say so. David Singer Manager, Software Standards, Apple Inc.
Received on Monday, 12 May 2014 16:38:00 UTC