This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I don't think this is currently supported by XSD 1.1. Not by XSD 1.0 as far as I know. I have a need to define both simpleType and complexType deriving from the same abstract type. Currently abstract types can only be complex, making a simpleType deriving from a complexType not possible.
Perhaps you could explain what you are trying to achieve, then we might be able to suggest a better way of achieving it. (In fact, I think a better place to raise the question would be on the xmlschema-dev mailing list - it only becomes a comment on the spec when we've had a discussion about the requirement and established that there is no way of doing what you want to do.) Michael Kay (personal response)
Here is the start of the thread I started on the subject on xml schema dev in late March: http://lists.w3.org/Archives/Public/xmlschema-dev/2007Mar/0034.html The discussion thread includes some options explored, but none of them seemed to fully address my requirements.
OK, I've read the thread (glad you pointed to it, wouldn't want to have to repeat all that!) As far as I can see you want to define an abstract type O such that every O has an OID child element, and in some concrete subtypes of O, OID will have attributes and in others it won't. So why can't you define the top-level type for OID as an abstract complex type with simple content having no attributes, and then derive from it (by extension) by adding attributes where needed?
Thank you for the comment. The XML Schema Working Group discussed this issue on our call today. In view of the suggestion in comment #3, it appears that the effect you need can be achieved without changes to the XSDL spec. In addition, introducing abstract simple types would involve what appears to us to be a great deal of complexity (much of it invisible in the spec), which we would gladly avoid at this point. There was also some uncertainty about whether allowing abstract simple types would actually do what you need, given that complex types with simple content have anyType, not the simple type of their content, as their {base type definition}. So we propose to close this issue without making any change to the spec. We hope that you are happy with the suggestion in comment #3 and thus are willing to accept our closing the issue without action. If so, you can so indicate by changing the status zof the issue to CONFIRMED. If you are unhappy and would like to register a formal appeal of the WG's decision, you can indicate that by changing the status to REOPENED. If we don't hear from you in the next month, we'll assume that you accept the WG's disposition of the issue.