1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
BUGS in MS Implementation of XmlSchema:
Here we summarize bugs found in MS.NET, including some comment excerpt from
Microsoft development team (as of 2004/07).
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.
(MS: This is fixed in .NET 2.0)
002. Resets the minOccurs to 0 if maxOccurs="0", whereas it should raise an error.
(MS: This WON'T be fixed in .NET 2.0. MS users may depend on this bug.)
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>
(MS: This is fixed in .NET 2.0)
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.
(MS: This is fixed in .NET 2.0)
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).
(MS: This is fixed in .NET 2.0)
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
(MS: This happens only when a group ref targets to xs:all. This is bug.)
007. Insufficient unique particle attribution of xs:any
MS.NET allows <xs:choice><xs:any /><xs:element ... /></xs:choice>.
<del>
Related msxsdtests are: ParticlesJd002.xsd, ParticlesJd003.xsd and
ParticlesJd004.xsd.
</del>
[Update] They are sequence not choice. Thus does not apply to this
case. MS validator handles such schema as invalid correctly.
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.
[Still on discussion on ParticlesIb001.xsd]
<del>008. Occurence Range OK (3.9.6) incorrectly assessed</del>
[Update] MS team pointed out that it is incorrect and I found that
XML Schema Structures 3.3.2 explicitly denotes that when minOccurs=
maxOccurs=0 it corresponds to no component at all.
Particles that have maxOccurs="0" looks simply ignored *before*
evaluating particle restriction valid, but it might get incorrect
result.
<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 groupG001.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.
(MS: This will be fixed in the next version of .NET 2.0)
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.
[ditto]
<del>011. schema finalDefault with list and/or union</del>
[Update] This is not MS bug. We have to fix this problem. XML Schema
errata corrected this part of the spec by allowing 'list'.
In xs:schema, finalDefault = (#all | List of (extension | restriction)),
but MS.NET failed to handle blockDefault='list' as an error.
(union as well.)
Related msxsdtest is stF034.xsd and stF036.xsd.
012. derived types cannot duplicate fixed facet
If you have a facet like <xsd:minLength value="5" fixed="true" />,
you should be able to have <xsd:minLength value="5" /> in
restrictions of it, as long as the values are the same. MS says:
"Base type has {fixed} equal to true."
XML-Schema part2 Datatype, 4.3.2.1:
"If {fixed} is true, then types for which the current type is the
{base type definition} cannot specify a value for minLength other than
{value}."
Which implies that you can specify a value for minLength that is the
same as {value}.
(MS: This is bug.)
013. Some facets are incorrectly allowed for list simple type.
As to structures spec 3.14.6 Derivation Valid (Simple) 2.2, only length,
minLength, maxLength, pattern and enumeration are allowed. However, MS
implementation allows whitespace (and possibly and so on).
(MS: "whitespace" is incorrectly allowed. It is bug.)
<del>014. Incorrectly disallowed mixed derivation with empty content from
elementOnly</del>
[Update] MS team pointed out that XSD Errata replaced -explicit
content- with -effective content- . Thus, such schema should be
rejected. (See E1-5 of http://www.w3.org/2001/05/xmlschema-errata .)
When a complexType whose mixed='true' and -explicit content- is empty,
and is derived from a complexType whose {content type} is ElementOnly,
MS.NET rejects such schema. But 3.4.2 (complex content Schema
Component) especially 2.1 of {content type} does not say it is an error.
Related msxsdtest: ctF008.xsd
015. Included schema ignores incorrect element name which belongs to
XmlSchema.Namespace
MS Schema compiler fails to catch an error when an incorrect schema
(such as below) is included by any other schemas:
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'>
<xs:foo />
</xs:schema>
This does not apply to general compilation error such as missing
sub components that should result in an error.
This seems fixed in Whidbey.
|
