- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 12 May 2014 13:15:12 -0600
- To: David Singer <singer@apple.com>
- Cc: Cyril Concolato <cyril.concolato@telecom-paristech.fr>, TTWG <public-tt@w3.org>
- Message-ID: <CACQ=j+dc-G23TJ_63UUG3Rxn9pQnnjaGDmwG5ynneAePra0d=g@mail.gmail.com>
On Mon, May 12, 2014 at 10:37 AM, David Singer <singer@apple.com> wrote:
> 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
>
TTML1 already allows including multiple ttp:profile elements [1] and
defines a hardwired combination method:
If more than one ttp:profile element appears in a *Document Instance*, then
> all specified profiles apply simultaneously. In such a case, if some
> feature or some extension is specified by one profile to be used (mandatory
> and enabled) and by another profile to be required (mandatory) or optional (voluntary),
> then that feature or extension must be considered to be used (mandatory
> and enabled); if some feature or some extension is specified by one profile
> to be merely required (mandatory) and by another profile to be optional (voluntary),
> then that feature or extension must be considered to be required
> (mandatory).
This is equivalent to specifying ttp:profileCombination="replace" as
currently defined in TTML2 [2].
[1] http://www.w3.org/TR/2013/REC-ttml1-20130924/#vocabulary-profiles
[2]
https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#parameter-attribute-profileCombination
>
> > 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.
>
If this can be rephrased as follows, then yes:
"A processor must abort processing (unless overridden) when the effective
processor profile specifies a feature/extension is required and the
processor does not support that feature/extension."
where "effective processor profile" is the result of combining all
processor profiles referenced/defined by a document, and the method of
combination is specified by ttp:profileCombination.
> * This document conforms to this profile.
>
If this can be rephrased as follows, then yes:
"A document declares it satisfies (or otherwise conforms with) the
effective content profile. In addition, in the absence of declared
processor profile, a processor may infer a processor profile from this
effective content profile."
where "effective content profile" is the result of combining all content
profiles referenced/defined by a document, and the method of combination is
specified by ttp:contentProfileCombination.
>
> What is the practical difference here, for a client trying to decide “I
> support profiles X, Y, Z; can/should I process this document?”.
To answer this question in general, the client must determine the effective
processor profile by combining all referenced/included/inferred processor
profiles. A content profile declaration would only apply in the absence of
an explicitly referenced or included processor profile, i.e., only when it
is necessary to infer a processor profile from the effective content
profile.
> Isn’t it just a question of how conformance is defined (as a format
> question or as a processing question)?
>
The definitions of content conformance and processor conformance are
distinct.
A document may (or not) conform to a content profile, a determination that
can be made by a content validator/verifier using some set of
specifications, including, e.g., schemas, custom verification tools, etc.
A processor on the other hand doesn't, strictly speaking, conform to a
processor profile. It conforms to general semantic requirements of TTML,
e.g., the ability to compute a document's effective processor profile and
test whether it (the processor) supports that profile's required
features/extensions. Thus, it is better to ask whether a processor
"supports" or "satisfies" a given processor profile, and not whether a
processor "conforms" with a processor profile.
Also, with respect to content profiles, it is better to ask whether a
processor "supports a processor profile implied by (inferred from) a
content profile".
Why do these concepts of processor profile and content profile need to be
distinct? It is best to give an example:
Let's say that content profile C defines a feature F to be optional,
meaning it may but need not be present. By itself this doesn't say anything
about whether a processor must support F. Now, an author may decide to use
F in some documents but not others, all of which conform to C. Now, let's
say an author wants all processors that may process these documents to be
able to correctly support F *if it is present*. So the author defines a
processor profile P that specifies that support for F is required. Now this
P is not the same as C, since the former says (support for) F is required,
and the latter says (use of) F is optional.
If the author were to only make reference to content profile C, and not
reference a processor profile, then a processor profile would need to be
inferred from C, in which case a determination must be made as to whether
support for F is required or optional. Depending on how we define this
default inference process, the inferred processor profile may or may not
meet the original requirements of the author (that F must be supported by
processor whether or not F is used in a document), in which case the author
might need to specify the suggested ttp:inferProcessorProfile.
So to summarize, the author has the following options (without considering
an external codecs/profile hint):
#1 declare only a processor profile;
#2 declare only a content profile, in which case a processor profile is
inferred at processing time;
#3 declare both processor and content profiles;
#4 declare neither processor nor content profile, in which case a default
processor profile is determined by the document interchange context, or, if
no context or the context doesn't specify a default, then choose a default
based on the type of processing (transform vs presentation) and the version
of TTML that applies;
When processing on client, the processor looks only at the processor
profile, unless it is performing validation processing, in which case it
would look at the content profile. If there is no declared content profile,
then no validation is possible, i.e., content profile is never inferred
from processor profile, etc.
>
> * 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).
>
"conforms simultaneously to 2 of them"
>
> > 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)
>
actually, leastRestrictive is defined to mean that when merging values
component-wise for a given feature F (or extension E), then choose the
least restrictive value (optional > required > prohibited);
so for the example, the combination of P, Q, R would be F: optional; if
said document does use F, then it conforms to the combination, but not to
P; if said document does not use F, then it conforms to the combination,
but not to R
in contrast ttp:contentProfileCombination="mostRestrictive” means choose
most restrictive (prohibited > required > optional);
so for the example, the combination of P, Q, R would be F: prohibited; if
said document does use F, then it does not conform to the combination, but
does conform individually to Q and R; if said document does not use F, then
it conforms to the combination, but not to R individually;
b) there is nothing in the document contrary to any of P Q or R
>
it is up to the author to determine how they want to declare conformance;
in this (admittedly) complex example, the author has declared conformance
with two mutually conflicting content profiles, P and R; the combination
methods are defined to produce reproducible results, which they do
accomplish;
> 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.
>
in the above example, the author has only declared a (set of) content
profile(s), so it will be necessary to infer a processor profile from the
effective content profile, i.e., the content profile produced by performing
the content profile combination method on the declared content profiles;
if we alter our example and say that P, Q, and R are not pair-wise mutually
conflicting, and ttp:inferProcessProfile is not specified, in which case it
would default to 'loose', then we would end up with an effective processor
profile that requires support for a feature F only if all of P, Q, and R
require support for F, otherwise support for F is optional;
if ttp:contentProfileCombination were specified as 'mostRestrictive', then
the same configuration would require support for a feature F if any of P,
Q, or R require support for F, otherwise support for F is optional;
>
> >
> > 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.
If we define the syntax P+Q+R as a suffix of codecs (following stpp.ttml,
e.g., "stpp.ttml.P+Q+R") to mean:
1. P, Q, and R are identifiers that map to pair-wise non-conflicting
content profiles;
2. determine an effective processor profile as follows:
1. compute effective content profile ECP by combining P, Q, and R using
content profile combination method "leastRestrictive"
2. infer an effective processor profile EPP from ECP using the
"loose" inference method
3. if EPP contains a required feature/extension that is not supported by
the processor, then do not fetch resource
4. otherwise, fetch resource and commence processing of profile
declarations contained in resource (in tt:tt and tt:head elements);
5. if processing of profile declarations contained in resource result in
processing being aborted, then do not fetch remainder of resource and
continue to next candidate resource
Using this method, the codecs parameter could serve as a pre-filter on
fetching the resource and the the full TTML profile processing semantics
(based on declarations found in the resource) could occur next. So there
are two opportunities to reject and pass over a candidate resource in a
list of resources: once using the codecs parameter, and once using the TTML
resource's profile declarations.
A conservative client can ignore the codecs parameter and fetch each
resource to perform the TTML specified processor profile semantics; a
liberal client can perform the codecs base pre-filtering step and reject
fetches without performing the TTML specified profile processing.
The above procedure is a "limited calculus" that would appear to expose the
desirable filtering while not exposing the need to fetch or perform the
full TTML profile computations (in the pre-fetch state).
> 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.
>
I agree they should be able to do this internally, and they certainly will
be able to do so in a fuller manner in the TTML2 context. Not so much in
TTML1.
Defining the codecs parameter and a higher level (fetch filtering) proposal
such as described above should be able to handle this both for existing
TTML1 and new TTML2 resources.
>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>
Received on Monday, 12 May 2014 19:16:02 UTC