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)