Impact of xs:redefine

I think there is probably a need, in both XSLT 2.0 and XQuery 1.0, to place
constraints on the use of xs:redefine in imported schemas.

The specifications generally assume that schema components are identified
uniquely by their expanded QName. However, if one query module imports
schema1.xsd, and another query module imports schema2.xsd, and schema1.xsd
redefines schema2.xsd, then the two query modules are using different
definitions of the same named types. This means that when a node is
annotated with a QName, we don't know whether it was validated against the
original type or the redefined type.

There don't appear to be any existing rules that cover this.

In XSLT 2.0, I think it's reasonably easy to fix, because (a) the set of
imported types is the same in all stylesheet modules, and (b) we define the
semantics of xsl:import-schema in terms of importing a single composite
schema, which means that the redefined definitions are used throughout. The
only problem that arises is when source documents arrive that have been
validated against an "unredefined" version of the schema; these may carry
type annotations that are inconistent with the redefined types. This is
essentially the same problem as occurs when different versions of a schema
are used in xsl:import-schema and in source document validation, and we can
disallow it under the same provision.

In XQuery 1.0 it's a little more difficult, because each query module has
its own static context, but it can still be done under the rule that all
versions of a single type definition must be consistent. This amounts to
saying (a) it's not allowed for one module to import schema1.xsd and for
another module to import a schema that redefines schema1.xsd, and (b) the
implementation must (?) detect when this happens. But is this restriction
acceptable?

Michael Kay

Received on Sunday, 4 January 2004 14:14:55 UTC