RE: more profile confusion

Another troubling profile sentence in 5.2 was called to my attention:

 

If neither <http://www.w3.org/TR/ttaf1-dfxp/#parameter-attribute-profile> ttp:profileattribute nor <http://www.w3.org/TR/ttaf1-dfxp/#parameter-vocabulary-profile> ttp:profileelement is present in a TTML document instance, and if the document interchange context does not specify a profile, then the DFXP Transformation profile applies.

 

A “document interchange context” might well fully define a conforming subset definition, but it may or may not formally define a “profile” as defined in the recommendation.

 

An instance document would more likely declare its conformance by some other means, such as reference to a schema, or using xml-model, or simply by its context (e.g. a branded MP4 file).

 

When we get to overhauling the profile language, we should fix the above, minimally replacing “profile” with “conforming subset” or something more generic that does not imply a TTML Profile definition is required.

 

Regards,

 

                Mike

 

From: Glenn Adams [mailto:glenn@skynav.com] 
Sent: Thursday, March 15, 2012 6:11 AM
To: Andreas Tai
Cc: Michael A Dolan; public-tt@w3.org
Subject: Re: more profile confusion

 

Sure, that wouldn't hurt. As for deleting them, perhaps in the specified profiles, but not as feature designators. They are not redundant in their definition, just in their potential usage.

On Thu, Mar 15, 2012 at 2:59 AM, Andreas Tai <tai@irt.de> wrote:

It would be good to make this more explicit in the spec. As well it maybe worth considering to delete redundant features from the DFXP Profiles.

- Andreas
Am 15.03.2012 07:45, schrieb Glenn Adams: 

 

On Mon, Mar 12, 2012 at 4:47 PM, Michael A Dolan <mdolan@newtbt.com> wrote:

Either way, I am also confused about the practice of including various features concurrently – both in the Recommendation and as used by 3rd 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.)

 

specifying that #backgroundColor is required is equivalent to specifying that #backgroundColor-{block,inline,region} are required;

 

the reason for having the subset features is that one may not require all, e.g., may not require inline background color, but only require block and region, in which case one would specify that #backgroundColor-{block,region} are required; or if one is lazy (and willing to risk running on a presentation processor that happens to support block and region background color but not inline background color), then one could merely specify #backgroundColor as required

 

so in this case, specifying #backgroundColor-block is redundant

 

In #2, all the subset constructions are specified. How is this different from simply #backgroundColor?

 

no difference, specifying the subset constructions is redundant

 

In #3, #core is included in #presentation, so isn’t #presentation adequate?

 

#core is a subset of #presentation, so in specifying both the former is redundant

 

¿claro?

 

-- 
------------------------------------------------
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 <tel:%2B49%2089%2032399-389>  | Fax: +49 89 32399-200 <tel:%2B49%2089%2032399-200> 
http: www.irt.de | Email: tai@irt.de
------------------------------------------------
 
registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------