Re: schemas too "lax"

On Sat, Aug 31, 2013 at 11:21 AM, Michael Dolan <mdolan@newtbt.com> wrote:

> The current schemas don’t reject attributes on elements that:****
>
> ** **
>
> **1.       **are undefined (e.g. junk:junk=”junk”),
>
Since this is permissible, I'm not sure whether we want to reject. Keep in
mind that TT validity is assessed only after removing foreign namespace
elements and attributes. If we reject these by making the schema more
restrictive, then it may produce a false negative assessment.

The current use of processContents="lax" is defined by XSD 1.0 as follows:

"If the item has a uniquely determined declaration available, it must be ·
valid· <http://www.w3.org/TR/xmlschema-1/#key-vn> with respect to that
definition, that is, ·validate· <http://www.w3.org/TR/xmlschema-1/#key-vn> if
you can, don't worry if you can't."

IMO, this seems the logically correct choice.

> ****
>
> **2.       **typos of valid attributes (e.g. ttm:descr=”t”), and
>
Unfortunately, this is a limitation of relying upon an XSD schema to solely
determine validity. This is only one of a number of validity constraints
not expressible using XSD 1.0 schemas. However, this particular invalidity
is testable outside of XSD, and the TTV tool does test and report this as
an error [1].

[1]
https://github.com/skynav/ttv/blob/master/tst/resources/com/skynav/ttv/app/ttml10-invalid-metadata-unknown-attributes.xml

> ****
>
> **3.       **valid attributes from TTML namespaces that are forbidden
> (e.g. <tt ttm:desc=”t” …>).
>
Again, this is an XSD 1.0 limitation, and requires testing beyond XSD
usage. The TTV tool does test and report this as an error [2].

[2]
https://github.com/skynav/ttv/blob/master/tst/resources/com/skynav/ttv/app/ttml10-invalid-metadata-disallowed-attributes.xml


> ****
>
> ** **
>
> I understand that this was intentional to enable foreign namespace
> attributes without requiring their schemas.****
>
> ** **
>
> This negative side effect stems from the use ##other and
> processContents=”lax” in combination with commercial validators not even
> trying to validate when the schemaLocation is actually provided (lax is
> supposed to be “best effort”, not “just forget all about it”).
>
I just tested use of lax validation of a "junk:junk" attribute using ant's
<schemavalidate/> task, which uses the platform's JAXP implementation.
Doing a bit of snooping, I'm using:

$ java -version
java version "1.6.0_51"
Java(TM) SE Runtime Environment (build 1.6.0_51-b11-457-11M4509)
Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-457, mixed mode)

$ java com.sun.org.apache.xerces.internal.impl.Version
Xerces-J 2.6.2

So, back to "junk:junk", I find that it is indeed being processed with use
of lax processing. I've tested it using two techniques, and both work:

*Option #1* using xsi:schemaLocation in the instance document, e.g.

<tt tts:extent="640px 480px" xml:lang="en"
  xmlns="http://www.w3.org/ns/ttml"
  xmlns:tts="http://www.w3.org/ns/ttml#styling"
*  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"*
*  xsi:schemaLocation="http://junk.com/junk junk.xsd"*
  xmlns:junk="http://junk.com/junk" junk:junk="-3"/>

and

*Option #2* using ant's <schemavalidate/> task's <schema/> child element
(having removed the above xsi:schemaLocation embedded in instance document):

<schemavalidate fullchecking="true" warn="true">
  <schema namespace="http://www.w3.org/ns/ttml" file="${xsd.schema}"/>
*  <schema namespace="http://junk.com/junk"
file="${examples.dir}/junk.xsd"/>*
  <fileset dir="${examples.dir}">
    <include name="ex1.xml"/>
  </fileset>
</schemavalidate>

If don't create a junk.xsd file, then I get the following using Option #1:

$ ant validate-example-1
Buildfile: /Users/glenn/work/w3c/ttml/ttml1/spec/build.xml

validate-example-1:
[schemavalidate]
/Users/glenn/work/w3c/ttml/ttml1/spec/examples/ex1.xml:6:52:
schema_reference.4: Failed to read schema document 'junk.xsd', because 1)
could not find the document; 2) the document could not be read; 3) the root
element of the document is not <xsd:schema>.

BUILD SUCCESSFUL
Total time: 0 seconds

For Option #2, I get:

$ ant validate-example-1
Buildfile: /Users/glenn/work/w3c/ttml/ttml1/spec/build.xml

validate-example-1:

BUILD FAILED
/Users/glenn/work/w3c/ttml/ttml1/spec/build.xml:128: File not found:
/Users/glenn/work/w3c/ttml/ttml1/spec/examples/junk.xsd

Total time: 0 seconds

If I do create junk.xsd with the following contents:

<xs:schema targetNamespace="http://junk.com/junk"
  xml:lang="en" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:attribute name="junk" type="xs:positiveInteger"/>
</xs:schema>

then retry validation, I get:

For Option #1:

$ ant validate-example-1
Buildfile: /Users/glenn/work/w3c/ttml/ttml1/spec/build.xml

validate-example-1:
[schemavalidate]
/Users/glenn/work/w3c/ttml/ttml1/spec/examples/ex1.xml:6:52:
cvc-minInclusive-valid: Value '-3' is not facet-valid with respect to
minInclusive '1' for typ\
e 'positiveInteger'.
[schemavalidate]
/Users/glenn/work/w3c/ttml/ttml1/spec/examples/ex1.xml:6:52:
cvc-attribute.3: The value '-3' of attribute 'junk:junk' on element 'tt' is
not valid with res\
pect to its type, 'positiveInteger'.

BUILD FAILED
/Users/glenn/work/w3c/ttml/ttml1/spec/build.xml:128:
/Users/glenn/work/w3c/ttml/ttml1/spec/examples/ex1.xml is not a valid XML
document.

Total time: 0 seconds


For Option #2:

$ ant validate-example-1
Buildfile: /Users/glenn/work/w3c/ttml/ttml1/spec/build.xml

validate-example-1:
[schemavalidate]
/Users/glenn/work/w3c/ttml/ttml1/spec/examples/ex1.xml:4:52:
cvc-minInclusive-valid: Value '-3' is not facet-valid with respect to
minInclusive '1' for typ\
e 'positiveInteger'.
[schemavalidate]
/Users/glenn/work/w3c/ttml/ttml1/spec/examples/ex1.xml:4:52:
cvc-attribute.3: The value '-3' of attribute 'junk:junk' on element 'tt' is
not valid with res\
pect to its type, 'positiveInteger'.

BUILD FAILED
/Users/glenn/work/w3c/ttml/ttml1/spec/build.xml:128:
/Users/glenn/work/w3c/ttml/ttml1/spec/examples/ex1.xml is not a valid XML
document.

Total time: 0 seconds




****
>
> ** **
>
> I believe that the negative side effects of this “feature” in practice far
> outweigh its benefits and would like to change this to “strict”.****
>
> ** **
>
> If a user is going to the trouble to use XML validation with the TTML
> schema, why wouldn’t they also ensure that they have schemas handy for the
> foreign namespaces in use?****
>
> ** **
>
> Regards,****
>
> ** **
>
>                 Mike****
>
> ** **
>
> Michael A DOLAN****
>
> TBT, Inc.    PO Box 190****
>
> Del Mar, CA 92014****
>
> (m) +1-858-882-7497****
>
> mdolan@newtbt.com****
>
> ** **
>
> ** **
>