RE: Permit (greedy) conflicting wildcards

> > So in this sense you're right: I'm trying to find rules 
> that allow the 
> > schema as a whole to be extended while retaining confidence 
> that the 
> > assumptions I made at query compile time relating to type- 
> safety are 
> > still true when the query is executed. I'm trying to do this by 
> > freezing the parts of the schema on which compiled queries depend.
> 
> Unless I'm misunderstanding, <xs:redefine> is completely 
> incompatible with this model

Not completely incompatible: you can use xs:redefine to redefine a component
so long as you haven't yet used the component. Once you've used the
component, for example to do static type inferencing as described in the
XQuery formal semantics, you'd better not allow the component to be
redefined. (That's just the same as not allowing redefinition in the middle
of a validation episode).

>I'm not sure why something like a Not In Schema wildcard is more than a
minor additional compliction

Perhaps it is just a "minor additional complication", and if the XQuery type
system can cope with the horrors of nillability then it can probably cope
with this too. But I'm not yet convinced it's a minor complication that we
actually need. I think that asking users to say "anything except X, Y and Z"
is cleaner than allowing them to say "anything so long as there's no
[global?] element declaration for it in the schema" (even if it's more
verbose) because you've then got a meaning that doesn't change with the
direction of the wind.

Michael Kay
http://www.saxonica.com/