- From: Michael A Dolan <mdolan@newtbt.com>
- Date: Fri, 27 Jan 2012 08:10:52 -0800
- To: <public-tt@w3.org>
- Message-ID: <043a01ccdd0e$3f3ec260$bdbc4720$@newtbt.com>
Hello again- Since there seems to be some receptiveness to addressing schema issues, here is another one. TTML allows any foreign namespace attribute on the elements. For example, note the green-highlighted text below: <tt tts:extent <http://www.w3.org/TR/ttaf1-dfxp/#style-attribute-extent> = string xml:id <http://www.w3.org/TR/ttaf1-dfxp/#content-attribute-id> = ID <http://www.w3.org/TR/ttaf1-dfxp/#content-attribute-lang> xml:lang = string xml:space <http://www.w3.org/TR/ttaf1-dfxp/#content-attribute-space> = (default|preserve) : default {any attribute in TT Parameter namespace} {any attribute not in default or any TT namespace}> Content: head <http://www.w3.org/TR/ttaf1-dfxp/#document-structure-vocabulary-head> ?, body <http://www.w3.org/TR/ttaf1-dfxp/#document-structure-vocabulary-body> ? </tt> However, the schema is constructed to reject all such attributes. For example, the following XML would be rejected, even though it is clearly permitted by the Recommendation: <p cff:forcedDisplayMode="true">translated from Klingon</p> As a result, those working on derived schemas from TTML that add attributes to the existing elements are forced to do unusual things in their schemas to work around this and/or create schemas from scratch. And such instance documents cannot be validated against TTML since they are (wrongly) rejected. Therefore, for the deployments I am aware of, the TTML schema is not useful as is except to the schema developer to borrow pieces of it perhaps. The obvious way to correct this would be to add anyAttribute="##other" to the element definitions, however, this would then enable false validations of non-default TT namespace elements (e.g. ttm: ), which is undesirable. So this issue is a bit trickier to address than my last one about tts:extent. I believe it would be beneficial to the industry for W3C to correct this in some manner to provide a schema that can be used by those developing derived (but TTML conformant) designs. Regards, Mike Michael A DOLAN Television Broadcast Technology, Inc PO Box 190, Del Mar, CA 92014 USA +1-858-882-7497 (m)
Received on Friday, 27 January 2012 16:11:27 UTC