Re: TTML attribute syntax versus semantics

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