RE: TTML attribute syntax versus semantics

Both the clarification and the change would be good I think.

 

I agree making the restriction is a substantive, non-editorial change. However, any user putting non-inheritable attributes on an element for which there are no semantics, has nearly certainly done so in error.

 

                Mike

 

From: Glenn Adams [mailto:glenn@skynav.com] 
Sent: Monday, April 16, 2012 9:55 AM
To: Andreas Tai
Cc: public-tt; Michael A Dolan; Sean Hayes
Subject: 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 <tel:%2B1-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 <tel:%2B49%2089%2032399-389>  | Fax: +49 89 32399-200 <tel:%2B49%2089%2032399-200> 
http: www.irt.de | Email: tai@irt.de
------------------------------------------------
 
registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------