RE: profile summary

Mike is attempting to explain what we have in TTML1 today, not define a new proposal; although that may follow on, once people understand what we have today, and its limitations.

The point of 5 is that one cannot today write a profile using the standard #feature set which describes *exactly* what the document needs.

For example, if the document only needs #aarrggbb support and a limited palette of colours, either the document must require #color in its profile, which would include that as a subset; i.e. the document is asking for more than it needs, which is inefficient, as #color implies the processor must support features the document doesn't need. Or the profile author must create a new feature to capture just the required subset; which suffers from the fact that its non-standard, and so your corollary is also true, if a document carrying a profile with a required extension feature (intended to capture a subset of a standard feature) lands on a processor which understands the standard feature, but not the non-standard extension, then it would not process the document (modulo user override) even though it would be perfectly capable of doing so.

What we do about this state of affairs (if anything) is the subject of next week's discussion. We may end up repartitioning the features to capture a much finer grain set, or another possible solution might be to create some additional syntax which allowed an <extension> to somehow defer to a standard <feature>  on a processor which does not have the extension, but does have a standard feature which would imply the necessary support.

Or we might abandon the profile thing altogether for an entirely different system.

Hope this clarifies.

From: John Birch [mailto:John.Birch@screensystems.tv]
Sent: 16 August 2013 11:10
To: Michael Dolan; public-tt@w3.org
Subject: RE: profile summary

I may not be understanding correctly, but I think I have an issue with point 5.

What I interpret you as saying is that a use case that only uses part of a current TTML feature (e.g. only uses RGBA hex colour definitions) must create that *subset* as a *new* feature.

The problem I have with this is that

a)      An existing processor that supports the currently defined colour feature might reject a document marked with the new subset feature even though it is perfectly capable of processing the document.

b)      In fact, a new document 'profile' that only contains subsets of existing functionality would not be accepted by such a processor... if the designer of the processor had not updated his profile handling mechanism to incorporate the new subset features.

In fact the existing profile / feature mechanism is not the problem... since it can be used to indicate the necessary functionality required in a processor (even if some of that functionality is unused by the document instance (which is clearly the norm for most document instances).
What IMHO is required is a different mechanism that can be used when specifying document structures that can be used to validate and define how the features of base TTML have been constrained.

I do agree that new features defined by derived specifications that are not in base TTML should have a new #feature defined.

But perhaps I misunderstand your proposal?

Best regards,
John


John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 270 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems

Visit us at
IBC, Hall 1 Stand C49, The RAI, Amsterdam, 13-17 September

P Before printing, think about the environment

From: Michael Dolan [mailto:mdolan@newtbt.com]
Sent: 15 August 2013 23:58
To: public-tt@w3.org<mailto:public-tt@w3.org>
Subject: profile summary

In an attempt to lay some groundwork for how we want to improve the profile mechanism, I undertook an attempt to summarize the various provisions of TTML1SE. This is not intended to replace the normative provisions, but rather summarize them (hopefully clearer) as well as capture some indirect implications.

After everyone digests this a bit, then we may be able to have a framework in which to discuss the various open issues on profiles.

1.       Profiles are used today to signal, in an instance document, what TTML features and extensions are required by a processor to process the document. Today, profiles are not used to signal instance document conformance (but see below).

2.       All instance documents should contain a profile parameter attribute or a profile element.

3.       Processors not supporting all of the required features and extensions signaled in the instance document by a profile parameter attribute or a profile element must reject the document unless 1) there is an explicit override from the user or system configuration; or 2) the profile is not available to the processor.

4.       By including a feature or extension designator in a profile, the full syntax and the minimum required semantics (as defined by the referenced feature or extension) must be supported by the processor. It is not valid for a processor to continue processing a document that requires support for a feature or extension if it only supports some subset of that feature defined elsewhere.

5.       If desired features or extensions do not meet or exceed existing defined features or extensions, then the profile designer must either propose a new feature designator be added to TTML, or define a new extension designator that describes the constrained feature. In other words, if support for a strict subset of a feature or extension is intended, then a new subset feature or extension needs to be defined

6.       Profile designers are required to define a profile document and should publish a URI that would reasonably resolve to such a document. Failing to publish the URI has potentially negative interoperability consequences. It is recommended that the URI be a URL using the HTTP scheme for better interoperability.

7.       If processors do not recognize a profile from the profile designator URI and it wishes to present the document, then unless there is an override, it is required to attempt to resolve and analyze the profile document.

8.   Profile mechanisms are expected to be extended in TTML2 to:

a.  Add support to use the profile mechanism to declare document conformance;

b.  Add the designator property of "prohibited" (mostly in support of (a)); and

c. Other enhancements as appropriate



Michael A DOLAN
TBT, Inc.    PO Box 190
Del Mar, CA 92014
(m) +1-858-882-7497
mdolan@newtbt.com<mailto:mdolan@newtbt.com>


This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ