Re: TTML attribute syntax versus semantics

A possible fix for this is to do the following:

(1) remove {*any attribute in TT Style namespace*} from each element that
specifies it now
(2) define *Inheritable.class *in a new table after table 5 (that looks
like table 4)
(3) add {*any attribute in Inheritable.class*} to each element that had (1)
before
(4) add specific, non-inheritable tts: properties to each element if the
property applies to that element

This would constitute a technical, non-backwards compatible syntactic
change since it would make documents invalid that are valid according to
the current element definition syntax. So this could only be done in
TTML1.1.

Another option is to add notes and other informative language under the
definition of non-inheritable tts properties that remind the reader that
specifying non-inheritable properties on elements for which they do not
apply is effectively a semantic NO-OP. This would be a non-technical
change, so could be done in TTML1.0 2nd Ed.

We could also do both of the above, i.e., elaborate usage in TTML1.0 2nd Ed
and make TTML1.1 more restrictive (syntactically speaking).

On Mon, Apr 16, 2012 at 9:40 AM, Andreas Tai <tai@irt.de> wrote:

>  I totally agree with Mike’s summary of the problem. I would prefer as
> well amendment in TTML 1.1 and the corresponding XML Schema. It would help
> building TTML  documents with correct semantics.
>
> It could be a possibility to allow “region only style attributes” only
> inside tt:region elements. If just incorrect inline styling is disallowed
> "region only style attributes" could be referenced by content elements
> (e.g. p) via the tt:style element.
>
> Best regards,
>
> Andreas
>
> Am 13.04.2012 18:47, schrieb Michael A Dolan:
>
>  One thing that I and others find confusing about the TTML specification
> structure is that the BNF syntax specification is very broad allowing for
> many attributes that have no semantics on the specific elements. For many,
> these are inherited style attributes and thus useful to child elements
> where semantics are defined.  However, there are some non-inheritable
> attributes that are syntactically permitted on many/all elements with no
> semantics or purpose.  In addition to seemingly conflicting language to the
> casual reader, the XML schema is constructed (as it should) with the
> broader allowed syntax, further reinforcing to the user that such
> attributes could have semantic meaning or purpose.****
>
> ****
>
> One such example that has led several implementers astray is <p> and
> tts:origin.  This is the subject of another issue about how to accomplish
> the positioning function at that level, but this email is about the general
> specification approach. ****
>
>  ****
>
> The BNF for <p> says it can have any style attribute.  But in the
> description of tts:origin, it says: “This attribute may be specified by any
> element type that permits use of attributes in the TT Style Namespace;
> however, this attribute applies as a style property only to those element
> types indicated in the following table.”  The table lists only <region>.
> This is common practice throughout the specification.  While it is useful
> to enable style inheritance, I think also including the non-inherited
> attributes creates confusion to no good purpose.****
>
> ** **
>
> I think we should not do this for future-defined elements and attributes
> and non-inheritable attributes should not be grouped with inheritable ones
> or allowed on elements for which there are no semantics.  A corresponding
> XML schema would, of course, not permit it. This specification practice
> would have invalidated the <p tts:origin> example above. Hopefully this
> makes sense to everyone.****
>
> ** **
>
> The harder question is should we try to “fix” the current spec (1.02
> and/or 1.1) to not actually permit tts:origin (and similar non-inheritable
> attributes) on anything except the elements where they have semantic
> meaning?  Personally I think the lack of backwards compatibility is
> over-ridden by avoiding “bad” TTML document construction. That is, any
> document that would not validate against an updated schema was probably
> authored in error in the first place.****
>
> ** **
>
> Regards,****
>
> ** **
>
>                 Mike****
>
> ** **
>
> Michael A DOLAN****
>
> Television Broadcast Technology, Inc****
>
> PO Box 190, Del Mar, CA 92014 USA****
>
> +1-858-882-7497 (m)****
>
> ** **
>
>
>
> --
> ------------------------------------------------
> Andreas Tai
> Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
> Floriansmuehlstrasse 60, D-80939 Munich, Germany
>
> Phone: +49 89 32399-389 | Fax: +49 89 32399-200
> http: www.irt.de | Email: tai@irt.de
> ------------------------------------------------
>
> registration court&  managing director:
> Munich Commercial, RegNo. B 5191
> Dr. Klaus Illgner-Fehns
> ------------------------------------------------
>
>