Successive restriction of enumerated content in complex types

In my xbrli namespace I have the following type:

 <complexType name="stringItemType">
  <simpleContent>
   <extension base="string">
    <attribute name="nonNumericContext" type="IDREF" use="required"/>
    <anyAttribute namespace="##other" processContents="lax"/>
   </extension>
  </simpleContent>
 </complexType>

I now define a new type in my dt namespace as follows:

 <complexType name="accountTypeItemType">
  <simpleContent>
   <restriction base="xbrli:stringItemType">
    <enumeration value="account"/>
    <enumeration value="bank"/>
    <enumeration value="employee"/>
    <enumeration value="customer"/>
    <enumeration value="job"/>
    <enumeration value="vendor"/>
    <enumeration value="fixed-asset"/>
   </restriction>
  </simpleContent>
 </complexType>

I now try to further restrict it in another namespace thus:

 <complexType name="moreRestrictedAccountTypeItemType">
  <simpleContent>
   <restriction base="dt:accountTypeItemType">
    <enumeration value="account"/>
    <enumeration value="bank"/>
    <enumeration value="employee"/>
   </restriction>
  </simpleContent>
 </complexType>

XML-Spy chokes on this by highlighting

base="dt:accountTypeItemType"

and giving the error message "simpleContent cannot have a base that is a
complexType with complexContent" which makes no sense to me because
accountTypeItemType does not have complexContent.

A JAXP 1.2/Xerces 2 validator says this is valid XML Schema

Is it?

Thanks

Hugh




************************************************************************

If you received this e-mail in error please delete it and notify the sender as soon as possible. The contents of this e-mail may be confidential and the unauthorized use, copying, or dissemination of it and any attachments to it, is prohibited.

Internet communications are not secure and Hyperion does not, therefore, accept legal responsibility for the contents of this message nor for any damage caused by viruses. The views expressed here do not necessarily represent those of Hyperion.

For more information about Hyperion, please visit our Web site at www.hyperion.com

Received on Tuesday, 25 March 2003 11:48:40 UTC