- From: Glenn Adams <glenn@skynav.com>
- Date: Fri, 10 Feb 2012 13:56:15 -0700
- To: Philippe Le Hegaret <plh@w3.org>
- Cc: Michael A Dolan <mdolan@newtbt.com>, public-tt@w3.org
- Message-ID: <CACQ=j+dVK3rogEuQyz6uuh5bYZPM0KDQqm0i6jJRZs6KDHin7A@mail.gmail.com>
As a reminder, we had actually included prose describing this issue at [1]: see the Note at the end of 4.1: [1] http://www.w3.org/TR/ttaf1-dfxp/#dfxp-content-doctype Also, we defined a Valid Abstract Document Instance (of a TTML document) in [2] as being assessed *after* pruning foreign elements and attributes. [2] http://www.w3.org/TR/ttaf1-dfxp/#doctypes So from a formal definition perspective, no change is needed; however, I agree that for practical content development purposes, it is useful to have both XSD and RNG schemas that permit foreign namespace elements and attributes. On Thu, Feb 9, 2012 at 2:37 PM, Philippe Le Hegaret <plh@w3.org> wrote: > Hi Michael, > > following this morning decision to relax the XML schema for TTML 1.0, I > updated the errata page for TTML 1.0: > http://www.w3.org/2010/11/ttml-issues.html > > I also added links on the errata page for new zip archives of the relax > NG and XML schema files. > > In addition, the editor's copy of TTML 1.0 is up-to-date and include all > errata: > > http://dev.w3.org/cvsweb/~checkout~/2008/tt/spec/ttaf1-dfxp.html?content-type=text/html;charset=utf-8 > > Regards, > > Philippe > > On Fri, 2012-01-27 at 08:10 -0800, Michael A Dolan wrote: > > 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 = string > > > > xml:id = ID > > > > xml:lang = string > > > > xml:space = (default|preserve) : default > > > > {any attribute in TT Parameter namespace} > > > > {any attribute not in default or any TT namespace}> > > > > Content: head?, 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, 10 February 2012 20:57:03 UTC