RE: TTML attribute syntax versus semantics

ISSUE-167<https://www.w3.org/AudioVideo/TT/tracker/issues/167> added to database


From: Michael A Dolan [mailto:mdolan@newtbt.com]
Sent: 13 April 2012 17:48
To: public-tt@w3.org
Subject: TTML attribute syntax versus semantics

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)