Defining common wrapper elements across schemas

I'm having trouble writing a generic "wrapper" schema.

I've got a tool that consumes XML instances that need tool-specific 
metadata wrapped around a context-specific fragment defined in a user's 
schema. These schemas are designed outside of the tool and would thus 
know nothing about tool-specific metadata. For example,

<c:Content>
	<meta:Metadata/>
	<my:Stuff/>
</c:Content>

and

<c:Content>
	<meta:Metadata/>
	<other:Vocabularies/>
</c:Content>

In writing the schemas to validate these instances, my first 
inclination was to import all of the possible context schemas into the 
Content schema and declare the ContentType as such:

<xs:complexType name="ContentType">
	<xs:sequence>
		<xs:element ref="meta:Metadata"/>
		<xs:choice>
			<xs:element ref="my:Stuff"/>
			<xs:element ref="other:Vocabularies"/>
		</xs:choice>
	</xs:sequence>
</xs:complexType>

This is rather inflexible and inefficient, though, requiring the 
Content schema to keep track of all of its possible child schemas.

A substitutionGroup in the Content schema won't work because none of 
the substituted elements (e.g. my:Stuff, other:Vocabularies) share a 
common base type.

Finally, I created another layer of abstraction by creating 
StuffContent and VocabulariesContent schemas that import the Content 
and context schemas and extend the ContentType:

<xs:element name="Content" type="myc:ContentType"/>
<xs:complexType name="ContentType">
	<xs:complexContent>
		<xs:extension base="c:ContentType">
			<xs:sequence>
				<xs:element ref="std:Student"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>

However, this requires that the root content element be in the 
nonsensical myc namespace, rather than a more generic c namespace (as 
in the first code-snippet).

Is there another, simpler way to allow wrapper elements around elements 
from schemas that aren't known at design-time? (Does this question make 
any sense?).

Any help would be much appreciated.

- Justin Makeig

--
The Center for Document Engineering
University of California, Berkeley
http://cde.berkeley.edu/

Received on Thursday, 20 November 2003 03:46:04 UTC