Re: profile summary

Basically, today (in TTML1) we have a limited form of a propositional logic
for evaluating each feature/extension: essentially, we assume an AND
operator over every feature/extension specification, each of which
evaluated as:

   - if "optional", then true
   - if "required" AND supported, then true
   - if "use" AND enabled, then true

What we don't have is an OR operator, such as:

<or>
  <extension value="required">http://extension.org/spec/#color-rrggbbaa
</extension>
  <feature value="required">http://www.w3.org/ns/ttml/feature/#color
</feature>
</or>

Adding an OR operator would address the concern expressed by John. Although
this doesn't express the subset relationship.

An alternative (or additional mechanism) would be something like:

<extension
  value="required"
  subsetOf="http://www.w3.org/ns/ttml/feature/#color">
  http://extension.org/spec/#color-rrggbbaa
</extension>

Adding this alternative, would change the above evaluation rules to:

   - if "required" AND (supported OR evaluate(subsetOf,"required")), then
   true
   - if "use" AND (enabled OR evaluate(subsetOf,"use")), then true

If an <or> element were added, it begs the question of use cases for a
<not> element as well.


On Fri, Aug 16, 2013 at 5:30 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:

>  It appears as though a more formal mechanism for subsets is needed, that
> allows extension features to state that they are implied to be supported if
> some superset feature is supported. The current #length feature and all
> of its sub-features could be a starting point for this, in contrast to the
> time features e.g. #time-clock, #time-offset etc which do not include a
> superset feature.
>
>  An example of something a profile creator could hypothetically want to
> do would be to define a subset feature #time-clock-hms that does not
> require that fractions be supported. This would be implicitly supported if
> #time-clock is supported, and it would be useful for a processor to be
> able to derive that information.
>
>  However I'd suggest that if a required feature is *only* a combination
> of a set of other features, then it should be good practice to explicitly
> require that expanded set, even if the feature definition mechanism
> formally allows the relationship to be defined. See
> #time-clock-with-frames – it requires support for #frameRate,
> #frameRateMultiplier and #subFrameRate; this is in contrast to an implied
> support as in the previous example.
>
>  Nigel
>
>
>   On 16/08/2013 11:09, "John Birch" <John.Birch@screensystems.tv> wrote:
>
>    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 | 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 <mdolan@newtbt.com>]
> *Sent:* 15 August 2013 23:58
> *To:* 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****
>
> ** **
>
> 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
>    ­­
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>