W3C home > Mailing lists > Public > xmlschema-dev@w3.org > June 2002

abstract elements and late binding namespaces

From: Naomi Dushay <Naomi@cs.cornell.edu>
Date: Thu, 13 Jun 2002 16:51:14 -0400
Message-ID: <46D7B75B426D7C4C9432E3E96B7D9F6A0559CD@opus.cs.cornell.edu>
To: <xmlschema-dev@w3.org>

I'm stumped with a XML schema writing problem.

Conceptually, I've got different types of instance files that are similar, but not the same.  My design concept was to have a schema with some abstract elements, and then have a separate schema for each type of instance file that declares concrete elements to be substituted for the abstract ones.  

This is compounded because the "abstract" schema has no namespace.  The Schemas with concrete elements belong to a namespace, and the elements they use from the "abstract" schema should then be a part of the concrete namespace.

I *think* this is sound design, but I can't get it to validate. 

XMLSpy chokes on validation, saying that there are undefined values for the abstract types.  I can get XML spy to validate the schemas if I *import* rather than *include* the abstract schema in the concrete schema.  But then the instance doc won't validate because the root "records" element isn't declared anywhere.

XSV chokes on validation, claiming that it's expecting "[]" as content in the records element, and then tells me the header element is undeclared.  Similar tweaking with import and include statements doesn't make this error go away.

Topologi chokes on validation, too.


Here is my XML.


Schema with abstract elements:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">

	<xsd:element name="records">
	  <xsd:complexType>
		<xsd:sequence>
			<xsd:element ref="abstractHeader" />
			<xsd:element ref="abstractRecord" maxOccurs="unbounded" />
		</xsd:sequence>
	   </xsd:complexType>
	</xsd:element>

	<xsd:element name="abstractHeader" type="headerType" abstract="true"/>

	<xsd:element name="abstractRecord" type="recordType" abstract="true"/>

	<xsd:complexType name="headerType">
		<xsd:sequence>
			<xsd:element name="category" type="xsd:string" />
			<xsd:element name="link" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element name="namingAuthority" type="xsd:string" />
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="recordType">
		<xsd:sequence>
			<xsd:element name="reharvestID" type="xsd:string" />
			<xsd:element name="secondaryID" type="xsd:string" minOccurs="0" maxOccurs="unbounded" />
		</xsd:sequence>
	</xsd:complexType>

</xsd:schema>


Schema with concrete elements for "collection" type:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"  targetNamespace="http://the.namespace" xmlns:TNS="http://the.namespace" elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- NOTE:  for instance validation debugging, xsv seems happiest with import rather than include of DB_Insert_abstract -->
<!-- NOTE:  for instance validation debugging, XMLSpy says the schemas are okay, but chokes on records element in instance doc without include. -->
<!--                             but XMLSpy chokes on schema WITH include -->
	<xsd:include schemaLocation="abstract.xsd"/>
	<!-- the following import statement is redundant due to the include above, but it makes XSV happier -->
<!--
	<xsd:import  schemaLocation="abstract.xsd"/>
-->

	<xsd:element name="header" substitutionGroup="abstractHeader" type="TNS:collectionHeaderType"/>
	<xsd:element name="record" substitutionGroup="abstractRecord" type="TNS:collectionRecordType"/>

	<xsd:complexType name="collectionHeaderType">
		<xsd:complexContent>
			<xsd:restriction base="headerType">
				<xsd:sequence>
					<xsd:element name="category" type="xsd:string" fixed="collection" />
					<xsd:element name="link" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
					<xsd:element name="namingAuthority" type="xsd:string" />
				</xsd:sequence>
			</xsd:restriction>
		</xsd:complexContent>
	</xsd:complexType>

	<xsd:complexType name="collectionRecordType">
		<xsd:complexContent>
			<xsd:extension base="recordType">
				<xsd:sequence>
					<xsd:element name="responsibleEntityNA" type="xsd:string" />
					<xsd:element name="brandIconURL" type="xsd:string" />
					<xsd:element name="brandTitle" type="xsd:string" />
				</xsd:sequence>			
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

</xsd:schema>



Instance document for collection type:

<?xml version="1.0" encoding="UTF-8"?>
<TNS:records xmlns:TNS="http://the.namespace" xsi:schemaLocation="http://the.namespace concrete.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
	<TNS:header>
		<TNS:category>collection</TNS:category>
		<TNS:link linktype="collection" primary="true">oai:nsdl.org:nsdl.nsdl/00135</TNS:link>
		<TNS:namingAuthority>nsdl.nsdl</TNS:namingAuthority>
	</TNS:header>
	<TNS:record>
		<TNS:reharvestID>00002</TNS:reharvestID>
		<TNS:secondaryID>cornell.nsdl.collections/00002</TNS:secondaryID>
		<TNS:responsibleEntityNA>nsdl</TNS:responsibleEntityNA>
		<TNS:brandIconURL>default.gif</TNS:brandIconURL>
		<TNS:brandTitle>NSDL</TNS:brandTitle>
	</TNS:record>
	<TNS:record>
		<TNS:reharvestID>00004</TNS:reharvestID>
		<TNS:secondaryID>cornell.nsdl.collections/00004</TNS:secondaryID>
		<TNS:responsibleEntityNA>nsdl</TNS:responsibleEntityNA>
		<TNS:brandIconURL>default.gif</TNS:brandIconURL>
		<TNS:brandTitle>NSDL</TNS:brandTitle>
	</TNS:record>
</TNS:records>
Received on Thursday, 13 June 2002 16:51:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:31 GMT