schemas for vxml grammars need updating

[cmsmcq]

We have made changes to the grammar of ixml since the schemas in the /schemas directory were generated; the schemas need to be updated.

I don't know whether we should try to make building the schemas part of the build process when the spec is updated, or not. Thoughts welcome.

[ndw]

Yes, they should be built automatically.

But also, we probably need to get a copy of the 1.0 versions and put them somewhere under the 1.0/ spec directory.

[cmsmcq]

Hmm. I guess we probably also have to think a bit about quality assurance for the schemas (and maybe the grammars). (Sigh.)

For the schemas, I guess there are several kinds of tests we could construct, some of which could reuse material in the existing test collections. Some would require us to agree (for testing purposes) on a reference implementation of a vxml-to-ixml serializer.

• The XML form constructed from any error-free grammar should be valid against the schema.
• An ixml grammar serialized from any valid vxml grammar should be accepted by a conforming ixml processor. (This should be possible for the spec grammar, even though it's not guaranteed possible in the general case.)
• Given an invalid vxml grammar, either the reference serializer should raise an error or the resulting character sequence should be rejected by a conforming ixml processor.

In short: translations into XML should preserve grammaticality, and translations from XML into ixml should preserve grammaticality and ungrammaticality.

For grammars, well, once processors are adjusted to use a new spec grammar, the existing test suite probably provides some assurance that a revised grammar still works.

It might be nice to have some tests we could run to check a new grammar even before processors are updated. We could construct a test catalog that just asked processors to parse all of the error-free test-set grammars in the existing collection of tests using the new grammar. I think that should provide worthwhile results for any grammar change which

• (a) is meant to preserve grammaticality in existing grammars,
• (b) does not use any new constructs, and
• (c) does not change the meaning of any existing construct.

If condition (a) is not met, then it can't be guaranteed that the test-set grammars being parsed should be accepted. If (b) is not met, then existing processors won't be able to parse against the new spec grammar until they are updated. If (c) is not met, then the expected XML output for the test cases will not match what a current processor will produce. But the likelihood of these conditions holding for most changes we might want to make to the spec grammar seems high.