230 lines
7.6 KiB
Plaintext
230 lines
7.6 KiB
Plaintext
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.
|