- From: Andreas Tai <tai@irt.de>
- Date: Wed, 04 Sep 2013 21:58:32 +0200
- To: Michael Dolan <mdolan@newtbt.com>
- CC: 'TTWG' <public-tt@w3.org>, glenn@skynav.com
- Message-ID: <522790E8.4040206@irt.de>
Hi Mike,
I understand now where you are coming from and after re-thinking the
issue I tend to agree that setting the value to "strict" would result in
the lesser evil.
I agree with the second point of your concern: the current schema will
not detect misspelled TTML attributes. tts:color and tts:colour would
both validate. If the processContents attribute of xs:anyAttribute is
set to strict this will give a validation error (unless somebody defines
the element colour in the same targetnamespace
http://www.w3.org/ns/ttml#styling, but this is something he should not do).
I agree with Glenn that his indeed changes the original definition of
the Abstract document type. TTML is right now what is called an open
content model and you have a lot of freedom to put in your own "stuff".
But possibly it needs further discussion how open it really should be.
If the value is set to strict you have to know which "foreign namespace"
attributes you expect and than integrate the schema for those attributes
in your validation process. You are not prepared to get XML attributes
with qualified names you don´t "know". But possibly in practice this
reflects the context of use? You loose flexibility but you gain a more
predictable content model (and this does not affect only schema validation).
On the value of XML Schema validation I have a different point of view.
The advantage to use standard XML technologies like XML Schema 1.0
should not be under estimated. I agree that the dedicated TTML validator
from Glenn will be very helpful. But implementers will also look for
validation mechanisms that are built in their parsers already. Possibly
not are willing to integrate an extra validation tool.
The proposed solution from Glenn will not work.
The model group schema components with the compositors all, sequence or
choice can only be used for the content model of elements. You can place
multiple namespace in one xs:anyAttribute e.g.
<xs:anyAttribute namespace="http://www.w3.org/ns/ttml#styling
http://www.w3.org/ns/ttml#parameter" processContents="strict"/>
But you can not combine it with an other xs:anyAttribute like the following
<xs:anyAttribute namespace="http://www.w3.org/ns/ttml#styling
http://www.w3.org/ns/ttml#parameter" processContents="strict"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
This would violate the ambiguity constraints:
3.10.2 XML Representation of Wildcard Schema Components
Wildcards are subject to the same ambiguity constraints (Unique Particle
Attribution (§3.8.6)) as other content model particles: If an instance
element could match either an explicit particle and a wildcard, or one
of two wildcards, within the content model of a type, that model is in
error.
If there would be a tts:colour attribute ("tts" bound to the namespace
"http://www.w3.org/ns/ttml#styling") in an element like tt:style it
would not be unambiguous if it should be validated against the first or
the second xs:anyAttribute wildcard.
Best regards,
Andreas
Am 03.09.2013 19:48, schrieb Michael Dolan:
>
> This issue is about commercial validator behavior and what are the
> least worst side affects when validating TTML documents with foreign
> namespace attributes. This is not about TTML document conformance -
> the schema is not authoritative. It’s just a tool. Sorry for any
> misunderstanding.
>
> The issue is only about which side affects you prefer in your schema
> validation:
>
> 1.Fail to properly validate the use of foreign namespace attributes
> unless a schema is available; or
>
> 2.Fail to properly reject forbidden TTML attributes (e.g. <tt>), or
> misspelled permitted TTML attributes.
>
> I prefer #1 over #2, but perhaps it is a matter of personal or
> application preference. As long as there is no implication that the
> W3C schema is authoritative, then it doesn’t really matter, I guess.
>
> Regards,
>
> Mike
>
> *From:*Andreas Tai [mailto:tai@irt.de]
> *Sent:* Monday, September 02, 2013 2:50 AM
> *To:* Glenn Adams
> *Cc:* Michael Dolan; TTWG
> *Subject:* Re: schemas too "lax"
>
> Hi Glenn, Mike,
>
> I agree with Glenn that the value "lax" best matches the original
> intention. TTML does not make any provisions about the validation of
> foreign namespace elements. An XML schema is no requirement for
> foreign namespace elements. Therefore it is possible that document
> authors include foreign namespace elements (e.g. some metadata) that
> are not specified in any schema or written specification.
>
> It is as well probable that implementations take a TTML
> subset/derivation (e.g. Subset A) as reference. If this implementation
> gets a TTML document that take Subset B as a reference where for
> example some extra metadata elements are defined it will just ignore
> them and process the document without any errors.
>
> It could be helpful to dig a bit deeper why some commercial parsers do
> not conform to the XSD standard. If this can not be fixed an
> additional note may be helpful (e.g. that in some application contexts
> the processContents attribute of xs:any and xs:anyAttribute may be set
> to "strict").
>
> Best regards,
>
> Andreas
>
>
> Am 01.09.2013 05:20, schrieb Glenn Adams:
>
> Sorry, hit the Send button prematurely. See more inline:
>
> On Sat, Aug 31, 2013 at 9:17 PM, Glenn Adams <glenn@skynav.com
> <mailto:glenn@skynav.com>> wrote:
>
> On Sat, Aug 31, 2013 at 11:21 AM, Michael Dolan <mdolan@newtbt.com
> <mailto: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 type '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 respect 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
>
> In conclusion, there clearly are commercial validators that do
> respect lax semantics. Perhaps the one you are using should be
> replaced with a newer model.
>
> 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 <tel:%2B1-858-882-7497>
>
> mdolan@newtbt.com <mailto:mdolan@newtbt.com>
>
>
>
>
> --
> ------------------------------------------------
> Andreas Tai
> Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
> Floriansmuehlstrasse 60, D-80939 Munich, Germany
>
> Phone: +49 89 32399-389 | Fax: +49 89 32399-200
> http:www.irt.de <http://www.irt.de> | Email:tai@irt.de <mailto:tai@irt.de>
> ------------------------------------------------
>
> registration court& managing director:
> Munich Commercial, RegNo. B 5191
> Dr. Klaus Illgner-Fehns
> ------------------------------------------------
--
------------------------------------------------
Andreas Tai
Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
Floriansmuehlstrasse 60, D-80939 Munich, Germany
Phone: +49 89 32399-389 | Fax: +49 89 32399-200
http: www.irt.de | Email: tai@irt.de
------------------------------------------------
registration court& managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------
Received on Wednesday, 4 September 2013 20:07:41 UTC