Re: schemas too "lax"

I wanted to update this thread a bit by mentioning that the recently
updated TTV Alpha 3 [1][2] now allows the use of additional schemas to
validate extension elements and attributes in non-TTML namespaces.

Depending on whether your Java platform supports newer JAXP implementations
or not, you can use either the xsi:schemaLocation mechanism or the new
--external-schema command line option.

If possible, it is better to use the --external-schema option since this
will work with either new or old JAXP. If you use the xsi:schemaLocation
mechanism, and your platform doesn't support the addition of non-pool
grammars (i.e., setting the
http://apache.org/xml/features/internal/validation/schema/use-grammar-pool-only
feature
to false), then a warning will be issued and the extension schema won't be
loaded.

The --external-schema option takes two arguments, a namespace URI (the
schema's target namespace) and the schema URL (location of schema's
top-level XSD resource). Multiple such options can be used to specify
multiple extension schemas.

G.

[1] https://github.com/skynav/ttv/releases/tag/ttv-1.0.0a3
[2] https://github.com/skynav/ttv/tree/ttv-1.0.0a3/dst



On Sat, Aug 31, 2013 at 9:17 PM, Glenn Adams <glenn@skynav.com> wrote:

>
> 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****
>>
>> ** **
>>
>> ** **
>>
>
>