W3C home > Mailing lists > Public > public-tt@w3.org > February 2012

Re: TTML XSD vallidation and extension problem (ISSUE-150)

From: Glenn Adams <glenn@skynav.com>
Date: Fri, 10 Feb 2012 13:56:15 -0700
Message-ID: <CACQ=j+dVK3rogEuQyz6uuh5bYZPM0KDQqm0i6jJRZs6KDHin7A@mail.gmail.com>
To: Philippe Le Hegaret <plh@w3.org>
Cc: Michael A Dolan <mdolan@newtbt.com>, public-tt@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 10 February 2012 20:57:04 GMT