RE: ISSUE: Changes to Simple Delivery Profile to Allow Use of Other Profiles

I don't see that thread, which although it brings up some issues on profile features (which I believe are now in tracker), as questioning the way the profile mechanism itself works and any relationship to namespaces; we are not proposing any change in how profile is specified in TTML1.0.

Multiple profiles are explicitly allowed in TTML1.0, and the rules for combining them are clear. They apply to documents, the processor uses this information to determine whether it should process the document.

Specifically create the collection corresponding to each of the individual profiles using the following rules :
The collection of features and extensions of a profile are determined according to the following ordered rules:
1.   initialize the features and extensions of the profile to the empty set;
2.   if a use attribute is present, then augment the profile with the set of features and extensions specified by the referenced baseline profile;
3.   for each ttp:feature and ttp:extension element descendant of the ttp:profile element, using a post-order traversal, merge the specified feature or extension with the features and extensions of the profile, where merging a feature or extension entails replacing an existing feature or extension specification, if it already exists, or adding a new feature or extension specification, if it does not yet exist in the profile;

and combine them using 5.2

If more than one ttp:profile element appears in a TTML 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).

From: Michael A Dolan [mailto:mdolan@newtbt.com]
Sent: 19 September 2012 09:01
To: public-tt@w3.org
Subject: RE: ISSUE: Changes to Simple Delivery Profile to Allow Use of Other Profiles

Sean-

Please read the email thread quoted below, where the discussion about 6.1.1 is clear and everyone seemed to concur last March.

But as I said,  I am OK with changing the purpose of profiles to be for the use case that you (and Monica) want - I agree it seems more useful.  I just oppose silently assuming a different purpose for profiles without first changing the TTML spec to alter the meaning.

Regards,

                Mike

From: Sean Hayes [mailto:Sean.Hayes@microsoft.com]
Sent: Wednesday, September 19, 2012 7:54 AM
To: Michael A Dolan; public-tt@w3.org
Subject: RE: ISSUE: Changes to Simple Delivery Profile to Allow Use of Other Profiles

I don't recall that being the intent, and there is no language in the specification I can see which makes such a restriction.

From: Michael A Dolan [mailto:mdolan@newtbt.com]
Sent: 19 September 2012 07:22
To: public-tt@w3.org
Subject: RE: ISSUE: Changes to Simple Delivery Profile to Allow Use of Other Profiles

I believe the intent of supporting more than one profile was only to allow the specification of a single profile for each namespace used within the document (e.g. ttml, smpte, etc), not for multiple profiles in the same namespace as you describe as the desired use case (e.g. dfxp-full, sdp, etc). See:
http://lists.w3.org/Archives/Public/public-tt/2012Mar/0015.html

I believe the use case you wish to enable is neither intended, nor possible given the current definition of how profiles are to be used.  But maybe I misunderstand the use case you describe?

We should discuss this further in the meeting tomorrow.

                Mike

From: Monica Martin (MS OPEN TECH) [mailto:momartin@microsoft.com]
Sent: Tuesday, September 18, 2012 4:51 PM
To: Michael A Dolan; public-tt@w3.org
Subject: RE: ISSUE: Changes to Simple Delivery Profile to Allow Use of Other Profiles

A bit confusing Michael. None of the added text in Sections 1 or 5.4.2 is a conformance requirement. The addition of ttp:profile element was to correct an omission in Section 5.2.2.  Use of multiple ttp:profile is allowed by TTML 1.0.[1]

I can see we could remove this text in Section 5.4.2 Note:  "See also Conformance<http://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10-sdp-us/Overview.html#conformance>."

Monica

[1] Section 5.2
The profile of TTML that must be supported by a TTML content processor in order to process a document instance is specified either (1) by specifying attp:profile attribute on the root tt element, as defined by 6.2.8 ttp:profile<http://www.w3.org/TR/2010/REC-ttaf1-dfxp-20101118/#parameter-attribute-profile>, or (2) by including one or more ttp:profile elements in the head element, in accordance with 6.1.1 ttp:profile<http://www.w3.org/TR/2010/REC-ttaf1-dfxp-20101118/#parameter-vocabulary-profile>.

From: Michael A Dolan [mailto:mdolan@newtbt.com]<mailto:[mailto:mdolan@newtbt.com]>
Sent: Tuesday, September 18, 2012 9:48 AM
To: public-tt@w3.org<mailto:public-tt@w3.org>
Subject: RE: ISSUE: Changes to Simple Delivery Profile to Allow Use of Other Profiles

I am concerned that this proposal perpetuates a misunderstanding about TTML profiles.  Profiles are metadata signaling to the Presentation Processor about what features are minimally required to properly render the document.  They are not, at least not directly, a signal for document conformance.

With the current definition in TTML, I'm not sure what value there is (and I can see serious downsides) to signaling, for example, all of the following profiles:

SDP-US
CFF-TT
DFXP-Full

The proper interpretation of the above, by virtue of the DFXP-Full, would be that a Presentation Processor would need to support every single TTML feature in order properly render such a document.

I'm pretty sure that's both not the intent of this proposal and obviously harmful as an SDP-US Presentation Processor would be permitted to reject the document.

If we want the profile to signal document conformance instead of required presentation processor features, we need to make substantive changes to the TTML 1.0 spec to change the definition of profile.

I'm OK with that change. But we can't implement this proposal without first doing that.

Regards,

                Mike

From: Monica Martin (MS OPEN TECH) [mailto:momartin@microsoft.com]<mailto:[mailto:momartin@microsoft.com]>
Sent: Tuesday, September 18, 2012 9:24 AM
To: 'public-tt@w3.org'; Michael A Dolan (mdolan@newtbt.com<mailto:mdolan@newtbt.com>); Sean Hayes
Subject: ISSUE: Changes to Simple Delivery Profile to Allow Use of Other Profiles

Issue: Allow more than one profile to be used in the SDP-US. Add use of ttp:profile element.

Benefit: Allows SDP-US to use TTML 1.0<http://www.w3.org/TR/2010/REC-ttaf1-dfxp-20101118/>, SDP-US profile URI, and other profiles.  TTML 1.0 already defines the mandatory processing semantics for the intersection of required elements of the profile(s) that apply (Section 5.2<http://www.w3.org/TR/2010/REC-ttaf1-dfxp-20101118/#vocabulary-profiles>).[1]

Proposal to add the following:[2]
1. Language in Section 1 that indicates use of other profiles is not precluded; retain URI requirement for this profile.
2. The profile element to the list of elements in R0007, Section 5.2.2.
3. Language in Section 5.4.2 that articulates how multiple profile elements may exist.

We plan to enter into Issue/Tracker. The question was raised by DECE community by Mike Dolan re: CFF-TT.

Thanks. Monica


Monica J Martin
Senior Program Manager
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation


[1]
TTML 1.0 Section 5.2:  If more than one ttp:profile element appears in a TTML document instance, then all specified profiles apply simultaneously."

[2] Proposed changes (in bold)
Section 1
This constrained profile enumerates a set of required TTML features, some of which may be constrained in behavior, and the capabilities required of a Presentation Processor<http://www.w3.org/TR/ttaf1-dfxp/#conformance-presentation-processor> in TTML 1.0.  The semantics defined in TTML 1.0 apply unless otherwise constrained in this profile.

Claims of conformance MUST use this URI and implement the required features and constraints of use and processing outlined in this profile.

Name

Designator

simple-delivery

http://www.w3.org/TR/profile/simple-delivery<http://www.w3.org/TR/profile/online-delivery>


Conformance to this profile does not preclude the:

*         Use of other features defined in TTML 1.0. Such behavior is not defined here.

*         Use of other profiles that may implement the features in this profile.

Section 5.4.2
Add to Note (1). NOTE: See also Conformance<http://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10-sdp-us/Overview.html#conformance>.  TTML 1.0 allows zero or more profiles (ttp:profile in the head element) to be specified and used simultaneously. A player may reject documents it does not understand.

Add to Note (2). NOTE: When the use attribute is used on the ttp:profile element, the use attribute could indicate the geographical region for which the profile is used. For example, specific styling capabilities could be used in a particular geographical region. See also Other Constraints<http://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10-sdp-us/Overview.html#other_constraints>.

Requirement R0007
Add ttp:profile element to the list.