Re: more profile confusion

This is exactly the problem we had in the EBU-TT group with the profile 
mechanism. We thought about to make an EBU-TT profile but at the end we 
did not amongst others because in practice users understand and use this 
mechanism differently.

Mike emphasized the crucial point: the distinction between a restriction 
of a TTML document instance by a Subset (what Mike described as a 
document profile) and a "hint" mechanism what a processor is expected to 
support when processing a document that is an instance of a TTML 
Subset/Variation. This distinction is maybe not well understood by the 
TTML user community.

In theory the profile mechanism makes sense. In practice it might not be 
applied as intended. So it is maybe the right time to "rethink" this 
concept.

With the relationship between "general" features and "restricted" 
features of the same kind Mike named another area that needs clarification.
I had this topic last week in an email conversation with Sean Hayes and 
we agreed that this has to be discussed in the TTML Group. I found a 
profile where the general feature #fontStyle was included but neither 
#fontStyle-italic nor the feature #fontStyle-oblique. The intention of 
the implementing Group seems to be to support #fontStyle-italic and 
#fontStyle-oblique. But from the Spec this is not clear.

Best regards,

Andreas



Am 12.03.2012 23:47, schrieb Michael A Dolan:
>
> The more I ponder our open issues with profiles, the more questions I 
> have...
>
> I've always been a bit unclear about whether the profile applies to 
> the document or to the processor.  Relevant I think is the 6.1.1 text: 
> "...its purpose is to express authorial intentions about which 
> features and extensions must or may be supported by a recipient 
> content processor. In addition, the element indirectly expresses 
> information about the set of features or extensions that are (or may 
> expected to be) used by the document instance"
>
> The above seems to indicate that the profile is a set of metadata 
> delivered (possibly in the document instance) to a processor to 
> indicate which features are required to properly operate on the 
> document instance.  It does not appear to be a means to define a 
> document profile, yet many users have interpreted it that way.  As a 
> set of processor metadata, it then makes sense that there is no 
> "forbidden" value or a definition of what it means to have omitted 
> features.
>
> Minimally this needs to be clarified. If we decide we want to also 
> make it a means to define formal document profiles, then I don't think 
> it is a rich enough expression -- XML schema or RelaxNG is really 
> needed, which would then obviate the need for such a parallel (and 
> possibly conflicting) feature description.
>
> Either way, I am also confused about the practice of including various 
> features concurrently -- both in the Recommendation and as used by 
> 3^rd parties. I don't know what it means to include:
>
> 1.            Both (for example): #backgroundColor and 
> #backgroundColor-block; or
>
> 2.            All of (for example): #backgroundColor, 
> #backgroundColor-block, #backgroundColor-inline, and 
> #backgroundColor-region; or
>
> 3.            Both (for example):  #presentation and #core.
>
> In #1, doesn't #backgroundColor sweep in all semantics and placement?  
> If so, what does it mean to add the more restricted one? And if 
> #backgroundColor does not include all semantics and placement, what is 
> excluded? (This is just an example and the same question can be asked 
> of all the #[feature]-[subset] constructions.)
>
> In #2, all the subset constructions are specified. How is this 
> different from simply #backgroundColor?
>
> In #3, #core is included in #presentation, so isn't #presentation 
> adequate?
>
> Regards,
>
>                 Mike
>
> Michael A DOLAN
>
> Television Broadcast Technology, Inc
>
> PO Box 190, Del Mar, CA 92014 USA
>
> +1-858-882-7497 (m)
>


-- 
------------------------------------------------
Andreas Tai
Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
Floriansmuehlstrasse 60, D-80939 Munich, Germany

Phone: +49 89 32399-389 | Fax: +49 89 32399-200
http: www.irt.de | Email: tai@irt.de
------------------------------------------------

registration court&   managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------