The behavior you describe can be obtained by declaring 'octave' this way:
<xs:complexType name="octave" >
<xs:choice>
<xs:any minOccurs="0"
maxOccurs="unbounded"
namespace="http://www.website.com/main"
processContents="strict" />
</xs:choice>
<xs:attribute name="id"
type="xs:string"
use="optional" />
</xs:complexType>
and declaring query as a global element:
<xs:element name="query" type="xs:string" />
Since the query element you are defining is in namespace http://www.website.com/main
, it is accepted by the wildcard and there is no pressing need, from the point of view of the 'octave' type, to include an element reference to it in the choice.
This design does have the disadvantage of making 'query' accessible to all existing wildcards which match arbitrary elements in namespace http://www.website.com/main
. If it matters a great deal that 'query' should appear only as a child of element 'octave' and other elements of the same type, then you might consider making the local 'query' element unqualified:
<xs:complexType name="octave" >
<xs:choice>
<xs:element name="query"
type="xs:string"
form="unqualified"/>
<xs:any minOccurs="0"
maxOccurs="unbounded"
namespace="http://www.website.com/main"
processContents="strict" />
</xs:choice>
<xs:attribute name="id"
type="xs:string"
use="optional" />
</xs:complexType>
Since the declaration of 'query' no longer generates an element declaration whose expanded name is in the 'main' namespace, it no longer competes with the wildcard.
You might also move to XSD 1.1, which relaxes the 'unique particle attribution' rule by saying that element declarations and references are matched in preference to wildcards and which thus makes your existing declaration legal.