Re: [ttml2] major update to profile related material

On 21/05/2014 15:45, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
On Wed, May 21, 2014 at 7:54 PM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:

Thanks Glenn. LGTM on the whole. One query, 2 typos:

Query:

Should ttp:validationAction be considered to be abort when not specified?

That is what I defined as the default, with my logic being that if validation is performed, then a natural consequence of failure is to abort. However, 'warn' might be a preferable default. I probably wouldn't make 'ignore' the default ... why bother to validate if you aren't going to take some action.

I'd go for warn as a default on the grounds that it at least gives the processor a chance to try to present the content, which is presumably the intention.

If neither ttp:validation nor ttp:validationAction are specified and a processor decides it will attempt to validate, then this could have unexpected consequences.

I make the default of ttp:validation be 'optional', so as presently defined: 'optional' + 'abort' is what you would get if we stay with the defaults and neither attribute is present.

Maybe a better option would be to introduce an "auto" value to the enumeration and set this as the default. Then the validation behaviour would be delegated to the validator. This would also facilitate an implementation's behaviour to be controlled validly by command line flags rather than document contents.

Over time, I've seen nothing but trouble arising from 'auto' values. In any case, I think we can allow the validator to determine overriding behavior, and treat @validationAction as a recommendation to the validator rather than a mandate.

Treating @validationAction as a recommendation rather than a mandate works for me.

As the implementor of a validator your thoughts on this have obviously directed you towards an 'always in the document' approach, but would the flags approach not also be useful in some circumstances?

External parameters may be of use when there is no internal content profile specified. However, I am leery of validating a document that fails to make any claim whatsoever about its content conformance. On the other hand, TTML1 docs had no way to make that claim (internally).

One problem with using an external parameter is how to deal with the case where the external claim conflicts with an internal claim.

Agreed – I was only referring to the validationAction not the conformance claim. However as you raise the point I would expect a validator to complain if given an external claim that conflicts with the internal claim.

Or even an informative note in the TTML2 spec to recognise that validating processors may choose to ignore the value of ttp:validationAction in favour of behaviour defined externally?

As I say above, it is reasonable to treat validationAction as a recommendation. However, an external parameter that claims specific content profile conformance needs to be treated more carefully.


Works for me – let's discuss on the call tomorrow and see if we can make that a resolution.


Typos:

In definition of [nesting profile] s/my/by

In §5.2.4.3 s/someimplementation/some implementation

thanks, will fix


Kind regards,

Nigel



On 21/05/2014 09:04, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:

I have posted an update [1] to the TTML2 ED [2] which addresses the issues raised in [3] (discussed in Shenzhen [4]).

Main changes are:

  *   deprecate ttp:profile attribute
  *   add ttp:contentProfiles
  *   add ttp:contentProfileCombination
  *   add ttp:processorProfiles
  *   add ttp:processorProfileCombination
  *   add ttp:inferProcessorProfileMethod
  *   add ttp:inferProcessorProfileSource
  *   add ttp:validation
  *   add ttp:validationAction
  *   modify ttp:profile content model to take list of ttp:profile or ttp:{feature,extension} sequence
  *   add @type to ttp:profile
  *   unify @combine on ttp:profile with ttp:{content,processor}profileCombination values
  *   define profile state objects and algorithms (section 5.2)
  *   update xsd/rnc schemas

There are a few aspects of this that need further tweaking, but most of the substance is there.

[1] https://dvcs.w3.org/hg/ttml/rev/66236744421e

[2] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html

[3] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/design/TPAC2013-TTMLProfiles.pdf

[4] http://lists.w3.org/Archives/Public/public-tt/2013Nov/0044.html





----------------------------

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.

---------------------




----------------------------

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.

---------------------