mcs/class/System.XML/System.Xml.Schema/BUGS-MS.txt

   1 BUGS in MS Implementation of XmlSchema:\r
   2 \r
   3 001. Does not allow duplicate values in lists for final* and block* attributes. \r
   4    For example "restriction restriction" is not allowed even though its a valid\r
   5    value for blockDefault.\r
   6 \r
   7 002. Resets the minOccurs to 0 if maxOccurs="0", whereas it should raise an error.\r
   8 \r
   9 003. Allows abstract="true" in the a localElement whereas it is not allowed.\r
  10         <?xml version="1.0"?>\r
  11         <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xsdtesting" xmlns:x="http://xsdtesting" elementFormDefault="qualified">\r
  12                 <xsd:element name="doc">\r
  13                         <xsd:complexType>\r
  14                                 <xsd:sequence>\r
  15                                         <xsd:element name="elem1"/>\r
  16                                         <xsd:element abstract="true" name="elem2"/> <!--This element is not valid -->\r
  17                                 </xsd:sequence>\r
  18                         </xsd:complexType>\r
  19                 </xsd:element>\r
  20         </xsd:schema>\r
  21 \r
  22 004. QName value constraint\r
  23 \r
  24         When xs:QName based type is specified to an attribute or element\r
  25         declaration, MS.NET fails to fill their {value constraints} (i.e.\r
  26         default or fixed value), even though they have those namespace \r
  27         declaration by XmlSerializerNamespaces.\r
  28 \r
  29 005.  derivation by extension of xs:all\r
  30 \r
  31         As it is discussed on w3c xmlschema-dev ML, MS System.Xml.Schema\r
  32         incorrectly allows <complexType><complexContent><extension><all>\r
  33         (i.e. XmlSchemaComplexContentExtension that contains XmlSchemaAll)\r
  34         whose base type contains non-empty particle. It is prohibited, \r
  35         because, as XML Schema structures 3.4.2 (complex content Schema\r
  36         Component) {content type} 2.3, complex content extension creates \r
  37         merged particles as a sequence, which never allows 'all' model group \r
  38         as its content. \r
  39         See: http://lists.w3.org/Archives/Public/xmlschema-dev/2002Oct/0156.html\r
  40 \r
  41         Below are incorrect W3C test suite in msxsdtest/complexType: ctH013.xsd,\r
  42         ctH019.xsd, ctH020.xsd, ctH021.xsd, ctH022.xsd, ctH023.xsd, ctJ001.xsd\r
  43         and in msxsdtest/ModelGroups: mgA016.xsd, mgO007.xsd (9 testcases).\r
  44 \r
  45 006. xs:all minOccurs="0" not allowed\r
  46 \r
  47         W3C WXS Structures REC. says that model group xs:all is limited to have\r
  48         minOccurs=maxOccurs=1 in case of complexType's content type particle\r
  49         (see 3.8.6 All Group Limited), but this is corrected to allow \r
  50         minOccurs=0. \r
  51         (see E1-26 of http://www.w3.org/2001/05/xmlschema-errata#Errata1)\r
  52 \r
  53         Related msxsdtest is ParticlesEa022.xsd\r
  54 \r
  55 007. Insufficient unique particle attribution of xs:any\r
  56 \r
  57         MS.NET allows <xs:choice><xs:any /><xs:element ... /></xs:choice>.\r
  58 \r
  59         Related msxsdtests are: ParticlesJd002.xsd, ParticlesJd003.xsd and\r
  60         ParticlesJd004.xsd. \r
  61         ParticlesIb001.xsd is also related, but it is not necessarily said as\r
  62         incorrect. Both elements are of the same type, so *in a sense* they are\r
  63         the same declaration. MSV, XSV and I stands different.\r
  64 \r
  65 008. Occurence Range OK (3.9.6) incorrectly assessed\r
  66 \r
  67         Particles that have maxOccurs="0" looks simply ignored *before*\r
  68         evaluating particle restriction valid, but it might get incorrect\r
  69         result. For example, it is regarded as valid (while 'e1' must occur 1\r
  70         time for the base 'bar' type):\r
  71 \r
  72         <xsd:complexType name="foo">\r
  73         <xsd:complexContent>\r
  74         <xsd:restriction base="bar">\r
  75                 <xsd:choice>\r
  76                         <xsd:element name="e1" minOccurs="0" maxOccurs="0"/>\r
  77                         <xsd:element name="e2"/>\r
  78                 </xsd:choice>\r
  79         </xsd:restriction>\r
  80         </xsd:complexContent>\r
  81         </xsd:complexType>\r
  82 \r
  83         <xsd:complexType name="bar">\r
  84         <xsd:choice>\r
  85                 <xsd:element name="e1"/>\r
  86                 <xsd:element name="e2"/>\r
  87         </xsd:choice>\r
  88         </xsd:complexType>\r
  89 \r
  90         Related msxsdtest is groupG001.xsd and mgH014.xsd.\r
  91 \r
  92 009. derived list incorrectly allowed\r
  93 \r
  94         "Type Derivation OK" by list simple type of atomic simple type is\r
  95         incorrectly assessed, when the list's {item type definition} (not \r
  96         {base type definition} ) can be assessed as "Type Derivation OK". MSV,\r
  97         XSV and Xerces is not designed to allow such type derivation, and I\r
  98         think they are more correct than MS. That is, MS's schema engine is\r
  99         designed to use such schema typed class like:\r
 100 \r
 101              public class Foo { int notAList; }\r
 102 \r
 103         Normally validates such xml into this class:\r
 104 \r
 105              <Foo>1</Foo>\r
 106 \r
 107         MS validator consequently allows such instance like:\r
 108 \r
 109              <foo xsi:type="int_list_type">1 2 3</foo>\r
 110 \r
 111         But it cannot be validated into that class Foo.\r
 112 \r
 113         Related msxsdtests are elemT015.xsd and elemT022.xsd.\r
 114 \r
 115 010. derived union incorrectly allowed\r
 116 \r
 117         Similar problem to No.9 above resides in xs:union. Derived union type\r
 118         from atomic type is not naturally allowed.\r
 119 \r
 120         Related msxsdtest is elemT014.xsd.\r
 121 \r
 122 011. schema finalDefault with list and/or union\r
 123 \r
 124         In xs:schema, finalDefault = (#all | List of (extension | restriction)),\r
 125         but MS.NET failed to handle blockDefault='list' as an error.\r
 126         (union as well.)\r
 127 \r
 128         Related msxsdtest is stF034.xsd and stF036.xsd.\r
 129 \r
 130 012. derived types cannot duplicate fixed facet\r
 131 \r
 132   If you have a facet like <xsd:minLength value="5" fixed="true" />, you should\r
 133   be able to have <xsd:minLength value="5" /> in restrictions of it, as long as\r
 134   the values are the same. MS says: \r
 135     "Base type has {fixed} equal to true."\r
 136 \r
 137   XML-Schema part2 Datatype, 4.3.2.1: \r
 138     "If {fixed} is true, then types for which the current type is the {base\r
 139     type definition} cannot specify a value for minLength other than\r
 140     {value}."\r
 141 \r
 142   Which implies that you can specify a value for minLength that is the same as\r
 143   {value}.\r
 144 \r
 145 013. Some facets are incorrectly allowed for list simple type.\r
 146 \r
 147         As to structures spec 3.14.6 Derivation Valid (Simple) 2.2, only length,\r
 148         minLength, maxLength, pattern and enumeration are allowed. However, MS\r
 149         implementation allows whitespace (and possibly and so on).\r
 150 \r