ISSUE-167: allowing attributes that have no semantics on specific elements

attribute syntax

allowing attributes that have no semantics on specific elements

State:
OPEN
Product:
TTML2
Raised by:
Mike Dolan
Opened on:
2012-04-13
Description:
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)
Related Actions Items:
No related actions
Related emails:
  1. {minutes} TTML Meeting of 24/10/13 (from glenn@skynav.com on 2013-10-24)
  2. RE: TTML Agenda for 24/10/13 (from mdolan@newtbt.com on 2013-10-23)
  3. TTML Agenda for 24/10/13 (from nigel.megitt@bbc.co.uk on 2013-10-23)
  4. Re: TTML Minutes for 25/09/13 (from tmichel@w3.org on 2013-09-27)
  5. RE: TTML Minutes for 25/09/13 (from silviapfeiffer1@gmail.com on 2013-09-27)
  6. RE: TTML Minutes for 25/09/13 (from nigel.megitt@bbc.co.uk on 2013-09-26)
  7. TTML Agenda for 25/09/13 (from Sean.Hayes@microsoft.com on 2013-09-25)
  8. TTML Agenda for 19/09/13 (from Sean.Hayes@microsoft.com on 2013-09-19)
  9. No Meeting today 12-09-13 (from Sean.Hayes@microsoft.com on 2013-09-12)
  10. Minutes for 05/09/13 (from nigel.megitt@bbc.co.uk on 2013-09-05)
  11. Agenda for 05/09/13 (from glenn@skynav.com on 2013-09-04)
  12. RE: TTML Agenda for 29/08/13 (from mdolan@newtbt.com on 2013-08-28)
  13. TTML Agenda for 29/08/13 (from glenn@skynav.com on 2013-08-28)
  14. Minutes TTWG Aug 16, 2012 (from momartin@microsoft.com on 2012-08-17)
  15. RE: TTML Agenda for 15/8/12 (from momartin@microsoft.com on 2012-08-16)
  16. Fwd: TTML Agenda for 15/8/12 (from geoff_freed@wgbh.org on 2012-08-16)
  17. Re: TTML Agenda for 15/8/12 (from geoff_freed@wgbh.org on 2012-08-16)
  18. TTML Agenda for 15/8/12 (from Sean.Hayes@microsoft.com on 2012-08-16)
  19. RE: TTML attribute syntax versus semantics (from Sean.Hayes@microsoft.com on 2012-04-13)
  20. ISSUE-167 (attribute syntax): allowing attributes that have no semantics on specific elements [DFXP v.next] (from sysbot+tracker@w3.org on 2012-04-13)

Related notes:

Addressed. https://dvcs.w3.org/hg/ttml/rev/9058209ad63f

See also https://github.com/skynav/ttv/issues/12.

Glenn Adams, 25 Aug 2013, 00:59:02

[glenn]: mike should review, but WG appears satisfied

19 Sep 2013, 14:54:52

Although a warning note is an improvement, I'm not sure a reader will find it any easier than understanding in general the details of inheritance and undefined semantics. I believe we should consider forbidding non-inheritable attributes from being placed on elements for which there are no defined semantics. This would theoretically be non-backwards compatible with TTML1, but any document doing this was probably authored in error. The XML schema can be updated to reflect this change and thus flag such usage.

Mike Dolan, 3 Oct 2013, 16:31:54

Raised by Sean Hayes

Philippe Le Hégaret, 24 Oct 2013, 15:21:22

NIgel: P2 for Mike and see if he pushes it

Philippe Le Hégaret, 24 Oct 2013, 15:24:38

This issue is not resolved per my comment above. This issue has led to poor/fatal interop, e.g. the erroneous and vendor-specific semantics for origin and extent on <p>. Non-inheritable attributes with no semantics on an element should not be permitted.

Mike Dolan, 1 Nov 2013, 17:49:04

Changelog:

Created issue 'allowing attributes that have no semantics on specific elements' nickname attribute syntax owned by Sean Hayes on product DFXP v.next, description '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)
' non-public

Sean Hayes, 13 Apr 2012, 16:54:20

Status changed to 'pending review'

Glenn Adams, 25 Aug 2013, 00:59:02

Status changed to 'open'

26 Sep 2013, 14:41:46

Owner changed to 'Mike Dolan'

Philippe Le Hégaret, 24 Oct 2013, 15:24:38


David Singer <singer@apple.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, Chairs, Thierry Michel <tmichel@w3.org>, Philippe Le Hégaret <plh@w3.org>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: index.php,v 1.323 2013-12-19 14:47:09 dom Exp $