Re: [ttml2] major update to profile related material

On Wed, May 21, 2014 at 7:54 PM, Nigel Megitt <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.


> 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.


>
>  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.


> 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.


>
>  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> 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.
>
> ---------------------
>