BUGS in MS Implementation of XmlSchema:

001. Does not allow duplicate values in lists for final* and block* attributes. 
   For example "restriction restriction" is not allowed even though its a valid
   value for blockDefault.

002. Resets the minOccurs to 0 if maxOccurs="0", whereas it should raise an error.

003. Allows abstract="true" in the a localElement whereas it is not allowed.
	<?xml version="1.0"?>
	<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xsdtesting" xmlns:x="http://xsdtesting" elementFormDefault="qualified">
		<xsd:element name="doc">
			<xsd:complexType>
				<xsd:sequence>
					<xsd:element name="elem1"/>
					<xsd:element abstract="true" name="elem2"/> <!--This element is not valid -->
				</xsd:sequence>
			</xsd:complexType>
		</xsd:element>
	</xsd:schema>

004. QName value constraint

	When xs:QName based type is specified to an attribute or element
	declaration, MS.NET fails to fill their {value constraints} (i.e.
	default or fixed value), even though they have those namespace 
	declaration by XmlSerializerNamespaces.

005.  derivation by extension of xs:all

	As it is discussed on w3c xmlschema-dev ML, MS System.Xml.Schema
	incorrectly allows <complexType><complexContent><extension><all>
	(i.e. XmlSchemaComplexContentExtension that contains XmlSchemaAll)
	whose base type contains non-empty particle. It is prohibited, 
	because, as XML Schema structures 3.4.2 (complex content Schema
	Component) {content type} 2.3, complex content extension creates 
	merged particles as a sequence, which never allows 'all' model group 
	as its content. 
	See: http://lists.w3.org/Archives/Public/xmlschema-dev/2002Oct/0156.html

	Below are incorrect W3C test suite in msxsdtest/complexType: ctH013.xsd,
	ctH019.xsd, ctH020.xsd, ctH021.xsd, ctH022.xsd, ctH023.xsd, ctJ001.xsd
	and in msxsdtest/ModelGroups: mgA016.xsd, mgO007.xsd (9 testcases).

006. xs:all minOccurs="0" not allowed

	W3C WXS Structures REC. says that model group xs:all is limited to have
	minOccurs=maxOccurs=1 in case of complexType's content type particle
	(see 3.8.6 All Group Limited), but this is corrected to allow 
	minOccurs=0. 
	(see E1-26 of http://www.w3.org/2001/05/xmlschema-errata#Errata1)

	Related msxsdtest is ParticlesEa022.xsd

007. Insufficient unique particle attribution of xs:any

	MS.NET allows <xs:choice><xs:any /><xs:element ... /></xs:choice>.

	Related msxsdtests are: ParticlesJd002.xsd, ParticlesJd003.xsd and
	ParticlesJd004.xsd. 
	ParticlesIb001.xsd is also related, but it is not necessarily said as
	incorrect. Both elements are of the same type, so *in a sense* they are
	the same declaration. MSV, XSV and I stands different.

008. Occurence Range OK (3.9.6) incorrectly assessed

	Particles that have maxOccurs="0" looks simply ignored *before*
	evaluating particle restriction valid, but it might get incorrect
	result. For example, it is regarded as valid (while 'e1' must occur 1
	time for the base 'bar' type):

	<xsd:complexType name="foo">
	<xsd:complexContent>
	<xsd:restriction base="bar">
		<xsd:choice>
			<xsd:element name="e1" minOccurs="0" maxOccurs="0"/>
			<xsd:element name="e2"/>
		</xsd:choice>
	</xsd:restriction>
	</xsd:complexContent>
	</xsd:complexType>

	<xsd:complexType name="bar">
	<xsd:choice>
		<xsd:element name="e1"/>
		<xsd:element name="e2"/>
	</xsd:choice>
	</xsd:complexType>

	Related msxsdtest is mgH014.xsd.

009. derived list incorrectly allowed

	"Type Derivation OK" by list simple type of atomic simple type is
	incorrectly assessed, when the list's {item type definition} (not 
	{base type definition} ) can be assessed as "Type Derivation OK". MSV,
	XSV and Xerces is not designed to allow such type derivation, and I
	think they are more correct than MS. That is, MS's schema engine is
	designed to use such schema typed class like:

	     public class Foo { int notAList; }

	Normally validates such xml into this class:

	     <Foo>1</Foo>

	MS validator consequently allows such instance like:

	     <foo xsi:type="int_list_type">1 2 3</foo>

	But it cannot be validated into that class Foo.

	Related msxsdtests are elemT015.xsd and elemT022.xsd.

010. derived union incorrectly allowed

	Similar problem to No.9 above resides in xs:union. Derived union type
	from atomic type is not naturally allowed.

	Related msxsdtest is elemT014.xsd.
