| blob | cda2ebeb2dce6dede30f2d1c819ffe174d1ff7fb |
1 BUGS in MS Implementation of XmlSchema:\r
2 \r
3 Here we summarize bugs found in MS.NET, including some comment excerpt from\r
4 Microsoft development team (as of 2004/07).\r
5 \r
6 \r
7 001. Does not allow duplicate values in lists for final* and block* attributes. \r
8 For example "restriction restriction" is not allowed even though its a valid\r
9 value for blockDefault.\r
10 \r
11 (MS: This is fixed in .NET 2.0)\r
12 \r
13 \r
14 002. Resets the minOccurs to 0 if maxOccurs="0", whereas it should raise an error.\r
15 \r
16 (MS: This WON'T be fixed in .NET 2.0. MS users may depend on this bug.)\r
17 \r
18 \r
19 003. Allows abstract="true" in the a localElement whereas it is not allowed.\r
20 <?xml version="1.0"?>\r
21 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xsdtesting" xmlns:x="http://xsdtesting" elementFormDefault="qualified">\r
22 <xsd:element name="doc">\r
23 <xsd:complexType>\r
24 <xsd:sequence>\r
25 <xsd:element name="elem1"/>\r
26 <xsd:element abstract="true" name="elem2"/> <!--This element is not valid -->\r
27 </xsd:sequence>\r
28 </xsd:complexType>\r
29 </xsd:element>\r
30 </xsd:schema>\r
31 \r
32 (MS: This is fixed in .NET 2.0)\r
33 \r
34 \r
35 004. QName value constraint\r
36 \r
37 When xs:QName based type is specified to an attribute or element\r
38 declaration, MS.NET fails to fill their {value constraints} (i.e.\r
39 default or fixed value), even though they have those namespace \r
40 declaration by XmlSerializerNamespaces.\r
41 \r
42 (MS: This is fixed in .NET 2.0)\r
43 \r
44 \r
45 005. derivation by extension of xs:all\r
46 \r
47 As it is discussed on w3c xmlschema-dev ML, MS System.Xml.Schema\r
48 incorrectly allows <complexType><complexContent><extension><all>\r
49 (i.e. XmlSchemaComplexContentExtension that contains XmlSchemaAll)\r
50 whose base type contains non-empty particle. It is prohibited, \r
51 because, as XML Schema structures 3.4.2 (complex content Schema\r
52 Component) {content type} 2.3, complex content extension creates \r
53 merged particles as a sequence, which never allows 'all' model group \r
54 as its content. \r
55 See: http://lists.w3.org/Archives/Public/xmlschema-dev/2002Oct/0156.html\r
56 \r
57 Below are incorrect W3C test suite in msxsdtest/complexType: ctH013.xsd,\r
58 ctH019.xsd, ctH020.xsd, ctH021.xsd, ctH022.xsd, ctH023.xsd, ctJ001.xsd\r
59 and in msxsdtest/ModelGroups: mgA016.xsd, mgO007.xsd (9 testcases).\r
60 \r
61 (MS: This is fixed in .NET 2.0)\r
62 \r
63 \r
64 006. xs:all minOccurs="0" not allowed\r
65 \r
66 W3C WXS Structures REC. says that model group xs:all is limited to have\r
67 minOccurs=maxOccurs=1 in case of complexType's content type particle\r
68 (see 3.8.6 All Group Limited), but this is corrected to allow \r
69 minOccurs=0. \r
70 (see E1-26 of http://www.w3.org/2001/05/xmlschema-errata#Errata1)\r
71 \r
72 Related msxsdtest is ParticlesEa022.xsd\r
73 \r
74 (MS: This happens only when a group ref targets to xs:all. This is bug.)\r
75 \r
76 \r
77 007. Insufficient unique particle attribution of xs:any\r
78 \r
79 MS.NET allows <xs:choice><xs:any /><xs:element ... /></xs:choice>.\r
80 \r
81 <del>\r
82 Related msxsdtests are: ParticlesJd002.xsd, ParticlesJd003.xsd and\r
83 ParticlesJd004.xsd. \r
84 </del>\r
85 [Update] They are sequence not choice. Thus does not apply to this\r
86 case. MS validator handles such schema as invalid correctly.\r
87 \r
88 ParticlesIb001.xsd is also related, but it is not necessarily said as\r
89 incorrect. Both elements are of the same type, so *in a sense* they are\r
90 the same declaration. MSV, XSV and I stands different.\r
91 \r
92 [Still on discussion on ParticlesIb001.xsd]\r
93 \r
94 \r
95 <del>008. Occurence Range OK (3.9.6) incorrectly assessed</del>\r
96 \r
97 [Update] MS team pointed out that it is incorrect and I found that \r
98 XML Schema Structures 3.3.2 explicitly denotes that when minOccurs=\r
99 maxOccurs=0 it corresponds to no component at all.\r
100 \r
101 Particles that have maxOccurs="0" looks simply ignored *before*\r
102 evaluating particle restriction valid, but it might get incorrect\r
103 result.\r
104 \r
105 <xsd:complexType name="foo">\r
106 <xsd:complexContent>\r
107 <xsd:restriction base="bar">\r
108 <xsd:choice>\r
109 <xsd:element name="e1" minOccurs="0" maxOccurs="0"/>\r
110 <xsd:element name="e2"/>\r
111 </xsd:choice>\r
112 </xsd:restriction>\r
113 </xsd:complexContent>\r
114 </xsd:complexType>\r
115 \r
116 <xsd:complexType name="bar">\r
117 <xsd:choice>\r
118 <xsd:element name="e1"/>\r
119 <xsd:element name="e2"/>\r
120 </xsd:choice>\r
121 </xsd:complexType>\r
122 \r
123 Related msxsdtest is groupG001.xsd.\r
124 \r
125 \r
126 009. derived list incorrectly allowed\r
127 \r
128 "Type Derivation OK" by list simple type of atomic simple type is\r
129 incorrectly assessed, when the list's {item type definition} (not \r
130 {base type definition} ) can be assessed as "Type Derivation OK". MSV,\r
131 XSV and Xerces is not designed to allow such type derivation, and I\r
132 think they are more correct than MS. That is, MS's schema engine is\r
133 designed to use such schema typed class like:\r
134 \r
135 public class Foo { int notAList; }\r
136 \r
137 Normally validates such xml into this class:\r
138 \r
139 <Foo>1</Foo>\r
140 \r
141 MS validator consequently allows such instance like:\r
142 \r
143 <foo xsi:type="int_list_type">1 2 3</foo>\r
144 \r
145 But it cannot be validated into that class Foo.\r
146 \r
147 Related msxsdtests are elemT015.xsd and elemT022.xsd.\r
148 \r
149 (MS: This will be fixed in the next version of .NET 2.0)\r
150 \r
151 \r
152 010. derived union incorrectly allowed\r
153 \r
154 Similar problem to No.9 above resides in xs:union. Derived union type\r
155 from atomic type is not naturally allowed.\r
156 \r
157 Related msxsdtest is elemT014.xsd.\r
158 \r
159 [ditto]\r
160 \r
161 \r
162 <del>011. schema finalDefault with list and/or union</del>\r
163 \r
164 [Update] This is not MS bug. We have to fix this problem. XML Schema\r
165 errata corrected this part of the spec by allowing 'list'.\r
166 \r
167 In xs:schema, finalDefault = (#all | List of (extension | restriction)),\r
168 but MS.NET failed to handle blockDefault='list' as an error.\r
169 (union as well.)\r
170 \r
171 Related msxsdtest is stF034.xsd and stF036.xsd.\r
172 \r
173 \r
174 012. derived types cannot duplicate fixed facet\r
175 \r
176 If you have a facet like <xsd:minLength value="5" fixed="true" />, \r
177 you should be able to have <xsd:minLength value="5" /> in \r
178 restrictions of it, as long as the values are the same. MS says: \r
179 "Base type has {fixed} equal to true."\r
180 \r
181 XML-Schema part2 Datatype, 4.3.2.1: \r
182 "If {fixed} is true, then types for which the current type is the\r
183 {base type definition} cannot specify a value for minLength other than\r
184 {value}."\r
185 \r
186 Which implies that you can specify a value for minLength that is the\r
187 same as {value}.\r
188 \r
189 (MS: This is bug.)\r
190 \r
191 \r
192 013. Some facets are incorrectly allowed for list simple type.\r
193 \r
194 As to structures spec 3.14.6 Derivation Valid (Simple) 2.2, only length,\r
195 minLength, maxLength, pattern and enumeration are allowed. However, MS\r
196 implementation allows whitespace (and possibly and so on).\r
197 \r
198 (MS: "whitespace" is incorrectly allowed. It is bug.)\r
199 \r
200 \r
201 <del>014. Incorrectly disallowed mixed derivation with empty content from\r
202 elementOnly</del>\r
203 \r
204 [Update] MS team pointed out that XSD Errata replaced -explicit \r
205 content- with -effective content- . Thus, such schema should be\r
206 rejected. (See E1-5 of http://www.w3.org/2001/05/xmlschema-errata .)\r
207 \r
208 When a complexType whose mixed='true' and -explicit content- is empty,\r
209 and is derived from a complexType whose {content type} is ElementOnly,\r
210 MS.NET rejects such schema. But 3.4.2 (complex content Schema\r
211 Component) especially 2.1 of {content type} does not say it is an error.\r
212 \r
213 Related msxsdtest: ctF008.xsd\r
214 \r
215 \r
216 015. Included schema ignores incorrect element name which belongs to \r
217 XmlSchema.Namespace\r
218 \r
219 MS Schema compiler fails to catch an error when an incorrect schema\r
220 (such as below) is included by any other schemas:\r
221 \r
222 <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'>\r
223 <xs:foo />\r
224 </xs:schema>\r
225 \r
226 This does not apply to general compilation error such as missing \r
227 sub components that should result in an error.\r
228 \r
229 This seems fixed in Whidbey.\r